From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=iq7Gs5sJowVYW3KuZD4gLs4IvLn3NPOMsJIFM6oppHU=; b=YsCFJiWCVVqB2RTPXziqMN/yaI/MLChTNpqEqgBxA/A181bF+dlva4fmBfFafg8SVJ 6S74pPY2kk9DJWIn3N+UHf42Jw+GSpP7w1PYoeQt3jDlPZ2d8meWV9A4Cy9VcCVG2PqD 3oxkYo31FxXOjMMMmROYgQcMMKQtI8nrM8eqZzoAFQqSWUBXV4ioPOBVciFvEgM1qUct PnoHWNOpGJLkSgBKprb82pLIhROkcMVLBda/X83kWctIvWenbx/I2iLsm7ncoX4iAiJ5 MewCwBTqg2qJ++BNR+lO0bustEAp6NL57Yn86pso4/ZBlhr/yd1LvI/BjbxP0DTlaZX6 GZmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iq7Gs5sJowVYW3KuZD4gLs4IvLn3NPOMsJIFM6oppHU=; b=uWxP2zPk0EkxPIOc9WHaDl7NgKmjAFTwGgfuQfoMGtvHFQXq49PDgdZroztQlrpr1E QNa3rz0Q9OZhb0nkMncEF1zB95Dnr2wf/U8gk7wKWViX0sxsE0uxYnX+qc7gtlHkTW+f hSgZifQHAsPFbpKD+nUEvgY9F3j6unKFdhj7ivFUmM8wBo3FWOqwxen4blC4AJ7ASP8A /vQ+e+dC2qwe2YZZBLrDR7EcfJEhWHzGJdLbGaWa6jcbrOsvfyc1yNxhQHKso+uZ4Vx1 TH74bd1vruDaLmGIu0cC0oiXhOhgPUp4ZjOJu4HLIm3wpi9Czc1fYnh/z9bktpwgh2+3 nMkw== X-Gm-Message-State: AOAM531h5ewz51Cg0E+Kr5DMEzpvneV4HJa6wtaSFfEJLiWmtZh7cBjj I5Py9xlhGVfiBifr6cMtJZ3cLVihP/8= X-Google-Smtp-Source: ABdhPJxHQZrxnjk+XoYvbICf0yvFew1yyUxhTyQOEsXyCdSQQJgRQ6owdwz4vEiyfY5MWKJwG8lpoQ== X-Received: by 2002:a05:6512:c1a:: with SMTP id z26mr20398517lfu.360.1617727130129; Tue, 06 Apr 2021 09:38:50 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20210406082842.pg3rejmmnxuxvddf@example.org> From: Leonid Krivoshein Message-ID: <52bf94c7-8653-9ce0-8f69-da689581fac0@gmail.com> Date: Tue, 6 Apr 2021 19:38:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210406082842.pg3rejmmnxuxvddf@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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 16:38:55 -0000 Archived-At: List-Archive: 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 2>&1 потому что interactive_off() делать и сам pipeline должен в идеале, если на выходе этого не сделано в шаге. >> В целом, хотелось услышать твоё мнение, чего с этим делать дальше? Строить >> ли рядышком с готовыми кусками шаги пропагаторного стека, как сейчас в >> черновом варианте, делать замену пропагатора отдельной фичей make-initrd или >> дождёшься (разрешишь) когда я перелопачу pipeline под новый лад и чуть >> больше адаптирую под пропагатор? > Я вполне допускаю, что pipeline вам не подойдёт для переписывания > propagator. Подойдёт. Уже получилось же. > Я об этом писал с самого начала. Если она не подходит, то вы > можете написать свою фичу с блэкджэком и обратной совместимостью. Правда в > последнем случае, кажется, она уже есть - make-initrd-propagator. Чтобы тебе не мешать, я временно отделю код фичи и буду работать с ним локально, мне так быстрее и тебе не будут приходить уведомления. А по готовности обсудим переработанное. -- Best regards, Leonid Krivoshein.