[devel] Запрос на фичу liveboot в make-initrd

Чт Апр 12 16:33:35 MSK 2018

On 2018-04-11 22:41:11 +0300, Leonid Krivoshein wrote:

 >> Коллеги, а вот кто может внятно объяснить, зачем вообще
 >> может быть нужен initrd при загрузке с локального носителя
 >> (непосредственно подключенного к компутеру)?
 > Это же очевидно: чтобы смонтировать корневую файловую систему,
 > необходимы модули для работы с диском и этой файловой системой,

Досюда все правильно.

 > а для чтения модулей необходима файловая система, с которой
 > этот модуль читается. :)

Ну и что мешает вкомпилировать в ядро поддержку наиболее типового
железа? Да и вообще - всех модулей, у которых при вкомпилячивании
в ядро появляется дополнительная функциональность (так, например,
CONFIG_MD_RAID{0,1,10,456}=y дает включить CONFIG_MD_AUTODETECT,
который, в свою очередь, позволяет держать корень на зеркале безо
всяких костылей). Ы?

 > В альте всё собирается модулями, а не зашивается в ядро.

Да блинский блин... Я не призываю вкомпилячивать в ядро абсолютно
все, что есть в ядре (прежде всего потому, что достоверно знаю о
том, что некоторые модули ведут себя по-разному, и их поведение не
всегда становится лучше) - я делюсь _своим_ _собственным_ _опытом_
(довольно значительным, ага) эксплуатации самого различного железа,
от ультрабюджетного до махрово энтерпрайзнутого.

Ну и самое главное: вкомпилячивание в ядро самых востребованных
модулей не отменяет CONFIG_MODULES=y и CONFIG_BLK_DEV_INITRD=y -
они прекрасно уживаются в одном ядре.

 > И в этом есть рациональное зерно (см. далее). Так делается по
 > умолчанию и во всех известных мне дистрибутивах.

Ага... в шляпе - "мы так делаем с 1994 года", у всех остальных -
"в шляпе делают так, значит и мы будем делать так" :-)

 >> Собственно, именно с этого момента появилась возможность
 >> собирать ядро со вкомпилированной поддержкой самых
 >> популярных накопителей и сетевых интерфейсов, а технология
 >> initrd переместилась на новое место работы: сетевая загрузка
 >> Live-системы. А что, когда памяти аж 256 Мб - почему бы не
 >> отдать половину под / на /dev/ram0 для запуска установки или
 >> rescue-системы?
 > И этой возможностью можно пользоваться, собирая ядро
 > из исходников под конкретную систему, добавляя туда
 > только то, что требуется лишь для этой системы. Нет
 > смысла применять эту технологию во всех случаях по целому
 > ряду причин, обусловленных, всё той же памятью, всё той же
 > скоростью/эффективностью загрузки. И обеспечить возможность,
 > о которой идёт речь, в binary-package-based дистрибутиве,
 > наверное, хоть и возможно, но нерационально.

Какой возможностью? Загрузкой по сети? Да ей уже давно успешно
пользуются все, кому не лень...

А с установкой все становится совсем просто: загрузились откуда
угодно (например, по сети), смонтировали целевой носитель,
сказали rpmdb --root $TARGETDIR --initdb и поехали ставить пакеты
через rpm --root $TARGETDIR -Uvh ...

Я так в датацентре серверы запускал: грузчики притащили, техники
в стойку поставили и провода воткнули, оно по PXE загрузилось,
само систему втащило, в нее перегрузилось, нужный VLAN подхватило,
адрес получило - все, машина готова к работе, хотя я ее в глаза
не видел :-)

 > Кстати, раз речь о /dev/ram0, почему предлагается отказываться
 > от stage1 (initramfs) в пользу stage2 (ramdisk, традиционная
 > загрузка корня, о которой далее говорит Сергей Большаков)?

/dev/ram0 хорош тем, что позволяет, например, поставить пакеты
в загруженную по сети live-систему - в корне для этого можно
оставить место. Ну да, памяти оно сожрет чуть больше... да и пусть
с ней - в современных компутерах ее много.

 > Ведь ядро понимает сжатый initramfs "из коробки". Причём это
 > формат внутреннего кэша самого ядра. Эффективнее просто некуда.
 > Никаких модулей дисков, файловых систем не требуется. Не говоря
 > о том, что initramfs "из коробки" понимают все загрузчики.
 > Его также можно вкомпилировать в само ядро. Простое любопытство.

Как сказал председатель Мао, "bai hua qifang, bai jia zhengming" -
"пусть расцветают сто цветов, пусть соперничают сто школ". Кому что
больше нравится - пусть то и пользуют, ядро поддерживает оба этих
варианта.

 >>> Добавлю от себя лично: в пакете propagotor есть два особенных
 >>> скрипта. Первый init-bottom "очень дорог для нас". И критичен
 >>> в плане совместимости. Его бы как-то по-максимуму сохранить.
 >>> Второй -- mkmodpack. О нём в данном письме речи не идёт.
 >> А зачем? Грузим ядро, оно находит корневой раздел по метке,
 >> монтирует его, запускает init... Зачем для этого какие-то
 >> костыли?
 > init-bottom обеспечивает работу с read-only носителями, слоями
 > aufs r/o и r/w, загрузкой по NFS, многими опциями пропагатора.

Я правильно понимаю, что речь прежде всего об унификации этой работы?
Тогда возникает другой вопрос: а нужна ли она? Или лучше использовать
более специализированные инструменты для работы с разными носителями?

Впрочем, загрузка live-системы и установка системы на компутер - это
хоть и взаимосвязанные, но все же отдельные задачи.

 > Отрывая этот скрипт полностью, мы теряем возможность предложить со
 > временем безболезненно перейти с пропагатора на make-initrd-liveboot.

А если не отрывать полностью, но попробовать обойтись без него там,
где это возможно?

-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180412/d9c0fdbc/attachment.bin>