Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
В моей практике сервером мог стать любой из соседних компьютеров с жёстким диском на 20 Гб и 1 Гб оперативной памяти, «раздавающий» по сети сам себя. Диски не демонтировались в силу их сомнительной ценности и не использовались в силу сомнительной работоспособности. Одновременная загрузка 3-4 компьютеров забивала 100 Мбит сеть почти до предела даже без помощи ngnix, а дальнейшее включение новых компьютеров с каждым новым случаем сильнее наталкивало на мысль, что всё просто зависло, хотя этого ни разу не случилось.
К моему стыду никогда не сталкивался в работе с HTTP, поэтому даже про iPXE узнал только из комментариев к предыдущей статье, и решил сразу попробовать уменьшить время загрузки отдельно взятой машины VirualBox и некогда любимого ноутбука с Core 2 Duo. С использованием iPXE и HTTP ноутбук всегда загружался по сети с виртуальной машины, подключенной по wi-fi. Тогда как TFTP в схожих условиях периодически отваливался. При разработке решения, естественно, такой вариант использования не тестировался, ведь проводные сети на практике доступнее и часто обходятся дешевле. К сожалению, iPXE очень странно ведёт себя в VirtualBox, поэтому с ним не удалось как следует познакомиться.
Доступа к реальным объектам у меня нет, поэтому перепроверил свои записи на реальных и виртуальных машинах в пределах квартиры и привёл их в такой вид, что даже сам бы их понял, чем и делюсь с сообществом.
Ваше решение, несомненно, имеет право на жизнь. Если вы немного подробнее про него расскажете, то я с удовольствием дополню статью. Замечательно, что ещё есть куда развиваться.
К моему стыду никогда не сталкивался в работе с HTTP, поэтому даже про iPXE узнал только из комментариев к предыдущей статье, и решил сразу попробовать уменьшить время загрузки отдельно взятой машины VirualBox и некогда любимого ноутбука с Core 2 Duo. С использованием iPXE и HTTP ноутбук всегда загружался по сети с виртуальной машины, подключенной по wi-fi. Тогда как TFTP в схожих условиях периодически отваливался. При разработке решения, естественно, такой вариант использования не тестировался, ведь проводные сети на практике доступнее и часто обходятся дешевле. К сожалению, iPXE очень странно ведёт себя в VirtualBox, поэтому с ним не удалось как следует познакомиться.
Доступа к реальным объектам у меня нет, поэтому перепроверил свои записи на реальных и виртуальных машинах в пределах квартиры и привёл их в такой вид, что даже сам бы их понял, чем и делюсь с сообществом.
Ваше решение, несомненно, имеет право на жизнь. Если вы немного подробнее про него расскажете, то я с удовольствием дополню статью. Замечательно, что ещё есть куда развиваться.
Я не понял, какова роль загрузочной флешки в вашей системе. Вроде с сервера грузимся?
Если вы имеете в виду загрузочную флешку в самом конце статьи, то я просто показал способ клонирования системы, который для флешек и жёстких дисков выглядит абсолютно одинаково. Просто демонстрация на примере флешек. При этом система с включенным обработчиком live будет работать в режиме «только для чтения», и её можно разместить даже на флешке, которую обычно быстро убивает режим постоянной записи мелких файлов, характерный для Linux.
Лицо-пальма.
Udev не может ничего создавать в sysfs напрямую (кроме как загрузкой драйверов). Sysfs создаётся ядром и только ядром. Udev заполняет /dev. И это в статье не опечатка, потому что «заполнять классы PCI» может только драйвер PCI, но никак не юзерспейнутая приблуда.
Далее. «Сравнивать» вывод udevadm info -q property с lspci просто не имеет смысла, так как они «смотрят» на одни и те же файлы в sysfs.
Кроме того, вы слишком радужную картинку рисуете. Я как-то попробовал запустить одновременно i915 и nvidia на разных X-серверах… Удачи, так сказать. Я плюнул. Хотя и обидно. Так что надеяться на то, что какая-то автоматика разберётся в зоопарке железа сама и правильно…
Udev не может ничего создавать в sysfs напрямую (кроме как загрузкой драйверов). Sysfs создаётся ядром и только ядром. Udev заполняет /dev. И это в статье не опечатка, потому что «заполнять классы PCI» может только драйвер PCI, но никак не юзерспейнутая приблуда.
Далее. «Сравнивать» вывод udevadm info -q property с lspci просто не имеет смысла, так как они «смотрят» на одни и те же файлы в sysfs.
Кроме того, вы слишком радужную картинку рисуете. Я как-то попробовал запустить одновременно i915 и nvidia на разных X-серверах… Удачи, так сказать. Я плюнул. Хотя и обидно. Так что надеяться на то, что какая-то автоматика разберётся в зоопарке железа сама и правильно…
Спасибо за замечания. Я исправлю это в статье. Теория меня на момент создания решения интересовала только как систематизация практических знаний.
Сравниваю выводы только для того, чтобы показать, что без разницы каким из них пользоваться, чтобы узнать вендора. Использую udevadm info для того, чтобы рассказать о правилах udev и получить информацию о подключенных мониторах, которую lspci не даёт. Оригинальный скрипт запускался один раз перед agetty и сканировал /sys/class/drm.
Что касается i915 и nouveau, то из них можно сделать даже «трехголовый» мультисит, если на материнской плате есть хотя бы два видеовыхода. Хотя я бы предпочёл поставить видеокарту radeon и использовать как минимум 4 головы, т. к. на nvidia мне их не удалось разделить. Попробуйте использовать предложенное решение на практике. Зачем гадать?
У Intel есть один чипсет, который в рассматриваемой системе. Это встроенные процессоры серий Atom D2500 — Atom D2700. С момента их первого появления я ждал, когда в линукс появится драйвер для их поддержки. Такой был в MeeGo, но вытащить его оттуда не получилось, а потом было не надо, т. к. вышли ещё несколько поколений Atom с того момента.
Сравниваю выводы только для того, чтобы показать, что без разницы каким из них пользоваться, чтобы узнать вендора. Использую udevadm info для того, чтобы рассказать о правилах udev и получить информацию о подключенных мониторах, которую lspci не даёт. Оригинальный скрипт запускался один раз перед agetty и сканировал /sys/class/drm.
Что касается i915 и nouveau, то из них можно сделать даже «трехголовый» мультисит, если на материнской плате есть хотя бы два видеовыхода. Хотя я бы предпочёл поставить видеокарту radeon и использовать как минимум 4 головы, т. к. на nvidia мне их не удалось разделить. Попробуйте использовать предложенное решение на практике. Зачем гадать?
У Intel есть один чипсет, который в рассматриваемой системе. Это встроенные процессоры серий Atom D2500 — Atom D2700. С момента их первого появления я ждал, когда в линукс появится драйвер для их поддержки. Такой был в MeeGo, но вытащить его оттуда не получилось, а потом было не надо, т. к. вышли ещё несколько поколений Atom с того момента.
Nouveau после появления стима, к сожалению, стала совсем неинтересным вариантом, ибо многие игры просто не запускаются с ней.
А nvidia с i915 не дружит намертво, и, подозреваю, что с nouveau оно тоже не заведётся, ибо там гигантские срачики за DRM и прочие fast path штуки. Драйвера просто одновременно не инициализируются. Увы.
А nvidia с i915 не дружит намертво, и, подозреваю, что с nouveau оно тоже не заведётся, ибо там гигантские срачики за DRM и прочие fast path штуки. Драйвера просто одновременно не инициализируются. Увы.
Сегодня специально протестировал такой компьютер: i5 на чипсете Z77 с видеокартой GTX680. К внешней видеокарте подключены монитор через DisplayPort и проектор через HDMI. Загрузил компьютер по сети.
Включился проектор. Lspci показал в системе только nVidia.
Включил встроенную видеокарту через BIOS (назовём его так). Картинка с nVidia исчезла совсем, т.к. сначала инициализируется встроенная видеокарта, куда сразу же был подключен монитор через D-Sub. Информация о загрузке отобразилась на нём, и на нём же система вышла в графический режим. Это предсказуемое поведение, т. к. внешняя видеокарта до сих пор была неактивна и пребывала в статусе disabled. Поправил правило вот таким образом:
Информация во время загрузки отображалась на D-Sub встроенной видеокарты, а графический режим включился на выходе HDMI внешней. Отключил кабель проектора и заново перезагрузил. Изображение появилось на мониторе, подключенном к DisplayPort GTX680.
Всё запустилось и работало как предполагалось. Не произошло ничего неожиданного.
Вот все устройства (card0 — intel):
В данном случае card0 — встроенная видеокарта, а card1 — внешняя. Они легко могут поменяться местами после перезагрузки. На работоспособность решения из статьи это никак не повлияет.
Если нужно быть уверенным, что смены имени не произойдёт, то можно сделать так (пример для случая с внешней картой AMD):
В этом случае всегда card0 — AMD, а card1 — Intel.
Включился проектор. Lspci показал в системе только nVidia.
Включил встроенную видеокарту через BIOS (назовём его так). Картинка с nVidia исчезла совсем, т.к. сначала инициализируется встроенная видеокарта, куда сразу же был подключен монитор через D-Sub. Информация о загрузке отобразилась на нём, и на нём же система вышла в графический режим. Это предсказуемое поведение, т. к. внешняя видеокарта до сих пор была неактивна и пребывала в статусе disabled. Поправил правило вот таким образом:
nano /etc/udev/rules.d/10-graphics.rules
...
KERNEL=="card*", SUBSYSTEM=="drm", ATTR{status}=="connected", RUN+="/etc/default/xdevice %n %k"Информация во время загрузки отображалась на D-Sub встроенной видеокарты, а графический режим включился на выходе HDMI внешней. Отключил кабель проектора и заново перезагрузил. Изображение появилось на мониторе, подключенном к DisplayPort GTX680.
Всё запустилось и работало как предполагалось. Не произошло ничего неожиданного.
Вот все устройства (card0 — intel):
ls /sys/class/drm/ | grep card
card0
card0-DP-1
card0-DP-2
card0-HDMI-A-1
card0-HDMI-A-2
card0-VGA-1
card1
card1-DP-3
card1-DVI-D-1
card1-DVI-I-1
card1-HDMI-A-3
lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1)В данном случае card0 — встроенная видеокарта, а card1 — внешняя. Они легко могут поменяться местами после перезагрузки. На работоспособность решения из статьи это никак не повлияет.
Если нужно быть уверенным, что смены имени не произойдёт, то можно сделать так (пример для случая с внешней картой AMD):
nano /etc/modules-load.d/persistent-drm-devices.conf
radeon
i915В этом случае всегда card0 — AMD, а card1 — Intel.
То есть одновременно запустить обе не удалось. Про это я и писал.
Я понял ваш вопрос.
Изначально в статье не ставилась задача запустить все мониторы.
Udev привязан к событию «появления головы с подключенным монитором» и срабатывает столько раз, сколько мониторов подключено. Каждый раз запускается скрипт $root/etc/default/xdevice, который заполняет шаблон и записывает его в один и тот же конфигурационный файл обычным перенаправлением вывода ">". В итоге остаётся только самый последний. На какую видеокарту он показывает, та и работает.
На самом деле будут работать все головы последней обнаруженной видеокарты, и они будут показывать одну и ту же картинку.
Можно в мой скрипт добавить код, который при первом срабатывании будет удалять старый конфигурационный файл из папки /etc/X11/xorg.conf.d. Но придётся много писать для того, чтобы понять, какой раз был первым, т. к. скрипт запускается в стольких копиях, сколько подключено мониторов, а сам запуск при этом происходит практически параллельно благодаря udev. Кроме того, в случае двух видеокарт в конфигурационном файле должны присутствовать только два блока «Device», а не сколько есть мониторов. Соответственно, придётся проверять и этот момент перед записью шаблона, чтобы не повторяться. Задачи решаемы, но проще их решить не при параллельном запуске, а запустив немного изменённый скрипт один единственный раз перед, getty, например. Но как в этом случае продемонстрировать пример с правилами udev?
Изначально в статье не ставилась задача запустить все мониторы.
Udev привязан к событию «появления головы с подключенным монитором» и срабатывает столько раз, сколько мониторов подключено. Каждый раз запускается скрипт $root/etc/default/xdevice, который заполняет шаблон и записывает его в один и тот же конфигурационный файл обычным перенаправлением вывода ">". В итоге остаётся только самый последний. На какую видеокарту он показывает, та и работает.
На самом деле будут работать все головы последней обнаруженной видеокарты, и они будут показывать одну и ту же картинку.
Можно в мой скрипт добавить код, который при первом срабатывании будет удалять старый конфигурационный файл из папки /etc/X11/xorg.conf.d. Но придётся много писать для того, чтобы понять, какой раз был первым, т. к. скрипт запускается в стольких копиях, сколько подключено мониторов, а сам запуск при этом происходит практически параллельно благодаря udev. Кроме того, в случае двух видеокарт в конфигурационном файле должны присутствовать только два блока «Device», а не сколько есть мониторов. Соответственно, придётся проверять и этот момент перед записью шаблона, чтобы не повторяться. Задачи решаемы, но проще их решить не при параллельном запуске, а запустив немного изменённый скрипт один единственный раз перед, getty, например. Но как в этом случае продемонстрировать пример с правилами udev?
Xorg'у нужно предоставить информацию ровно в тех пределах, чтобы не допустить двоякого толкования. Мы привязываем определённый драйвер к определённой шине, чтобы встроенное и внешнее видео работали каждый со своим. Конкретно для каждого драйвера указываем тип используемого ускорения, хотя для наших целей это делать не обязательно.
Из Intel не будут работать только D2500 series и D2700 series.
Если при старте X на каких-то системах возникает ошибка «xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted», то в файле ~/.bash_profile нужно убрать перенаправление "&>/dev/null"
Из Intel не будут работать только D2500 series и D2700 series.
Если при старте X на каких-то системах возникает ошибка «xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted», то в файле ~/.bash_profile нужно убрать перенаправление "&>/dev/null"
Прекрасный цикл их трех статей. Спасибо большое! Читая, получил большое удовольствие и некоторое понимание как оно все приблизительно работает. Появились вопросы.
Как сейчас, спустя несколько лет после написания, обстоит дело с использованием удаленных рабочих мест? Практика так сказать.
Второй вопрос: использовали ли вы виртуализацию, для отображения других операционных систем на тонких клиентах, например Windows, Mac OS X? Какие тут могут быть нюансы?
Как сейчас, спустя несколько лет после написания, обстоит дело с использованием удаленных рабочих мест? Практика так сказать.
Второй вопрос: использовали ли вы виртуализацию, для отображения других операционных систем на тонких клиентах, например Windows, Mac OS X? Какие тут могут быть нюансы?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стань повелителем загрузки Linux