Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Mon, Apr 05, 2021 at 11:33:14PM +0300, Leonid Krivoshein wrote:
> Алексей, привет!
> 
> 
> Снова я, и снова про pipelinie. :-)
> 
> Очень черновая сборка для обсуждения готова. Она не для того, чтобы её
> апстримить. Образы (любые -- live, altinst, rescue) с этим уже можно
> собирать. Несколько дней бодались с одной проблемой и наконец удалось её
> победить. Но сейчас немного о другом -- мысли и пожелания вокруг pipeline...
> 
> 1. Фича pipeline делалась на замену пропагатора видимо без учёта
> особенностей его работы. Разница оказалась ощутимой и для бесшовного
> перехода из stage1 в stage2 без необходимости править нынешние профили
> дистрибутивов, приходится идти на компромиссы и ухищрения. Менять stage2 под
> pipeline вообще не вариант -- мы даже не знаем, где, когда и что выстрелит,
> и как это тестировать.

Я никогда не планировал pipeline как прозрачную замену пропагатору. Я даже
не пытался наследовать его волшебные параметры поскольку это чёрная магия.

Я хорошо понимаю твои опасения и боль, но если ты не хочешь регрессий, то
продолжай использовать propagator. Иначе изменения в поведении и
параметрах будут.

> 2. В интерфейс pipeline не выведена уже реализованная в make-initrd
> возможность работы с /proc/cmdline. Имею ввиду общие параметры, такие как
> lowmem, live или rescue. У каждой фичи -- свои аргументы. Пока не удалось
> побороть эту проблему, мой "config" оказался нерабочим. Может, нужно просто
> инклюдить какой-то файл?

Я не понял вопроса. Cтрока /proc/cmdline парсится и это окружение
сохраняется в /.initrd/initenv .

> 3. /dev/pipeline/* -- длинные пути в mtab, не только монтируемые каталоги,
> но и устройства. Даже если это имеет право на жизнь в stage1, при переходе в
> stage2 оно должно умереть, как и не секьюрно смонтированный /dev/pipeline,
> куда можно загружать даже ISO'шки. :-) Вместо передачи dev и каталогов можно
> передавать симлинки на них (в дополнение), да и сам devname вместо dev
> передавать куда правильней, по-моему.

Я не понял этого пункта. Все компоненты цепочки должны быть доступны если
только не копировать их в ram-диск. Сделать недоступность можно только
если разместить все компоненты вне mntroot и /dev, который переносится в
mntroot, но в этом случае придётся не удалять initramfs.

О какой секьюрности речь если ты передаёшь управление в mntroot руту ?

> 4. Сделать замену пропагатора одним большим монолитным куском в рамках
> pipeline нельзя. Как сейчас -- гармоничнее и можно чередовать куски из
> "пропагаторного стека" с нативными. Но есть проблемы [1] и [2]. Пропагатор
> монтирует всё внахлёст в /image, /root и /dev/ramN, при это он ещё
> отмонтирует и много чего другого делает, что не вписывается в парадигму
> pipeline.

Порядок этого "монтирования внахлёст" жёстко определён.  Затруднительно
даже поменять порядок внутри уже реализованного. В такой парадигме только
такой же монолит будет работать также. Pipeline же спроектирована так,
чтобы в рамках одного синтаксиса можно было описывать разный порядок
стадий и иметь параметры у этих стадий.

Что именно не вписывается в парадигму pipeline ?

Кстати, совершенно не обязательно зацикливаться на использовании
/proc/cmdline как источника конфигурации. Вполне возможно написать
вандерфичу, которая "включит" pipeline. Также можно написать специфичные
шаги для pipeline, которые будут читать не один параметр из cmdline, а
собственный конфиг. Это всё зависит от решаемой задачи.

> 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
> каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
> устройств?

pipeline=waitdev,waitdev,... \
	waitdev=/dev/cdrom \
	waitdev=/dev/sda

Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
не обязательно, что на выходе должно быть что-то, что будет монтироваться.
Это может быть шаг с диалоговым окном для корректировки поведения
следующих шагов.

Негибкость, которая тут есть это невозможность ветвления т.е.
невозможность определить другие последующие шаги из предыдущего. Я думал
об этом и у меня есть идеи как такое можно реализовать.

[1] https://github.com/osboot/make-initrd/issues/2

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

Я пока не вижу нужды в таком усложнении как несколько pipeline. Технически
такое возможно, но зачем.

> 6. Я бы облегчил возможность определение одной pipeline
> с: pipeline=waitdev,mountfs,mountfs,rootfs waitdev=/dev/name mounfs=ISO
> mountfs=squash
> до: pipeline=waitdev=/dev/name,mountfs=ISO,mountfs=squash,rootfs
> т.е.: pipeline=step1[=arg1[:arg2...]][,step2[=arg1[:arg2...]]...] и
> регистрировал бы их автоматически.

Это сразу наложит ограничение на использование запятой в аргументе. А она
уже используется как разделитель например в опциях монтирования. Недавно я
предлагал вариант передачи дополнительных параметров монтирования:

pipeline=waitdev,mountfs \
	waitdev=/dev/sda \
	mountfs=/dev/sda:nodev,noexec,mode=620

Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
синтаксисе ?

> 7. Интерактивный ввод-вывод на этапе работы pipelined невозможен, разве что
> перенаправить ограниченный код в /dev/console. У пропагатора по ходу это
> было востребовано, что логично. Ну, хотя бы индикация загрузки больших
> образов, запрос режимов и источников загрузки. Хотелось бы во время работы
> шага прервать "фоновое" выполнение и перейти в интерактив, потом вернуться
> обратно.

Использование /dev/console является штатным механизмом. Им пользуются
скрипты, которым нужен интерактив с пользователем (например luks).

> В целом, хотелось услышать твоё мнение, чего с этим делать дальше? Строить
> ли рядышком с готовыми кусками шаги пропагаторного стека, как сейчас в
> черновом варианте, делать замену пропагатора отдельной фичей make-initrd или
> дождёшься (разрешишь) когда я перелопачу pipeline под новый лад и чуть
> больше адаптирую под пропагатор?

Я вполне допускаю, что pipeline вам не подойдёт для переписывания
propagator. Я об этом писал с самого начала. Если она не подходит, то вы
можете написать свою фичу с блэкджэком и обратной совместимостью. Правда в
последнем случае, кажется, она уже есть - make-initrd-propagator.

-- 
Rgrds, legion