Быстрая сетевая загрузка

Я автор статьи, вопросы можно задавать здесь.

ximeric (09.02.2010 11:43:39)

Слишком все высокоуровнево. Какой-то не нужный, да еще и патченный dracut, куча костыльных скриптов, привязка с федоре.. Все это можно сделать одними только mksquashfs+nfs+pxe.

holka (09.02.2010 12:13:03)

dracut - инструмент из Fedorы.

Внимательно читаем заголовок, замечаем слово "Fedora", успокаиваемся.

ximeric (09.02.2010 12:28:14)

Патчи в апстрим отправил?

Manhunt (09.02.2010 12:30:02)

> Патчи в апстрим отправил?

Нет, но буду рад, если кто-нибудь возьмёт на себя сей труд.

ximeric (09.02.2010 12:34:01)

Уважаемый, раскройте, плиз, технические детали Вашего решения совместного использования встроеной и внешней видях

Раскрою.

Что конкретно интересует?

ximeric (09.02.2010 13:45:33)

> Многие знают... Ещё меньшему количеству людей интересен...

Русских языков надо учить афтару.

Интересны:
используемое железо
+
нужные настройки BIOS
+
"скрипт, который перед нормальным запуском X'ов запускал Xorg с ключом '-probeonly'"
+
xorg.conf
+
комментарий, проломившего грабли

PS
в нашем печальном случае (мать AIMB-750 (video INTEL) + MATROX G550) скрестить не получилось - но мы прямо скажем слабоваты

Я н***я не понял.™

Почему время загрузки «initrd.img» и требования к памяти в разы уменьшаются?

guitarist (09.02.2010 13:58:19)

интересно, ща позырим.

Correctnoe_imya_polzovatelya (09.02.2010 14:01:52)

