From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 6 Apr 2021 10:28:42 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210406082842.pg3rejmmnxuxvddf@example.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 08:28:43 -0000 Archived-At: List-Archive: 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