Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein <klark.devel@gmail.com>]

17.04.2019 19:16, Антон Мидюков пишет:
> Я собираюсь заняться профилями. Но у меня вопрос: без поддержки cdrom 
> в make-initrd собранные ISO не загрузятся в виртуалке?

Когда legion@ реализует замену пропагаторному методу "cdrom", и, в 
зависимости от того, как он это реализует, тогда и будет смысл 
задумываться о выкидывании пропагатора из профилей. По идее, там должны 
быть минимальные изменения, поскольку необходимый функционал пропагатора 
должен будет переехать в make-initrd. Если выкинуть пропагатор сейчас, с 
созданного гибридного ISO-шника загрузиться по стандарту El-Torito и по 
спецификации UEFI будет нельзя, поскольку сейчас make-initrd сам не 
умеет влезать в squashfs и делать R/W-слои над ним.


> А с флэшки загрузятся?
>

Да. Также, как и по сети с NFS. Для этого уже сейчас можно взять любой 
ранее созданный ISO-шник, взять из его корня stagename-файл (squashfs) и 
его распаковать (как вариант -- тупо скопировать dd'ой) на отдельный 
раздел в случае флэшки или распаковать в отдельный каталог на сервере 
NFS. Это будет read-only rootfs. Далее надо смотреть, что из скрипта 
make-initrd-propagarot.git@init-bootom надо перетащить ещё в initramfs, 
чтобы заработало R/W-монтирование корня через overlayfs. Тут какой-то 
опыт уже есть у Михаила Кангина.

При этом придётся учитывать, что версия ядра, модулей в rootfs и в 
initramfs должны быть одинаковыми. На флэшку придётся ставить какой-то 
загрузчик, тот же syslinux. Скрипт init-bootom мы хотели в любом случае 
сохранить для совместимости, надо будет его перекладывать в тот же 
make-initrd. А проще всего сейчас проверять новый make-initrd, 
подсовывая нужные параметры QEMU (kernel=, initrd=, append=), тогда 
вообще на тему загрузки в тестовых целях можно пока не париться.


> Также вопрос, каким образом собрать initrd с максимумом модулей?
>

Вот об этом было моё предыдущее письмо, про всеядный initrd.img -- в 
него попадут все модули и прошивки, вообще все, что есть в stage2. Но 
для полноты стоит заказать фичи типа lvm, mdadm и всего остального, что 
умеет работать с носителями. Если же ориентироваться на нашу 
дистрибутивную логику, то в пакете propagator есть mkmodpack, к нему 
есть ответная часть в профилях m-p и в скриптах mkimage 
(tools/mki-build-propagator). Вместе они создают наборы модулей и 
фирмвари для всех наши универсальных установочных дисков live, rescue и 
install.

Только там всегда чего-нибудь не хватает, потому что мы пытаемся 
построить замыкание по какому-то принципу. У меня "все" заняли 1.1Гб без 
всяких фич -- это огромный объём, для экспериментов на хорошем железе 
сойдёт, чтобы не заморачиваться. Но для продакшена такой вариант не 
годится. Ведь "все" и не нужны -- к примеру, зачем в initramfs все 
модули ТВ-тюннеров или звуковых карт? А строить замыкание тоже можно 
по-разному...

Сейчас список модулей определяется именно в m-p -- как раз твоя часть. 
Беда в том, что за этим списком наши ядерщики не "ухаживают", я эту 
проблему озвучивал ldv@, mike@ и boyarsh@. С этой позиции лучше 
исключать заведомо ненужное, пусть лучше в initramfs лишнее попадёт. 
Кое-что для включения предпринял legion@, какой-то опыт подборки нужного 
есть у Михаила Кангина. Вот здесь давно пора объединять усилия, 
оглядываясь на dracut и live-boot.


> 17.04.2019 22:36, Michael A. Kangin пишет:
>> On 04/17/2019 05:26 PM, Leonid Krivoshein wrote:
>>
>>> Вот вся документация:
>>> https://github.com/legionus/make-initrd/tree/master/docs
>>
>> Да, это я уже всё пролазил. В общем, можно считать, что документации 
>> практически нету.
>>
>>
>>> Поэтому проще ориентироваться на исходники и уже готовые фичи...
>>
>> Я уже попробовал так сделать в первый раз. Оно заработало, но 
>> получилось так себе. И, как теперь выясняется, надо всё переделывать 
>> под новую версию.
>>


-- 
Best regards,
Leonid Krivoshein.