Прочитал и с налету не очень понял :(

Я когда давно пробывал это скрипт ( то-ПХЕ ) так он гад
имаж пихал в рам-диск :( А этот рамдиск грузился через тфтпд
а тфтпд торомоз как еще поискать .

В принципе я поизучаю статью но должны быть по идее проще.
по тфтпд грузится просто как обычно ядро + рамдиск а им уже параметрам
укзываешь что рут-имаже-скваш лежит вон тама ( нфс-фтп-ввв )
и загрузка этого образа уже по этим протоколам по локалке обычно меньше
минуты !
Ну то что я описал сделано во многих дистрибутах что грузятся через ПХЕ
тот же РескуеСД и т.д.

Думаю описал понятно :)

mx_ (09.02.2010 14:15:46)

Вендекапец?

> используемое железо

MB: Gigabyte M61PM-S2, с интегрированной NVidia Video: Sapphire X1650 PRO (DVI+D-SUB)

> нужные настройки BIOS

Сейчас не помню всё, но

• Точно нужно включить параметр, отвечающий за НЕОТКЛЮЧЕНИЕ встроенной видеокарты если воткнута внешняя.
• Порядок инициализации видео: сначала внешняя.
• Не все системные платы позволяют работать внутренней видеокарте, если есть внешняя. Однажды, когда делал 3-х-головое решение на NVidia (не бездисковое, обычное), поставщику компьютеров пришлось даже менять материнские платы (если интересно, можно поискать мой вопрос на сайте forum.gigabyte.ru, по моему нику).

> "скрипт, который перед нормальным запуском X'ов запускал Xorg с ключом '-probeonly'"

 
#!/bin/bash 
 
(                                                                     
echo Phase 1 
X -config /etc/X11/xorg-probe.conf -layout ProbeN1Layout -probeonly & 
sleep 3 
killall -9 X 
sleep 1 
echo Phase 2 
X -config /etc/X11/xorg-probe.conf -layout ProbeRRN1Layout -probeonly 
sleep 1 
killall -9 X 
sleep 1 
echo Phase 3 
X -config /etc/X11/xorg-probe.conf -layout ProbeRRN2Layout -probeonly & 
sleep 1 
killall -9 X 
echo Done  
) > /tmp/xprobe.log 2>&1 

> xorg.conf

xorg-probe.conf

 
# init primary and secondary card 
 
Section "ServerLayout" 
   Identifier     "ProbeN1Layout" 
   Screen         "ScreenN1" 
   InputDevice    "Keyboard0" "CoreKeyboard" 
EndSection 
 
Section "ServerLayout" 
   Identifier     "ProbeN2Layout" 
   Screen         "ScreenN2" 
   InputDevice    "Keyboard0" "CoreKeyboard" 
EndSection 
 
Section "ServerLayout" 
   Identifier     "ProbeRRN1Layout" 
   Screen         "Screen0" 
   Screen         "Screen1" LeftOf "Screen0" 
   Screen         "ScreenN1" LeftOf "Screen1" 
   InputDevice    "Keyboard0" "CoreKeyboard" 
EndSection 
 
Section "ServerLayout" 
   Identifier     "ProbeRRN2Layout" 
   Screen         "Screen0" 
   Screen         "Screen1" LeftOf "Screen0" 
   Screen         "ScreenN2" LeftOf "Screen1" 
   InputDevice    "Keyboard0" "CoreKeyboard" 
EndSection 
 
Section "Files" 
   ModulePath   "/usr/lib/xorg/modules/extensions/nvidia" 
   ModulePath   "/usr/lib/xorg/modules" 
EndSection 
 
Section "InputDevice" 
   Identifier  "Keyboard0" 
   Driver      "kbd" 
EndSection 
 
Section "Device" 
   Identifier  "Videocard0" 
   Driver      "radeonhd" 
   BusID       "PCI:2:0:0" 
EndSection 
 
Section "Device" 
   Identifier  "Videocard1" 
   Driver      "radeonhd" 
   BusID       "PCI:2:0:1" 
EndSection 
 
Section "Device" 
   Identifier  "VideocardN1" 
   Driver      "nv" 
   BusID       "PCI:0:13:0" 
EndSection 
 
Section "Device" 
   Identifier  "VideocardN2" 
   Driver      "nvidia" 
   BusID       "PCI:0:13:0" 
EndSection 
 
Section "Screen" 
   Identifier "Screen0" 
   Device     "Videocard0" 
   DefaultDepth     24 
   Option       "NoInt10" "no" 
   SubSection "Display" 
      Viewport   0 0 
      Depth     24 
   EndSubSection 
EndSection 
 
Section "Screen" 
   Identifier "Screen1" 
   Device     "Videocard1" 
   DefaultDepth     24 
   Option       "NoInt10" "no" 
   SubSection "Display" 
      Viewport   0 0 
      Depth     24 
   EndSubSection 
EndSection 
 
Section "Screen" 
   Identifier "ScreenN1" 
   Device     "VideocardN1" 
   DefaultDepth     24 
   Option       "NoInt10" "no" 
   SubSection "Display" 
      Viewport   0 0 
      Depth     24 
   EndSubSection 
EndSection 
 
Section "Screen" 
   Identifier "ScreenN2" 
   Device     "VideocardN2" 
   DefaultDepth     24 
   Option       "NoInt10" "no" 
   SubSection "Display" 
      Viewport   0 0 
      Depth     24 
   EndSubSection 
EndSection 

> комментарий, проломившего грабли

Не знаю, как сейчас обстоят дела с параллельной работой этих видеокарт на современной версии X-ов (потому, что первые бездисковые клиенты с F7 так и сидят на этой версии), но я тогда на@#$%*& вдоволь.

ximeric (09.02.2010 14:44:06)

> Почему время загрузки «initrd.img» и требования к памяти в разы уменьшаются?

Потому что образ диска больше не цепляется к initrd, и он (initrd.img) остаётся относительно маленьким.

ximeric (09.02.2010 14:52:14)

Спасибо, курим как протоМАН

Прочитал. Не очень понял зачем патчить то было ?
Что разве взять и примонтировать -o loop
образ этого ливе-сд нельзя ? А потом его раздать по нфс
где его схватит обычный - дракут-нетворк ?

mx_ (09.02.2010 15:02:14)

>но и заработать потом основной ОС.

"Все мы вышли из Шоминой шинели".

Sun-ch (09.02.2010 15:12:30)

Я тоже за использование nfs+pxe

> Ещё меньшему количеству людей интересен скрипт 'livecd-iso-to-pxeboot' из того же пакета,

не надо в таком тоне писать новости

www_linux_org_ru (09.02.2010 15:16:47)

> Что разве взять и примонтировать -o loop образ этого ливе-сд нельзя ? А потом его раздать по нфс где его схватит обычный - дракут-нетворк?

Попробуй сделать сам то, что написал.

Результат будет другой: сетевой трафик больше - в сети будут гоняться отдельные файлы, а не сжатые блоки; тебе придётся копировать образ для каждого клиента, или выдумывать обходные манёвры, т.к. изменения файлов клиентом попадут в образ (можешь посмотреть проект StatelessLinux, но он какой-то неживой).

ximeric (09.02.2010 15:31:36)

> не надо в таком тоне писать новости

Что не так?

ximeric (09.02.2010 15:33:01)

Вообще я про то что изменится если юзать стандартный дракут а не патченый ...

> Результат будет другой: сетевой трафик больше - в сети будут
> гоняться отдельные файлы, а не сжатые блоки
те блок не будет загружаться в рам клиента и тама разархивироваться
тут еще нужно поглядеть что будет лучше то ...

> тебе придётся копировать образ для каждого клиента, или
> выдумывать обходные манёвры, т.к. изменения файлов клиентом
> попадут в образ
Не понял ? Вообще это ливеСД вроде бы. Без овервлая те.
Или изнутри уже монтировать нфс-хоме не кошерно ?

mx_ (09.02.2010 15:47:12)

> например, образ в 200 МБ загружается через сеть около полутора минут

С чего бы это? У меня 200 Мб прокачивается за 5 секунд...

Поставь себе Арч, станет гораздо легче жить.

ei-grad (09.02.2010 16:06:10)

> С чего бы это? У меня 200 Мб прокачивается за 5 секунд...
Это он про тфтпд ...

mx_ (09.02.2010 16:08:07)

Кое у кого все еще не гигабитная сеть, ну и даже в гигабитной сети тоже параллельно какой-нибудь трафик случается.

shimon (09.02.2010 16:08:28)

Поясню свой пост - никаких федоровских костылей и LiveCD не нужно, простая PXE загрузка Linux с корнем в NFS и aufs поверх гораздо проще и удобнее в любом отношении. Можно сверху навесить что угодно.

ei-grad (09.02.2010 16:11:30)

> Что не так?

Я продолжу в таком стиле:

Ещё меньшему количеству людей интересен скрипт 'livecd-iso-to-pxeboot' из того же пакета. Их количество станет еще более ничтожным после того факта, что Федора -- всего лишь один из многочисленных дистрибутивов Линукса. Да и сам линукс, того и гляди, будет вытеснен...

____________________

Ты же пишешь статью для тех, кому livecd-iso-to-pxeboot интересен. Так какое им дело до их количества?

www_linux_org_ru (09.02.2010 16:22:16)

Наконец то осилили root on NFS?

azure (09.02.2010 17:54:47)

>С чего бы это? У меня 200 Мб прокачивается за 5 секунд...

по протоколу тфтп? я заметил что по тфтп не больше 10 мегабит скорость бывает. Видимо ограничение протокола хз

alt0v14 (09.02.2010 18:34:01)

>The TFTP protocol uses a lock-step algorithm. After the transmitter sends a block of data, it waits for an acknowledgement of reception before sending the next block. The transfer rate is therefore limited to the round-trip time (RTT). If the round-trip time between two hosts is 20 ms, for example, then the transmitter can send up to 50 blocks per second. With a default block size of 512 bytes, the transfer rate is bound to 25 kiB/s.

видимо в гигабитной сети будет шустрее, но ограничения в протоколе присутствуют

alt0v14 (09.02.2010 18:37:14)

У меня рабочая лошадка (AMD Athlon X2 5400, 8Gb DDR2-800) - тонкий клиент с IDE-Flash на 4 Mb, на которой лежит ядро, монтирующее корень по nfs. Машина "трехголовая", два монитора на встроенной GeForce 6150 и один на GT220. Скорость передачи данных - около 90 мегабайт (гигабитный линк). От загрузки ядра до приглашения xdm по сети передается 43 мегабайта. Скорость запуска openoffice - около 3 секунд с "холода". Если бы не глючные дрова nvidia, машина не перезагружалась бы неделями. Вопрос автору - зачем нужен initrd, nfssquash и т.д. Не троллинга ради, просто действительно не вижу преимуществ. Объясните.

> Не понял ? Вообще это ливеСД вроде бы. Без овервлая те.

Загляни в initrd.img/sbin/dmsquash-live-root (F12).

> Или изнутри уже монтировать нфс-хоме не кошерно?

Кроме 'хоме' бывают и другие изменяемые в процессе работы каталоги.

Вообще, в чём загвоздка? Статья для тех, кто хочет сделать НЕ через NFS-root, потому что это совсем другой способ. (Там, между прочим, указано, что эту возможность даёт установка dracut-network). Изначальная проблема - медленная загрузка большого initrd, сделанного через livecd-iso-to-pxeboot. Не я придумал этот инструмент, т.ч. выступления не по адресу.

Я пошёл своим путём, решение работает годы и меня устраивает. Теперь я решил поделиться этим решением с общественностью, что и сделал. Кто хочет - использует, остальные критикуют.

ximeric (09.02.2010 19:08:21)

> AMD Athlon X2 5400, 8Gb DDR2-800 - тонкий клиент

Ха-ха.

> зачем нужен initrd, nfssquash и т.д.

В стандартном ядре Fedora нет поддержки NFS-root (что, в общем, странно, т.к. dracut-network всё равно потом делает тоже самое, если нужно). Чтобы её туда добавить, нужно пересобирать ядро, а я последний раз делал это до того, как перешёл на дистрибутивы, базирующиеся на RedHat Linux и Fedora. Потому как дистрибутивное ядро меня устраивает.

Большинством используются средства, входящие в дистрибутив. Соответственно, initrd делается дистрибутивным dracut'ом, а nfssquash - дополнение. Тем более, что dracut стремится быть универсальным средством, охватывающим много вариантов загрузки.

Ну и основная цель - дать обычным (т.е. не таким, как Ваш ;-) ) "тонким" клиентам образ системы, который не занимает на сервере много места, не загружает сеть при работе, и является неизменяемым.

