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

[Alexey Gladkov]

On Tue, Apr 06, 2021 at 07:38:48PM +0300, Leonid Krivoshein wrote:
> 
> 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 это всего лишь tmpfs с капелькой мозгов про устройства. Я выбрал его
потому что:

1. Всё что в /dev/pipeline имеет непосредственное отношение к корню
   системы. Это тоже место, что и /dev/cdrom.

2. Он переносится в целевую систему. Таким образом не нужно опасаться, что
   он потеряется.

3. Это файловая система отличная от initramfs, потому что switch_root
   убьёт корень initramfs.

Если это так бомбит, то можно использовать /run или смонтировать в
/dev/pipeline ещё одну tmpfs. Хотя это всё та же память и просто
добавляется точка монтирования.

> Кроме /dev у тебя в stage2 передаётся /run (+$EXPORT_FS), а для ISO-образов
> /dev/ramN самое оно.

Да можно и /run использовать.

> оставлять что-либо в /dev/pipeline или /dev/.initrd (как раньше) -- нет,
> только что-то совсем небольшое и лучше в /run. Говорю как пользователь
> твоего продукта, как следует его "пощупав". ))

Вот бы вы "щупали" не спустя год после создания фичи ))

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

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

Нет. Если монтировать внахлёст, то часть вещей сделать просто не
получится.

В текущей схеме ты можешь скачать образ, смонтировать его смонтировать
флешку и потом объединить их overlayfs. Чтобы это было возможно тебе нужно
иметь две точки монтирования для оверлея, а также нужно уметь адрессовать
их. В pipeline для каждого шага доступны результаты всех предыдущих, а не
только предыдущий.

В пропагаторе всё делалось внахлёст, потому что это монолитный скрипт.

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

Я вижу :)

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

Я старался, чтобы не получилось (шучу).

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

Я как раз и надеялся, что будет произведена декомпозиция пропагатора. Да,
это непростая работа.

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

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

> Основное: я считаю, что шаг может использовать каталоги, предоставляемые
> pipeline, но не обязан этого делать, он с тем же успехом может делать нужное
> в initramfs.

Да. Именно так.

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

Вот именно потому что я не могу знать нужны или нет все звенья я их
переношу в систему. Ты всегда можешь сделать шаг prune и параметром (или
ещё как-нибудь) указать ему какие стадии удалить.

> > Что именно не вписывается в парадигму pipeline ?
> 
> Мне кажется, тебе лучше показать это сразу на bash. :-)

Ты мне хочешь показать на bash, что не вписывается в парадигму ?! ))
Может лучше всё-таки словами ? )))

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

Да нет же. Ты получаешь доступ ко _всем_ предыдущим шагам. Ты можешь к ним
обращаться pipeN, N это номер шага.

> Как написать универсальный шаг, который обработает результаты нескольких
> предыдущих? Передавать этому шагу номера 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
> > 
> > Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
> > синтаксисе ?
> 
> Давай я всё хорошенько обдумаю и предложу реализацию. Не скоро.

Ок.

> } </dev/console >/dev/console 2>&1
> 
> потому что interactive_off() делать и сам pipeline должен в идеале, если на
> выходе этого не сделано в шаге.

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

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

Ок.

-- 
Rgrds, legion