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

[Leonid Krivoshein]

12.04.2018 16:33, Alexey V. Vissarionov пишет:
> On 2018-04-11 22:41:11 +0300, Leonid Krivoshein wrote:
>
>   >> Коллеги, а вот кто может внятно объяснить, зачем вообще
>   >> может быть нужен initrd при загрузке с локального носителя
>   >> (непосредственно подключенного к компутеру)?

Уже отсюда всё неправильно! Стоило сразу заметить, что в случае 
пропагатора в initrd, носитель не всегда является локальным. Он как раз 
обеспечивает и сетевую загрузку, и загрузку с read-only носителей, 
подключенных локально, но съёмных. И создавать для этих случаев разные 
варианты ядер и инсталляторов смысла нет. Propagator, будучи в initrd, 
может задавать вопросы, откуда ставить систему. Ты можешь вкомпилировать 
в ядро вопросы пропагатора (1й стадии установщика)? :) Был упущен 
аргумент о том, что сейчас stage2 вынесена в корень установочного 
носителя, тогда как ядро с initrd находятся на нём в двух экземплярах.


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

Я бы скорее назвал два случая, весьма специфичных, для которых имеет 
смысл что-либо вкомпилировать в ядро: загрузка с md-raid без /boot (ух, 
ещё бы админов к этому приучить) и загрузка с корня на NFS, когда в ядро 
вкомпилируется даже свой DHCP-клиент. Но это такие крайние случаи, под 
которые не стоит ориентировать мэйнстрим.

Обсуждаемая проблема состоит в том, что нынешняя stage1 
Установщика/LiveCD/Rescue покрывает 95-98% железа, причём с нареканиями, 
к тому же требует "ухаживать" за файлами со списком модулей в m-p. Внеся 
изменения в алгоритм подбора модулей в соответствии устанавливаемому 
ядру, достаточных для загрузки на 99.9% железа, мы избавим себя от 
необходимости периодически ревьювить текстовый список модулей/регэкспов. 
Заменив пропагатор более надёжным решением, избавимся от нареканий и 
глюков. Это две разные задачи, но они об одном. Потому что не уследив 
вовремя за модулями, мы собрали более новое ядро без поддержки железа, 
которое там появилось, и у людей "не взлетело". Даже в этом году 
обращались (загрузка по PXE, облом на e1000e в более старом p7).

Твой вопрос: что мешает вкомпилировать в ядро поддержку наиболее 
типового железа?

1. Такой задачи не стоит. Нужно покрыть 100% железа, а не 80%. Потому 
что речь об общем, дистрибутивном, а не узко-специфичном решении. 
Простой пример "хитрого" железа, где так просто "не взлетит" -- Dell 
Latitude X1 с очень необычным съёмным DVD-приводом.

2. Каждый модуль что-то весит. А есть модули, требующие ещё и фирмварь. 
Чем больше модулей, тем ядро будет больше весить. Мало того, при каждой 
загрузке будет выполняться probe для каждого вкомпиляченного модуля, что 
замедлит процесс загрузки. Ну, так ведь наши деды никуда не торопились, 
да? :) Хотя сейчас, может, что-то изменилось и это работает иначе, не 
знаю. Понимаю, что MFM/RLL дискам место в музее истории, однако IDE 
найдутся даже в моём хозяйстве, а до относительно недавних пор 
использовал внешний ATAPI/CD-привод, подключавшийся к LPT-порту! Про 
нюансы с разными вариантами IDE, думаю, ты знаешь. И вот, если есть 
сомнения:

https://www.kernel.org/doc/Documentation/driver-model/platform.txt

3. Весьма неудобно держать/собирать десятки ядер под разные задачи. У 
нас их и так уже достаточно. Тогда как есть простой механизм -- одно 
ядро, один набор модулей в initrd.

4. Если загрузка модуля может быть перекрыта через blacklist, вызывая 
проблемы на конкретном железе, то как быть с вкомпиляченным модулем? 
Ядро менять?

5. Ещё несколько лет назад (не знаю, как сейчас), на ряде ноутбуков 
загрузиться по вай-фаю без ndiswrapper с виндовыми дровами было 
невозможно. Виндовые дрова тоже в ядро будем вкомпилячивать? :)

Этот список можно продолжать очень долго. И без того много букв! Ничто 
не мешает оптимизировать набор модулей под конкретную машину. Более 
того, по умолчанию у нас так и делается в процессе установки. Ничто не 
мешает собирать людям ядра с нужными им модулями под свои 
узко-специфичные задачи. Но мы здесь говорим совершенно о другом. Не 
стоит путать общее и частное. По моему глубокому убеждению, вообще всё 
равно, где находятся модули -- в ядре или в initrd с точки зрения 
"взлетит или не взлетит". Главное, чтобы они были. initramfs 
поддерживается ядром и не требует поддержки со стороны железа, 
одновременно обеспечивая общий, простой, удобный и модульный подход.


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

-->

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

А я думал, потому что так деды делали! :) Вообще-то initrd это 
усовершенствованный ramdisk. Если у тебя там будет rpm, apt, и даже 
Synaptic с иксами, ставь туда, что хочешь. В отличии от ramdisk, не надо 
указывать размер, он ничем неограничен. Чем действительно может быть 
полезен /dev/ram0 -- для организации промежуточной стадии stage2, когда 
реальный корень распаковывается в RAM из файла, который лежит где-то там...


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

Скорее "семейные традиции". К примеру, в Debian/Ubuntu -- iniramfs-tools 
+ liveboot и ещё с недавних пор overlayroot (оно немного для другого). А 
у нас ранее remount_rw и доселе init-bottom. Что это и зачем -- всё есть 
в коде и на ВиКи. Альт унифицировал в одном гибридном ISO Legacy и EFI 
загрузку, да ещё и по сети. С учётом выпускаемого числа дистрибутивов, 
стартеркитов и регулярок, это вполне оправдано.


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

Но не с точки зрения организации процесса начальной загрузки. Она у нас 
в stage1 одинакова для всех.


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

С учётом ограниченного числа его применений, мне сложно представить, как 
без него можно обойтись в тех местах, где он сейчас используется. А в 
других местах его нет, равно как и пропагатора.


-- 
Best regards,
Leonid Krivoshein.