From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 6 Apr 2021 21:05:32 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210406190532.ujqp7edd3niul4n6@example.org> References: <20210406082842.pg3rejmmnxuxvddf@example.org> <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> 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 19:05:34 -0000 Archived-At: List-Archive: 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 2>&1 > > потому что interactive_off() делать и сам pipeline должен в идеале, если на > выходе этого не сделано в шаге. Каждый шаг это отдельная программа. Если ты переоткроешь дескрипторы, то он будут открыты только для этого шага. > > Я об этом писал с самого начала. Если она не подходит, то вы > > можете написать свою фичу с блэкджэком и обратной совместимостью. Правда в > > последнем случае, кажется, она уже есть - make-initrd-propagator. > > Чтобы тебе не мешать, я временно отделю код фичи и буду работать с ним > локально, мне так быстрее и тебе не будут приходить уведомления. А по > готовности обсудим переработанное. Ок. -- Rgrds, legion