Большой initrd vs большое монолитное ядро

[DdShurick]

Имел ввиду сборку initrd типа dracut, mkinitcpio

Это персональный initrd к каждой сборочке? Зачем, когда можно сделать универсальный? И вообще, чем проще, тем надёжнее. Что должен делать initrd в frugal сборке? Должен увидеть носитель, найти на нём модули и собрать их в aufs. Всё, остальное излишество. В "большом" линунуксе видеть носитель обязано любое ядро, за исключением специальных сборок, предназначенных для работы из RAM. Для сборки с aufs необходимо накладывать патч, или использовать overlayfs, пожертвовав горячим подключением.
 Вопрос: на кой хрен тащить модули ядра в initrd и городить их загрузку, когда это абсолютно не нужно? Обоснуй свои излишества.

[krasnyh]

Обоснуй свои излишества.

Целая тема была, [Решено] Поддержка устройств типа nvme в initrd, по итогам которой допилили initrd-raf от sfs, а "классический*" initrd остался не удел, биться за него не стали.

* классический, тот самый, без модулей.

[sfs]

Это персональный initrd к каждой сборочке?

Это возможность добавить в инитрд то, что нужно не всем (например llvm , шифрование, экзотические ФС ...) и собрать его под любое ядро

Т.е. если собрать инитрд только с тем , что нужно тебе - совсем большим оно не будет
Да если и будет - на ссд это не заметно. После загрузки Ос - уже без разницы что было в инитрд

А вот если все притащить монолитом в ядро - vmlinuz становится огромным. А он грузится в память и торчит там до выключения.

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

"классический*"  initrd остался не удел, биться за него не стали.

Не очень удачный пример. Было просто лень с ним заморачиваться , т.к. маленький инитрд  мало что дает (см. выше)
Ну и допустим понадобился мне llvm . Системы пересборки нет. Автору не интересно. Приехали

[gumanzoy]

А что значит "большой initrd" ?
Не все initrd с модулями одинаковые.
mkinitramfs в Debian 11 с ядром 5.10 выходит ~33MB
А в DogLinux (mkinitrd) и в Slax (initramfs_create) ~10MB с ограниченным списком только нужных для загрузки модулей и их зависимостей.

initrd на сколько я понял все же остается в памяти. В DogLinux в /mnt/live/ в Slax /run/initramfs/
Или в других Puppyобразных не так ?

[imp]

Тут с sfs соглашусь. Большой vmlinuz не нужен. Однако, нужен достаточной для начального разворота. Большой initrd, как по-мне - тоже, нужен достаточный. И инструменты, чтобы добавить, кому чего не хватает для полного счастья.
Хотя, тот, кому надо и без инструментов добавит. А остальным это непонятно, зачем.

[sfs]

что значит "большой initrd" ?

В контексте этой темы - с модулями ядра.ko и udev внутри
А "большое ядро" - это там где эти модули монолитно и udev тогда в инитрд не нужен

в DogLinux (mkinitrd) и в Slax (initramfs_create) ~10MB с ограниченным списком только нужных для загрузки модулей и их зависимостей.

Если это загрузка модулей по списку без удев - на мой взгляд самое кривое рещение. И кстати модули ядра тоже постоянно будут в памяти, т.е. как у монолитного ядра

В DogLinux в /mnt/live/ в Slax /run/initramfs

Насколько мне известно - это копируется самим инитрд (причем обычно не весь инитрд)), чтобы потом корректно все отмонтировать и  выключить пк

Большой initrd, как по-мне - тоже, нужен достаточный

Раньше для  исо собирал 2 : normal и fallback . Разница по загрузке - пара секунд. В итоге собираю только большой, чтобы у юзеров было поменьше вопросов

[DdShurick]

А в DogLinux (mkinitrd) и в Slax (initramfs_create) ~10MB

Richy initrd.gz == 186Kb

[sfs]

Richy initrd.gz == 186Kb

Сколько секунд экономии при загрузке ОС это дает по сравнению с 20 мб  инитрд?

