From: Leonid Krivoshein <klark.devel@gmail.com> To: make-initrd@lists.altlinux.org Subject: Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 Date: Tue, 6 Apr 2021 19:38:48 +0300 Message-ID: <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> (raw) In-Reply-To: <20210406082842.pg3rejmmnxuxvddf@example.org> 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.
next prev parent reply other threads:[~2021-04-06 16:38 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-05 20:33 ` Leonid Krivoshein 2021-04-05 22:51 ` Leonid Krivoshein 2021-04-06 8:44 ` Alexey Gladkov 2021-04-06 17:38 ` Leonid Krivoshein 2021-04-07 13:13 ` Alexey Gladkov 2021-04-06 8:28 ` Alexey Gladkov 2021-04-06 16:38 ` Leonid Krivoshein [this message] 2021-04-06 19:05 ` Alexey Gladkov 2021-04-06 19:30 ` Alexey Gladkov 2021-04-06 23:13 ` Leonid Krivoshein 2021-04-07 12:28 ` Alexey Gladkov 2021-04-06 23:00 ` Leonid Krivoshein 2021-04-07 12:11 ` Alexey Gladkov 2021-04-06 23:59 ` Leonid Krivoshein 2021-04-07 1:51 ` Leonid Krivoshein 2021-04-07 12:57 ` Alexey Gladkov 2021-04-07 18:29 ` Leonid Krivoshein 2021-05-26 15:05 ` Leonid Krivoshein 2021-05-26 18:12 ` Alexey Gladkov 2021-05-26 19:25 ` Leonid Krivoshein 2021-05-27 8:37 ` Alexey Gladkov 2021-05-27 12:29 ` Leonid Krivoshein 2021-05-27 13:53 ` Alexey Gladkov 2021-05-27 15:10 ` Leonid Krivoshein 2021-05-27 17:04 ` Alexey Gladkov 2021-05-27 17:11 ` Leonid Krivoshein 2021-05-30 20:34 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com \ --to=klark.devel@gmail.com \ --cc=make-initrd@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git