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

Tue Apr 6 19:38:48 MSK 2021

06.04.2021 11:28, Alexey Gladkov пишет:
> 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 как прозрачную замену пропагатору.

Здесь ключевой момент в "прозрачности", ведь изначально pipeline и 
планировался стать его заменой. Что-ж, в какой-то степени даже 
"прозрачность" уже почти удалось достичь в черновом варианте на 
имеющейся реализации, хоть и немного вприпляску. :-)

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

Да, это стало и для меня неожиданностью. Мы больше проблем огребли не 
из-за реализации pipeline, а "чёрной магии". :-) Вот, к примеру, 
старинный код установщика: 
git.altlinux.org/gears/i/installer.git?p=installer.git;a=tree;f=installer/preinstall.d;h=557418ee9fd39cb82f4b49c8011bbf6a979dbf9a;hb=dc571fadc9a7c42609b6bcdde89e53182f1802a6 
-- тут тоже на первый взгляд магия: на этом месте установка спотыкается 
при указании параметра lowmem, а всё потому, что в 35 строке 
http://git.altlinux.org/gears/i/installer.git?p=installer.git;a=blob;f=installer/src/losetup-move.c;h=afb1c436f4faa36317e9ccef0272ad46a029e95a;hb=dc571fadc9a7c42609b6bcdde89e53182f1802a6#l35 
ioctl фейлится, когда вторым парамтром указан /dev/ram3. Вообще данный 
код видимо изначально подразумевал копирование файла второй стадии с 
извлекаемого CD-ROM в безопасное место и переключение backing device на 
него без учёта того, что этот файл уже может находиться в безопасном 
месте (/dev/ram3).

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

Нет, мы же решили от него уходить. Но и регрессий нам не нужно.
А ошибки, выявляемые по ходу, будем исправлять и в stage2, куда же без 
этого.

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

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

Вопрос в опциях монтирования /dev/pipeline -- хотя бы как /dev с 
ограничением в 5-8Мб и noexec/nosuid. Ведь там ничего, кроме DEV-файлов 
и каталогов, куда должны ещё монтироваться другие каталоги, вообще быть 
не должно. Нынешняя реализация getimage с передачей ISO-образа через 
/dev/pipeline/dst/pipe1, по-моему, заслуживает пересмотра. Ну не место 
это для хранения ISO-образов.

Кроме /dev у тебя в stage2 передаётся /run (+$EXPORT_FS), а для 
ISO-образов /dev/ramN самое оно. Чистить initramfs перед switch_root -- 
правильно, оставлять что-либо в /dev/pipeline или /dev/.initrd (как 
раньше) -- нет, только что-то совсем небольшое и лучше в /run. Говорю 
как пользователь твоего продукта, как следует его "пощупав". ))

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

Даже если монтировать "внахлёст" в один каталог, проблем не возникает и 
можно передавать от одного шага к другому.

> Затруднительно
> даже поменять порядок внутри уже реализованного.

Если реализуется отдельными шагами, как сейчас, не вижу проблем.

> В такой парадигме только
> такой же монолит будет работать также.

В рамках pipeline не выйдет реализовать монолит, я пытался.
А вот разбить на части удалось. Их можно переставлять, перемешивать с 
нативными.

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

Будет очень обидно потратить много времени на улучшение реализации и 
потом не смочь тебя убедить, что так лучше. :-) Но я всё же попробую, 
сохранив основные очертания. Ты бы на код посмотрел.

Основное: я считаю, что шаг может использовать каталоги, предоставляемые 
pipeline, но не обязан этого делать, он с тем же успехом может делать 
нужное в initramfs. Потому что задача initramfs -- добраться до корня и 
самоуничтожиться, а задача pipeline -- предоставить шагам логичный 
интерфейс для этого. Конечный результат переносится в $rootmnt, нынешняя 
реализация заставляет тянуть в будущий корень промежуточные звенья всей 
pipeline, а они там могут быть совсем не нужны, по крайней мере, заранее 
ты этого не можешь знать.

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

Мне кажется, тебе лучше показать это сразу на bash. :-)

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

Согласен.

>> 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
>> каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
>> устройств?
> pipeline=waitdev,waitdev,... \
> 	waitdev=/dev/cdrom \
> 	waitdev=/dev/sda
>
> Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
> не обязательно, что на выходе должно быть что-то, что будет монтироваться.
> Это может быть шаг с диалоговым окном для корректировки поведения
> следующих шагов.

Хорошо, дождались нескольких устройств. Выход получили только от 
последнего. Как написать универсальный шаг, который обработает 
результаты нескольких предыдущих? Передавать этому шагу номера pipe'ов 
через cmdline? Да и, в случае waitdev, первый ждёт. И только когда 
дождался, ждёт второй. И так далее. А если результаты каждого должны 
быть обработаны независимо, то это выстраивание в строгую 
последовательность вместо параллельной обработки.

> Негибкость, которая тут есть это невозможность ветвления т.е.
> невозможность определить другие последующие шаги из предыдущего. Я думал
> об этом и у меня есть идеи как такое можно реализовать.
>
> [1] https://github.com/osboot/make-initrd/issues/2

Знаком с этим обсуждением, но указанных идей там не видел. К слову, я 
думаю, у этого разработчика проблемы с ID_* потому, что в образ initrd 
собирается тулза (pcscd) с отпиленной поддержкой systemd, чтобы не 
тащить туда целиком весь стек зависимостей systemd, и когда токен 
"расшифровывается", эти ID_* стали бы доступны автоматом, т.к. udev их 
перечитал бы заново, но раз он собрал без systemd, этого не происходит. 
Я бы предложил ему по эвенту отработать какой-нибудь udevadm info... Но 
у меня пока нет аккаунта на гитхабе.

>> Выход ведь будет только у одного. Если именовать всю 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).

Да, я это понял и уже использовал. Имел ввиду что-то типа штатной:

interactive_on()
...
interactive_off()

вместо:

{
...
} </dev/console >/dev/console 2>&1

потому что interactive_off() делать и сам pipeline должен в идеале, если 
на выходе этого не сделано в шаге.

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

Подойдёт. Уже получилось же.

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

Чтобы тебе не мешать, я временно отделю код фичи и буду работать с ним 
локально, мне так быстрее и тебе не будут приходить уведомления. А по 
готовности обсудим переработанное.

-- 
Best regards,
Leonid Krivoshein.