ximeric (09.02.2010 19:57:42)

Прошу модераторов вернуть исходный заголовок, как в статье, т.к. текущий не отражает специфики и сбивает некоторых с толку.

ximeric (09.02.2010 20:04:25)

> Ты же пишешь статью для тех, кому livecd-iso-to-pxeboot интересен. Так какое им дело до их количества?

Возможно, что-то в этом не так. Придумаю - перефразирую.

ximeric (09.02.2010 20:10:11)

Кхм, ну да, термин тонкий клиент означает не совсем бездисковую рабочую станцию ) Но я думаю, что вы поняли. Тогда ваше предложение держать в оперативе Ъ тонкого клиента пару сотен мегов ещё более странно, так как вроде памяти у такой машины должно быть немного. Впрочем, в любом случае, у вас совершенно другие цели.

Решение на ALT Linux в том же духе (с выбором root via nfs/nbd/propagator) - http://admdev.blogspot.com/search/label/altlinux-live

pxelinux чем не устраивает???

Если еще и чего-то доинсталировать не понятно в чем проблема добавить поддержку nfsroot в ядро а параметры сборки ядра взять из /proc/config.gz

Ну это если задаться целью замучить fedora.

На slackware все ставиться без плясок с бубном используя pxelinux который является частью дистрибутива. Хотя очень сомнительно, что в fedora эта часть отсутствует.

