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

[Leonid Krivoshein]

11.04.2018 10:45, Alexey V. Vissarionov пишет:
> Коллеги, а вот кто может внятно объяснить, зачем вообще может быть
> нужен initrd при загрузке с локального носителя (непосредственно
> подключенного к компутеру)?

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_%D0%BA%D1%83%D1%80%D0%B8%D1%86%D1%8B_%D0%B8_%D1%8F%D0%B9%D1%86%D0%B0

Это же очевидно: чтобы смонтировать корневую файловую систему, 
необходимы модули для работы с диском и этой файловой системой, а для 
чтения модулей необходима файловая система, с которой этот модуль 
читается. :) В альте всё собирается модулями, а не зашивается в ядро. И 
в этом есть рациональное зерно (см. далее). Так делается по умолчанию и 
во всех известных мне дистрибутивах.


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

И этой возможностью можно пользоваться, собирая ядро из исходников под 
конкретную систему, добавляя туда только то, что требуется лишь для этой 
системы. Нет смысла применять эту технологию во всех случаях по целому 
ряду причин, обусловленных, всё той же памятью, всё той же 
скоростью/эффективностью загрузки. И обеспечить возможность, о которой 
идёт речь, в binary-package-based дистрибутиве, наверное, хоть и 
возможно, но нерационально.

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


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

http://git.altlinux.org/gears/m/make-initrd-propagator.git?p=make-initrd-propagator.git;a=blob;f=propagator/data/sbin/init-bottom;h=86d4e7b29095d5f5d8c85670c2e00e99894b7a9f;hb=bbcc4deda242a6fd48b6055be2e957df3db22819

init-bottom обеспечивает работу с read-only носителями, слоями aufs r/o 
и r/w, загрузкой по NFS, многими опциями пропагатора. Отрывая этот 
скрипт полностью, мы теряем возможность предложить со временем 
безболезненно перейти с пропагатора на make-initrd-liveboot.


-- 
Best regards,
Leonid Krivoshein.