[DdShurick]

по сравнению с 20 мб  инитрд

Не думай о секундах, хотя они тоже не лишние, думай от том, что останется болтаться в памяти. Или опять скажешь: "по сравнению с браузером....."
Загрузка Richy: ядро и initrd ~1сек. (точно измерить не получается), сборка aufs = 6 сек. , иксы = 24 сек.
LFD LXDE: соответственно 3, 15, 54.
Вот как-то так, дядько...
Altlinux LXDE тоже загружается чуть быстрее, чем за минуту. Ну и зачем тогда вся эта мудристика? Где выигрыш?

[gumanzoy]

На старых материнских платах, у которых BIOS при загрузке с USB накопителей умеет только USB 2.0 Full Speed (12Mbit/s) а не Hi-Speed (480Mbit/s) загрузка ядра и initrd из загрузчика может занимать минуту и более. Имено для этого случая минимальный размер ядра + initrd важен.
Плохой пример iso xubuntu 22.04 initrd.gz 113Mb.
Замерить секунды на данный момент не могу, железа под рукой нет. Примерно посчитать можно
12Mbit/s это 1.5Mb в минуту.
113Mb будет загружать 75 секунд.
10Mb 7 секунд.

Дальше уже когда ядро линукс взяло управление скорость USB нормальная Hi-Speed (480Mbit/s) и разницы в скорости загрузки модулей нет.
На таких платах (на этапе загрузчика) гораздо быстрее загрузка по сети через PXE 100Mbit/s примерно 12Mb в минуту.
113Mb будет загружать 10 секунд.

[DdShurick]

размер ядра + initrd

"От перемены мест слагаемых сумма не меняется", иначе говоря, переместив минимально необходимый набор модулей из ядра в initrd мы ничего не выигрываем, зато теряем время на подгрузку модулей, плюс нужен udev + kmod для их загрузки. Короче, сплошные минусы. Не понимать этого...... даже слов приличных нет.

[gumanzoy]

размер ядра + initrd

"От перемены мест слагаемых сумма не меняется", иначе говоря, переместив минимально необходимый набор модулей из ядра в initrd мы ничего не выигрываем, зато теряем время на подгрузку модулей, плюс нужен udev + kmod для их загрузки.

Все верно. Против монолитного ядра ничего не выиграть. Но оно будет загружаться только если на этапе сборки все необходимое вкомпилено.
Пример с размером initrd привел как бывает в других дистрибутивах. 113Mb не предел наверно, можно еще жирнее. Навключать разных firmware туда.
Как уже ранее писал в DogLinux и Slax initrd без udev + kmod. Только busybox. Так что так тоже можно, несмотря на минусы в виде не нужных остающихся в памяти модулей ядра.

[sfs]

ядро и initrd ~1сек

hdd или ssd?

зачем тогда вся эта мудристика? Где выигрыш?

Выигрыш - система сборкив возможности пересборки инитрд под любую задачу. Пара сек при загрузке никого не впечатлят

"От перемены мест слагаемых сумма не меняется", иначе говоря, переместив минимально необходимый набор модулей из ядра в initrd мы ничего не выигрываем,

Выигрываем память. udeb подгружает только те модули ядра, которые нужны этому железу. В монолитном ядре безвариантно  загружается куча ненужного именно этому железу. Подгрузка модулей без юдев  (как в debiandog) - это аналог монолита

думай от том, что останется болтаться в памяти

С этого момента поподробнее... Это принципиально важно.
Разве после загрузки основной системы что-то остается в памяти от initrd (если специально не скопировали )
Насколько я понимаю - нет. Только ядро и его модули

Initrd состоит из различных исполняемых файлов и драйверов, которые позволяют
смонтировать настоящую корневую файловую систему, после чего initrd
размонтируется и освобождается память.

нужен udev + kmod для их загрузки. Короче, сплошные минусы.

При наличии системы сборки инитрд - собирайте как хочется - с юдев или без