[devel] Модульный initrd.img

[Leonid Krivoshein]

Добрый вечер!


06.05.2018 19:55, Michael A. Kangin пишет:
> Здравствуйте!
>
> Не секрет, хотя и не широкоизвестно, что популярные загрузчики 
> позволяют указывать несколько cpio-образов, которые при загрузке будут 
> объединены в памяти в единую initramfs.
>

Равно как и то, что склеить initrd можно из нескольких кусков уже на 
этапе генерации. Если не ошибаюсь, наш mkmodpack создаёт отдельный кусок 
с модулями ядра.


> Этим можно воспользоваться, и разделить текущий монолитный initrd.img 
> на отдельные образы - собственно сам initrd, early-микрокод, и модули 
> ядра [с фирмварью].
>

Если не ошибаюсь, ucode для initel/amd у нас тоже сейчас отделён. Цена 
вопроса в любом из вариантов -- выравнивание кусков по 4Кб границам, 
если не ошибаюсь, они склеиваются не встык, а должны выравниваться по 
границам размера страницы.


> Зачем это может быть нужно?
> - ускорение генерации новых initrd при установке нового ядра. Если 
> микрокод и само тело initrd остаётся такими же, достаточно только 
> быстренько слепить образ с новыми модулями.

Это значит капитально переделывать инструмент генерации initrd, другие 
дистрибутивные инструменты, которые это должны поддерживать. Ради чего? 
Так ли уж долго генерируется initrd? И ведь нужно ещё вести учёт того, 
что менялось, а что нет.


> - уменьшение суммарного размера микрокода / разных вариантов initrd / 
> разных версий ядра. Например, мы выносим микрокод отдельным образом - 
> и нам не нужно включать его в каждую новую версию initrd, которую мы 
> делаем. Если мы генерим себе -debug initrd, то достаточно сделать 
> крохотный diff-образ с bash / lsmod / whatever, а модули и основной 
> initrd у нас уже есть. Мы можем предложить загрузить на выбор std-def 
> и un-def, причём разница (кроме самих vmlinuz'ов) будет достаточно 
> небольшая, архивы из десятка модулей ядра.

Для решения конкретных задач всё равно будут пары ядро+initrd, а любые 
попытки приведут к небольшому увеличению конечного образа, но не наоборот.


> - возможность оперативно фиксить уже существующий initrd, добавив 
> сбоку в отдельном образе или недостающий модуль, или конфиг там какой 
> со скриптом.

Чтобы его оперативно пофиксить сейчас достаточно сказать make-initrd.


> - возможность полностью отвязать сам initrd от версии ядра. И иметь 
> возможность загрузить систему с, например, RHEL-овским ядром, но нашим 
> initrd, не ломая никакой совместимости.
>

make-initrd умеет класть в образ initramfs любые файлы и сейчас.


> Минимальная поддержка, необходимая в initrd для сторонних образов с 
> модулями - вызов "depmod -a" перед загрузкой модулей, например, в 
> стадии pre-udev. Если сторонние образы содержат что-то другое, то и 
> поддержки особой не надо.
>

Сейчас автоугадав взаимных зависимостей модулей работает на этапе 
генерации initrd. Чего же хорошего в переносе этой длительной операции 
на этап КАЖДОЙ (!) загрузки машины?


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

Так и сейчас чтобы сгенерировать initrd с определёнными фичами или 
наоборот, без них, достаточно подправить /etc/initrd.mk и сказать 
make-initrd. Именно так можно избавиться от плимута, к примеру.


> Вот пара вполне работающих примеров:
>
> syslinux с семейством (iso, pxe):
> =======================
> LABEL test-modular-initrd
> MENU LABEL Test modular initrd
> KERNEL clb/vmlinuz
> INITRD clb/microcode.img,clb/initrd-thin.img,clb/supermicro_boot.modules
> APPEND root=http://xxxxx/rescue-base-sm.manifest rootdelay=5
> =======================
> Работает как с legacy bios, так и с uefi.
>
> grub2:
> =======================
> ...
> echo    'Loading Linux 4.9.71-std-def-alt0.M80P.1 ...'
> linux   /boot/vmlinuz-4.9.71-std-def-alt0.M80P.1 
> root=UUID=a397ac93-3b06-4023-83e4-18b29a28b033 ro  quiet 
> resume=/dev/disk/by-uuid/6481d48d-8403-4049-adfc-87e94b950361 panic=30 
> splash
> echo    'Loading initial ramdisk ...'
> initrd  /boot/microcode.img 
> /boot/initrd-4.9.71-std-def-alt0.M80P.1-thin.img /boot/modules.img
> =======================
> c uefi не пробовал.
>
> Так же, не знаю, умеют ли это хитрые uefi-загрузчики типа refind'а.

Даже если не умеет загрузчик, куски можно склеить заранее. И получить 
всё тот же монолитный initrd. Но зачем? Ведь в конечном итоге для 
решения конкретной задачи эти куски попадают на обработку всё равно уже 
в склееном виде.


-- 
Best regards,
Leonid Krivoshein.