Далее по поводу выбора конфигурации на основании ip/mac и еще чего угодно в стартовом скрипте выполнить переключение порядка загрузки. И профиля xorg.conf через выбор:

/usr/X11R6/bin/X +bs -screen "using_screen" -query $XSERVER

для любителей можно выбрать не только screen но и ServerLayout. т.о. считаю подобные страсти избыточными как и ltsp (не по теме) в загали. Все гораздо проще.

И еще пересборка ядра дает явные преимущества перед ядром из дистрибутива. Да и собирать можно не все....

У меня стоят еще 486dx4-100mHz и прекрасно работают в качестве тонких клиентов...

Но ведь Федора не нужна.

holka (09.02.2010 23:38:19)

>Но ведь Федора не нужна.

сам Торвальдс на федоре сидит

alt0v14 (10.02.2010 0:31:52)

хм странно... ещё на 8й федоре работали у меня тонкие сервера в nfsroot... всё что нужно было - доп параметры при запуске mkinitrd. машинки были полностью diskless, ибо жило в них РХЕ

но статью всё равно почитаю, может разберусь в этом грёбаном дракуте, а то не хочет увидеть все 6 флешек, после двух уже пытается собрать raid5

Это, конечно, веская причина, но только не за тем, чтобы всего лишь загрузить бездисковый клиент по сети. С этими дракутами и прочими наколеночными скриптами - без федоры здесь все куда проще.

holka (10.02.2010 8:18:21)

> но только не за тем, чтобы всего лишь загрузить
> бездисковый клиент по сети.

Это не бездисковый клиент ! Внимательно прочитайте заголовок статьи !
Или ТРУ ЛОР и по ссылкам не ходим ?
"Быстрая сетевая загрузка "живых" образов дисков с Fedora 12 через PXE"

Еще вопросы есть ?

mx_ (10.02.2010 8:24:45)

> Статья для тех, кто хочет сделать НЕ через NFS-root,
Ты уж извини. Я просто давно тоже с этим столкнулся ( медленная загрузка большого initrd ) и тогда забил про это :(
Вот прочитал твою статью и стало интересно. Нужно ли патчить ?
может достаточно динамически распаковывать имж-скваш и подсовывать его по нфс ( не люблю нфс - плохая секруность, до ху открытых портов :( )

Просто если запатчить то придется как минимум в юм добавлять ехклюде=дракут иначе при очередном обновлении все накроется медным тазом :( Или следить за этим руками :(((

mx_ (10.02.2010 8:47:28)

> по протоколу тфтп? я заметил что по тфтп не больше 10 мегабит скорость бывает. Видимо ограничение протокола хз

Сейчас специально померил - время загрузки файла размером 422 мегабайта в двоичном режиме 25 секунд (использовался штатный tftp-hpa)

> Тогда ваше предложение держать в оперативе Ъ тонкого клиента пару сотен мегов

А где такое написано?

ximeric (10.02.2010 9:06:24)

> Но вот проблема: образ initrd имеет размер в несколько сотен мегабайт, что выливается в очень долгое время загрузки только этого образа (например, образ в 200 МБ загружается через сеть около полутора минут), что, мягко говоря, непонятно и непозволительно.

Это утверждение не соответствует действительности

Если бы это работало "из коробки", то и патчить бы не пришлось.

Почему пришлось патчить? Потому, что dracut

• или поднимает сеть, монтирует NFS-root и продолжает загрузку с него,
• или в скрипте, подключающем "живой" образ, монтирует блочное устройство самостоятельно, а потом оживляет squashfs.img.

Вот и понадобилось делать стыковку методов.

По-хорошему, там можно ещё немного подправить, и доделать событийно-ориентированное монтирование "живого" образа по цепочке устройств. Может, разработчики обратят на это внимание.

"Тонкие" клиенты не нуждаются в частых обновлениях.

ximeric (10.02.2010 9:31:12)