Make-initrd development discussion
 help / color / mirror / Atom feed
* [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  @ 2021-04-05 20:33 ` Leonid Krivoshein
  2021-04-05 22:51   ` Leonid Krivoshein
  2021-04-06  8:28   ` Alexey Gladkov
  0 siblings, 2 replies; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-05 20:33 UTC (permalink / raw)
  To: make-initrd

Алексей, привет!


Снова я, и снова про pipelinie. :-)

Очень черновая сборка для обсуждения готова. Она не для того, чтобы её 
апстримить. Образы (любые -- live, altinst, rescue) с этим уже можно 
собирать. Несколько дней бодались с одной проблемой и наконец удалось её 
победить. Но сейчас немного о другом -- мысли и пожелания вокруг pipeline...

1. Фича pipeline делалась на замену пропагатора видимо без учёта 
особенностей его работы. Разница оказалась ощутимой и для бесшовного 
перехода из stage1 в stage2 без необходимости править нынешние профили 
дистрибутивов, приходится идти на компромиссы и ухищрения. Менять stage2 
под pipeline вообще не вариант -- мы даже не знаем, где, когда и что 
выстрелит, и как это тестировать.

2. В интерфейс pipeline не выведена уже реализованная в make-initrd 
возможность работы с /proc/cmdline. Имею ввиду общие параметры, такие 
как lowmem, live или rescue. У каждой фичи -- свои аргументы. Пока не 
удалось побороть эту проблему, мой "config" оказался нерабочим. Может, 
нужно просто инклюдить какой-то файл?

3. /dev/pipeline/* -- длинные пути в mtab, не только монтируемые 
каталоги, но и устройства. Даже если это имеет право на жизнь в stage1, 
при переходе в stage2 оно должно умереть, как и не секьюрно 
смонтированный /dev/pipeline, куда можно загружать даже ISO'шки. :-) 
Вместо передачи dev и каталогов можно передавать симлинки на них (в 
дополнение), да и сам devname вместо dev передавать куда правильней, 
по-моему.

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

5. Исходная идея pipeline -- организовать цепочку с входом и выходом у 
каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х 
устройств? Выход ведь будет только у одного. Если именовать всю 
pipeline, сделать таких цепочек несколько и в каждой сделать свой 
waitpipe, можно строить более сложную логику загрузки их разных 
устройств и типов источников, синхронизируя события в других цепочках.

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...]]...] и 
регистрировал бы их автоматически.
Возможно, это также поможет решить проблему [2].

7. Интерактивный ввод-вывод на этапе работы pipelined невозможен, разве 
что перенаправить ограниченный код в /dev/console. У пропагатора по ходу 
это было востребовано, что логично. Ну, хотя бы индикация загрузки 
больших образов, запрос режимов и источников загрузки. Хотелось бы во 
время работы шага прервать "фоновое" выполнение и перейти в интерактив, 
потом вернуться обратно.


В целом, хотелось услышать твоё мнение, чего с этим делать дальше? 
Строить ли рядышком с готовыми кусками шаги пропагаторного стека, как 
сейчас в черновом варианте, делать замену пропагатора отдельной фичей 
make-initrd или дождёшься (разрешишь) когда я перелопачу pipeline под 
новый лад и чуть больше адаптирую под пропагатор?




-------- Перенаправленное сообщение --------
Тема: 	[#269003] TESTED make-initrd.git=2.14.1-alt1
Дата: 	Mon, 5 Apr 2021 18:07:38 +0000
От: 	Girar awaiter (klark) <girar-builder@altlinux.org>
Отвечать: 	klark@altlinux.org
Кому: 	Leonid Krivoshein <klark@altlinux.org>
Копия: 	Alexey Gladkov <legion@altlinux.org>, 
girar-builder-sisyphus@altlinux.org, sisyphus-incominger@lists.altlinux.org



http://git.altlinux.org/tasks/269003/logs/events.1.1.log

subtask name aarch64 armh i586 ppc64le x86_64
#100 make-initrd 1:08 1:31 1:07 1:22 1:05

2021-Apr-05 18:00:48 :: test-only task #269003 for sisyphus started by 
klark:
#100 build 2.14.1-alt1 from /people/klark/packages/make-initrd.git 
fetched at 2021-Apr-05 18:00:47
2021-Apr-05 18:00:50 :: [x86_64] #100 make-initrd.git 2.14.1-alt1: build 
start
2021-Apr-05 18:00:50 :: [armh] #100 make-initrd.git 2.14.1-alt1: build start
2021-Apr-05 18:00:50 :: [aarch64] #100 make-initrd.git 2.14.1-alt1: 
build start
2021-Apr-05 18:00:50 :: [i586] #100 make-initrd.git 2.14.1-alt1: build start
2021-Apr-05 18:00:50 :: [ppc64le] #100 make-initrd.git 2.14.1-alt1: 
build start
2021-Apr-05 18:01:55 :: [x86_64] #100 make-initrd.git 2.14.1-alt1: build OK
2021-Apr-05 18:01:57 :: [i586] #100 make-initrd.git 2.14.1-alt1: build OK
2021-Apr-05 18:01:58 :: [aarch64] #100 make-initrd.git 2.14.1-alt1: build OK
2021-Apr-05 18:02:12 :: [ppc64le] #100 make-initrd.git 2.14.1-alt1: build OK
2021-Apr-05 18:02:21 :: [armh] #100 make-initrd.git 2.14.1-alt1: build OK
2021-Apr-05 18:03:05 :: #100: make-initrd.git 2.14.1-alt1: build check OK
2021-Apr-05 18:03:05 :: build check OK
warning (#100): make-initrd-devmapper-2.14.1-alt1.x86_64.rpm should be 
.noarch.rpm
warning (#100): make-initrd-luks-2.14.1-alt1.x86_64.rpm should be 
.noarch.rpm
warning (#100): make-initrd-lvm-2.14.1-alt1.x86_64.rpm should be .noarch.rpm
warning (#100): make-initrd-mdadm-2.14.1-alt1.x86_64.rpm should be 
.noarch.rpm
warning (#100): make-initrd-multipath-2.14.1-alt1.x86_64.rpm should be 
.noarch.rpm
warning (#100): make-initrd-nfs-2.14.1-alt1.x86_64.rpm should be .noarch.rpm
warning (#100): make-initrd-plymouth-2.14.1-alt1.x86_64.rpm should be 
.noarch.rpm
2021-Apr-05 18:03:15 :: noarch check OK
2021-Apr-05 18:03:17 :: plan: src +1 -1 =17879, aarch64 +9 -9 =29722, 
armh +9 -9 =27791, i586 +10 -10 =30615, ppc64le +9 -9 =29607, x86_64 +10 
-10 =31101
#100 make-initrd 2.14.0-alt1 -> 2.14.1-alt1
Sun Apr 04 2021 Leonid Krivoshein <klark@altlinux> 2.14.1-alt1
- Feature pipeline: introduce propagator compatibity layer. WIP!
2021-Apr-05 18:03:53 :: patched apt indices
2021-Apr-05 18:04:02 :: created next repo
2021-Apr-05 18:04:11 :: duplicate provides check OK
2021-Apr-05 18:04:36 :: dependencies check OK
2021-Apr-05 18:04:58 :: [x86_64 i586 aarch64 ppc64le armh] ELF symbols 
check OK
warning [i586]: make-initrd=2.14.1-alt1: circular dependencies on 
bootloader-utils=0.5.3-alt1
warning [x86_64]: make-initrd=2.14.1-alt1: circular dependencies on 
bootloader-utils=0.5.3-alt1
2021-Apr-05 18:05:13 :: [i586] #100 make-initrd: install check OK
2021-Apr-05 18:05:14 :: [x86_64] #100 make-initrd: install check OK
warning [aarch64]: make-initrd=2.14.1-alt1: circular dependencies on 
bootloader-utils=0.5.3-alt1
2021-Apr-05 18:05:15 :: [aarch64] #100 make-initrd: install check OK
warning [ppc64le]: make-initrd=2.14.1-alt1: circular dependencies on 
bootloader-utils=0.5.3-alt1
2021-Apr-05 18:05:18 :: [ppc64le] #100 make-initrd: install check OK
2021-Apr-05 18:05:21 :: [x86_64] #100 make-initrd-debuginfo: install 
check OK
2021-Apr-05 18:05:21 :: [i586] #100 make-initrd-debuginfo: install check OK
warning [armh]: make-initrd=2.14.1-alt1: circular dependencies on 
bootloader-utils=0.5.3-alt1
2021-Apr-05 18:05:24 :: [aarch64] #100 make-initrd-debuginfo: install 
check OK
2021-Apr-05 18:05:24 :: [armh] #100 make-initrd: install check OK
2021-Apr-05 18:05:28 :: [x86_64] #100 make-initrd-devmapper: install 
check OK
2021-Apr-05 18:05:28 :: [i586] #100 make-initrd-devmapper: install check OK
2021-Apr-05 18:05:29 :: [ppc64le] #100 make-initrd-debuginfo: install 
check OK
2021-Apr-05 18:05:31 :: [aarch64] #100 make-initrd-devmapper: install 
check OK
2021-Apr-05 18:05:34 :: [x86_64] #100 make-initrd-luks: install check OK
2021-Apr-05 18:05:35 :: [i586] #100 make-initrd-luks: install check OK
2021-Apr-05 18:05:38 :: [armh] #100 make-initrd-debuginfo: install check OK
2021-Apr-05 18:05:38 :: [aarch64] #100 make-initrd-luks: install check OK
2021-Apr-05 18:05:38 :: [ppc64le] #100 make-initrd-devmapper: install 
check OK
2021-Apr-05 18:05:41 :: [x86_64] #100 make-initrd-lvm: install check OK
2021-Apr-05 18:05:42 :: [i586] #100 make-initrd-lvm: install check OK
2021-Apr-05 18:05:46 :: [aarch64] #100 make-initrd-lvm: install check OK
2021-Apr-05 18:05:47 :: [x86_64] #100 make-initrd-mdadm: install check OK
2021-Apr-05 18:05:47 :: [ppc64le] #100 make-initrd-luks: install check OK
2021-Apr-05 18:05:48 :: [i586] #100 make-initrd-mdadm: install check OK
2021-Apr-05 18:05:50 :: [armh] #100 make-initrd-devmapper: install check OK
2021-Apr-05 18:05:53 :: [aarch64] #100 make-initrd-mdadm: install check OK
2021-Apr-05 18:05:53 :: [x86_64] #100 make-initrd-multipath: install 
check OK
2021-Apr-05 18:05:55 :: [i586] #100 make-initrd-multipath: install check OK
2021-Apr-05 18:05:57 :: [ppc64le] #100 make-initrd-lvm: install check OK
x86_64: make-initrd-nfs=2.14.1-alt1 post-install unowned files:
/usr/share/make-initrd
/usr/share/make-initrd/features
2021-Apr-05 18:05:58 :: [x86_64] #100 make-initrd-nfs: install check OK
i586: make-initrd-nfs=2.14.1-alt1 post-install unowned files:
/usr/share/make-initrd
/usr/share/make-initrd/features
2021-Apr-05 18:05:59 :: [i586] #100 make-initrd-nfs: install check OK
2021-Apr-05 18:06:00 :: [aarch64] #100 make-initrd-multipath: install 
check OK
2021-Apr-05 18:06:02 :: [armh] #100 make-initrd-luks: install check OK
aarch64: make-initrd-nfs=2.14.1-alt1 post-install unowned files:
/usr/share/make-initrd
/usr/share/make-initrd/features
2021-Apr-05 18:06:05 :: [aarch64] #100 make-initrd-nfs: install check OK
2021-Apr-05 18:06:06 :: [ppc64le] #100 make-initrd-mdadm: install check OK
2021-Apr-05 18:06:07 :: [x86_64] #100 make-initrd-plymouth: install check OK
2021-Apr-05 18:06:10 :: [i586] #100 make-initrd-plymouth: install check OK
2021-Apr-05 18:06:14 :: [armh] #100 make-initrd-lvm: install check OK
2021-Apr-05 18:06:15 :: [aarch64] #100 make-initrd-plymouth: install 
check OK
2021-Apr-05 18:06:15 :: [ppc64le] #100 make-initrd-multipath: install 
check OK
ppc64le: make-initrd-nfs=2.14.1-alt1 post-install unowned files:
/usr/share/make-initrd
/usr/share/make-initrd/features
2021-Apr-05 18:06:21 :: [ppc64le] #100 make-initrd-nfs: install check OK
2021-Apr-05 18:06:24 :: [x86_64] #100 make-initrd-ucode: install check OK
2021-Apr-05 18:06:25 :: [armh] #100 make-initrd-mdadm: install check OK
2021-Apr-05 18:06:28 :: [i586] #100 make-initrd-ucode: install check OK
2021-Apr-05 18:06:35 :: [ppc64le] #100 make-initrd-plymouth: install 
check OK
2021-Apr-05 18:06:37 :: [armh] #100 make-initrd-multipath: install check OK
armh: make-initrd-nfs=2.14.1-alt1 post-install unowned files:
/usr/share/make-initrd
/usr/share/make-initrd/features
2021-Apr-05 18:06:44 :: [armh] #100 make-initrd-nfs: install check OK
2021-Apr-05 18:07:00 :: [armh] #100 make-initrd-plymouth: install check OK
2021-Apr-05 18:07:13 :: [x86_64-i586] generated apt indices
2021-Apr-05 18:07:13 :: [x86_64-i586] created next repo
2021-Apr-05 18:07:20 :: [x86_64-i586] dependencies check OK
2021-Apr-05 18:07:20 :: gears inheritance check OK
2021-Apr-05 18:07:20 :: srpm inheritance check OK
girar-check-perms: access to make-initrd DENIED for klark: does not 
belong to approved builders list: legion check-subtask-perms: #100: 
make-initrd: Operation not permitted
2021-Apr-05 18:07:20 :: acl check IGNORED
2021-Apr-05 18:07:27 :: created contents_index files
2021-Apr-05 18:07:35 :: created hash files: aarch64 armh i586 ppc64le 
src x86_64
2021-Apr-05 18:07:38 :: task #269003 for sisyphus TESTED



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-05 20:33 ` [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 Leonid Krivoshein
@ 2021-04-05 22:51   ` Leonid Krivoshein
  2021-04-06  8:44     ` Alexey Gladkov
  2021-04-06  8:28   ` Alexey Gladkov
  1 sibling, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-05 22:51 UTC (permalink / raw)
  To: make-initrd


05.04.2021 23:33, Leonid Krivoshein пишет:
> 2. В интерфейс pipeline не выведена уже реализованная в make-initrd 
> возможность работы с /proc/cmdline. Имею ввиду общие параметры, такие 
> как lowmem, live или rescue. У каждой фичи -- свои аргументы. Пока не 
> удалось побороть эту проблему, мой "config" оказался нерабочим. Может, 
> нужно просто инклюдить какой-то файл?

С этим разобрался. Не нужен мой "config", можно просто инклюдить 
/.initrd/initenv, хотя переменные в верхнем регистре и так должны быть 
доступны через окружение.

...

8. Можно сделать общее описание входа/выхода для всех поддерживаемых 
шагов и выполнять необходимые проверки до и после выполнения шага, чтобы 
не не делать этого внутри самих шагов. Такое описание будет полезно и 
для шага debug. Шаги могут быть транзитными (pass-thru).

...

[уже не про pipeline]

Иногда нужно не делать switch_root "$rootmnt" "$INIT", а нужно просто 
запустить скрипт "$INIT" с подмонтированного "$rootmnt", полностью 
остановив счётчик таймаута загрузки, и разрешив интерактивное 
взаимодействие. При этом make-initrd с запущенными фоновыми процессами 
может продолжать работать, а организацию выключения/перезагрузки можно 
возложить на запущенный скрипт. Как лучше реализовать аналог 
data/etc/rc.d/rc.sysexec?


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-05 20:33 ` [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 Leonid Krivoshein
  2021-04-05 22:51   ` Leonid Krivoshein
@ 2021-04-06  8:28   ` Alexey Gladkov
  2021-04-06 16:38     ` Leonid Krivoshein
  2021-04-07  1:51     ` Leonid Krivoshein
  1 sibling, 2 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-06  8:28 UTC (permalink / raw)
  To: make-initrd

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-05 22:51   ` Leonid Krivoshein
@ 2021-04-06  8:44     ` Alexey Gladkov
  2021-04-06 17:38       ` Leonid Krivoshein
  0 siblings, 1 reply; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-06  8:44 UTC (permalink / raw)
  To: make-initrd

On Tue, Apr 06, 2021 at 01:51:30AM +0300, Leonid Krivoshein wrote:
> 8. Можно сделать общее описание входа/выхода для всех поддерживаемых шагов и
> выполнять необходимые проверки до и после выполнения шага, чтобы не не
> делать этого внутри самих шагов. Такое описание будет полезно и для шага
> debug. Шаги могут быть транзитными (pass-thru).

Я не хочу навязывать что должны шага принимать и уж тем более нельзя
навязывать, что они должны возвращать. Например, waitdev ничего не
монтирует т.е. на выходе нет ничего кроме задержки перед следующим шагом.

Могут быть шаги, которые будут спрашивать что-то у пользователя. Описывать
такое очень сложно.

Как организовывать debug это другой вопрос. Можно добавить в шаги больше
verbose сообщений. Можно также сделать шаг shell, который даст консоль.

> [уже не про pipeline]
> 
> Иногда нужно не делать switch_root "$rootmnt" "$INIT", а нужно просто
> запустить скрипт "$INIT" с подмонтированного "$rootmnt", полностью остановив
> счётчик таймаута загрузки, и разрешив интерактивное взаимодействие. При этом
> make-initrd с запущенными фоновыми процессами может продолжать работать, а
> организацию выключения/перезагрузки можно возложить на запущенный скрипт.
> Как лучше реализовать аналог data/etc/rc.d/rc.sysexec?

Ты всегда можешь придумать свой "метод" загрузки.

Для обычных систем это localdev [1], который подразумевает пинок init,
чтобы тот выполнил rc.sysexec.

Но ты можешь это изменить и придумать свою последовательность (какую
хочешь). Например вот фича [2], которая реализует "метод" bootloader,
который показывает меню и делает kexec.

[1] https://github.com/osboot/make-initrd/tree/master/data/lib/initrd/boot/method/localdev
[2] https://github.com/osboot/make-initrd-bootloader

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06  8:28   ` Alexey Gladkov
@ 2021-04-06 16:38     ` Leonid Krivoshein
  2021-04-06 19:05       ` Alexey Gladkov
  2021-04-07  1:51     ` Leonid Krivoshein
  1 sibling, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-06 16:38 UTC (permalink / raw)
  To: make-initrd


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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06  8:44     ` Alexey Gladkov
@ 2021-04-06 17:38       ` Leonid Krivoshein
  2021-04-07 13:13         ` Alexey Gladkov
  0 siblings, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-06 17:38 UTC (permalink / raw)
  To: make-initrd


06.04.2021 11:44, Alexey Gladkov пишет:
> On Tue, Apr 06, 2021 at 01:51:30AM +0300, Leonid Krivoshein wrote:
>> 8. Можно сделать общее описание входа/выхода для всех поддерживаемых шагов и
>> выполнять необходимые проверки до и после выполнения шага, чтобы не не
>> делать этого внутри самих шагов. Такое описание будет полезно и для шага
>> debug. Шаги могут быть транзитными (pass-thru).
> Я не хочу навязывать что должны шага принимать и уж тем более нельзя
> навязывать, что они должны возвращать. Например, waitdev ничего не
> монтирует т.е. на выходе нет ничего кроме задержки перед следующим шагом.
>
> Могут быть шаги, которые будут спрашивать что-то у пользователя. Описывать
> такое очень сложно.

Можно сделать необязательным описание входа. Если не описано, считать, 
что на входе может быть что угодно и задача шага -- проверить это 
самостоятельно и вывести fatal(). Если же есть описание, проверку может 
делать сам pipeline. ANY -- что угодно, DEV -- устройство, DIR -- 
каталог, PASS -- шаг не обрабатывает вход, вместо этого он должен быть 
напрямую связан с выходом без обработки, т.е. в данном случае pipeline 
должен передать выход предыдущего шага на вход следующего шага или 
первого, который не PASS.

Иначе каждый шаг начинается с проверок и вывода fatal(), а в конце 
сейчас приходится использовать специально написанную для данного случая 
pass_thru_pipeline(). Именно эту однотипную и примитивную обработку 
предлагаю перетащить в pipeline, чтобы не делать её на каждом шаге.

И вообще я бы заменил передачу dev на devname или симлинк. Чтобы не 
видеть таких путей в mtab ни в stage1, ни в stage2:

/dev/pipeline/dst/pipe1/dev ==> /dev/sr0



> Как организовывать debug это другой вопрос. Можно добавить в шаги больше
> verbose сообщений. Можно также сделать шаг shell, который даст консоль.
>
>> [уже не про pipeline]
>>
>> Иногда нужно не делать switch_root "$rootmnt" "$INIT", а нужно просто
>> запустить скрипт "$INIT" с подмонтированного "$rootmnt", полностью остановив
>> счётчик таймаута загрузки, и разрешив интерактивное взаимодействие. При этом
>> make-initrd с запущенными фоновыми процессами может продолжать работать, а
>> организацию выключения/перезагрузки можно возложить на запущенный скрипт.
>> Как лучше реализовать аналог data/etc/rc.d/rc.sysexec?
> Ты всегда можешь придумать свой "метод" загрузки.
>
> Для обычных систем это localdev [1], который подразумевает пинок init,
> чтобы тот выполнил rc.sysexec.
>
> Но ты можешь это изменить и придумать свою последовательность (какую
> хочешь). Например вот фича [2], которая реализует "метод" bootloader,
> который показывает меню и делает kexec.
>
> [1] https://github.com/osboot/make-initrd/tree/master/data/lib/initrd/boot/method/localdev
> [2] https://github.com/osboot/make-initrd-bootloader

Это прекрасно, большое спасибо!

Теперь и rescue-launcher для всяких развёртывалок можно перетащить в 
stage1...



-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 16:38     ` Leonid Krivoshein
@ 2021-04-06 19:05       ` Alexey Gladkov
  2021-04-06 19:30         ` Alexey Gladkov
                           ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-06 19:05 UTC (permalink / raw)
  To: make-initrd

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 19:05       ` Alexey Gladkov
@ 2021-04-06 19:30         ` Alexey Gladkov
  2021-04-06 23:13           ` Leonid Krivoshein
  2021-04-06 23:00         ` Leonid Krivoshein
  2021-04-06 23:59         ` Leonid Krivoshein
  2 siblings, 1 reply; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-06 19:30 UTC (permalink / raw)
  To: make-initrd

On Tue, Apr 06, 2021 at 09:05:32PM +0200, Alexey Gladkov wrote:
> > > > 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
> > > > каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
> > > > устройств?
> > > pipeline=waitdev,waitdev,... \
> > > 	waitdev=/dev/cdrom \
> > > 	waitdev=/dev/sda
> > > 
> > > Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
> > > не обязательно, что на выходе должно быть что-то, что будет монтироваться.
> > > Это может быть шаг с диалоговым окном для корректировки поведения
> > > следующих шагов.
> > 
> > Хорошо, дождались нескольких устройств. Выход получили только от последнего.
> 
> Да нет же. Ты получаешь доступ ко _всем_ предыдущим шагам. Ты можешь к ним
> обращаться pipeN, N это номер шага.

Я знаю, что тут много моей вины. Я не задокументировал это должным
образом. Я своё оправдание скажу, что год это никто даже не пробовал
использовать.

Но посмотри на реализацию шага overlayfs. Я специально его сделал для
иллюстрации того, что возможно использовать несколько предыдущих шагов.

В overlayfs параметр если указан это список того, что будет lowerdir. Для
каждого элемента используется resolve_target, которая либо берёт что
укажешь, либо если это pipeN вернёт dst этого шага. Таким образом ты
можешь указать overlayfs=pipe1,pipe2,pipe3 и собрать три шага в свой dst.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 19:05       ` Alexey Gladkov
  2021-04-06 19:30         ` Alexey Gladkov
@ 2021-04-06 23:00         ` Leonid Krivoshein
  2021-04-07 12:11           ` Alexey Gladkov
  2021-04-06 23:59         ` Leonid Krivoshein
  2 siblings, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-06 23:00 UTC (permalink / raw)
  To: make-initrd


06.04.2021 22:05, Alexey Gladkov пишет:
> [...]
> Если это так бомбит, то можно использовать /run или смонтировать в
> /dev/pipeline ещё одну tmpfs. Хотя это всё та же память и просто
> добавляется точка монтирования.

Бомбит возможность записывать в /dev большие объёмы данных без 
ограничений на их размер и вообще использовать /dev не по назначению. 
Да, для всех не-устройств /run более подходящее место, но я не уверен, 
что для какой-либо цепочки pipeline вообще нужно что-либо переносить 
целиком в stage2, кроме $rootmnt и возможно других одной-пары точек 
монтирования из initramfs. В случае пропагатора переносятся только две: 
/image и /root, остальное находится в /dev/ramN.


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

Неужели уже год прошёл!? Ну, прости, был сильно занят! :-)

А ещё я обещал с документированием подсобить, и тоже руки не дошли.
Но это и хорошо, сначала надо самому как следует разобраться.


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

Думаю, что нет, попробую по другому объяснить (ниже).


>>> Затруднительно
>>> даже поменять порядок внутри уже реализованного.
>> Если реализуется отдельными шагами, как сейчас, не вижу проблем.
> Я вижу :)
>
>>> В такой парадигме только
>>> такой же монолит будет работать также.
>> В рамках pipeline не выйдет реализовать монолит, я пытался.
> Я старался, чтобы не получилось (шучу).
>
>> А вот разбить на части удалось. Их можно переставлять, перемешивать с
>> нативными.
> Я как раз и надеялся, что будет произведена декомпозиция пропагатора. Да,
> это непростая работа.

Мне эта идея с декомпозицией как раз нравится.


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

Отлично! Именно так сейчас и реализованы шаги замены пропагатора с 
монтированием внахлёст.


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

Какой подход к проблеме не выбери, задача цепочки -- собрать нужное и 
перетащить в stage2. Шагом rootfs ты сейчас говоришь, что из цепочки 
надо перетащить в /root для stage2, остальное перетащится вообще всё.

При текущем подходе по умолчанию перетаскивается всё, включая ненужное, 
и надо сделать prune для очистки. В предлагаемом подходе потребуется 
альтернатива переноса только нужного. Например, это может быть шаг 
rootfs. Между подходами почти нет разницы, кроме одного: строителю 
цепочки видней, что надо перетаскивать, поэтому не стоит перетаскивать 
всё по умолчанию. Можно пойти и другим путём: использовать 
/{dev,run}/pipeline/ для размещения там только того, что действительно 
должно попасть в stage2. Я бы размещал на "входе" devname, вместо самих 
устройств и симлинки на каталоги, чтобы избавиться от длинных путей в mtab.

Для наглядности. Вот этот код будет работать при обеих подходах:

mount -t nfs -o ro,soft,nolock IP:/path/to/images /root
mount -t iso9660 -o ro,loop /root/path/to/ISO /image
dd if=/image/rescue of=/dev/ram3 bs=32
umount /image /root
mount /dev/ram3 /root

Для реализации текущим способом придётся делать prune, иначе всё это 
(ненужное) попадёт в stage2. А нужен здесь только результат последнего 
шага. В предлагаемом подходе при переходе в stage2 ненужное 
отмонтируется, а всё лишнее из initramfs вычистится автоматом. Разница в 
подходах будет также видна в путях как к устройствам, так и к 
смонтированным каталогам.

В предлагаемом подходе последняя строчка /proc/mounts:

/dev/ram3 /root squashfs ro,...

Что выглядит привычно и интуитивно понятно. В имеющемся это сейчас 
выглядит примерно так:

/dev/pipeline/dst/pipe3/dev /dev/pipeline/dst/pipe5 squashfs ro,..

Ну да, здесь по файловой системе ещё можно догадаться. Но если похожих 
будет много, это уже начинает приводить в замешательство.

Что касается монтирования внахлёст, то код:

mount ... /root
mount ... /root
mount ... /root

чудесно работает и не вызывает проблем, если по сути нужен результат 
только предыдущего шага, а результаты предыдущих шагов в конечном итоге 
не потребуются в stage2. Так что подходы вполне можно комбинировать, но 
предпочтительно использовать симлинки и передавать названия устройств 
вместо создания самих устройств. Да и просто симлинками можно решить все 
проблемы этого интерфейса.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 19:30         ` Alexey Gladkov
@ 2021-04-06 23:13           ` Leonid Krivoshein
  2021-04-07 12:28             ` Alexey Gladkov
  0 siblings, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-06 23:13 UTC (permalink / raw)
  To: make-initrd


06.04.2021 22:30, Alexey Gladkov пишет:
> On Tue, Apr 06, 2021 at 09:05:32PM +0200, Alexey Gladkov wrote:
>>>>> 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
>>>>> каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
>>>>> устройств?
>>>> pipeline=waitdev,waitdev,... \
>>>> 	waitdev=/dev/cdrom \
>>>> 	waitdev=/dev/sda
>>>>
>>>> Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
>>>> не обязательно, что на выходе должно быть что-то, что будет монтироваться.
>>>> Это может быть шаг с диалоговым окном для корректировки поведения
>>>> следующих шагов.
>>> Хорошо, дождались нескольких устройств. Выход получили только от последнего.
>> Да нет же. Ты получаешь доступ ко _всем_ предыдущим шагам. Ты можешь к ним
>> обращаться pipeN, N это номер шага.
> Я знаю, что тут много моей вины. Я не задокументировал это должным
> образом. Я своё оправдание скажу, что год это никто даже не пробовал
> использовать.
>
> Но посмотри на реализацию шага overlayfs. Я специально его сделал для
> иллюстрации того, что возможно использовать несколько предыдущих шагов.

В коде-то я увидел, потому и спросил в предыдущем письме: Как написать 
универсальный шаг, который обработает результаты нескольких предыдущих? 
Передавать этому шагу номера pipe'ов через cmdline? Что ты ниже и 
предлагаешь:


> В overlayfs параметр если указан это список того, что будет lowerdir. Для
> каждого элемента используется resolve_target, которая либо берёт что
> укажешь, либо если это pipeN вернёт dst этого шага. Таким образом ты
> можешь указать overlayfs=pipe1,pipe2,pipe3 и собрать три шага в свой dst.

Пользователь может редактировать cmdline, такой интерфейс я бы не назвал 
безопасным, интуитивно понятным и простым. Нужно хорошо понимать работу 
pipeline, мысленно переводить строку kw1,kw2,kw3,... в массив, 
производить в уме сдвиги ячеек в нём, прописывать в cmdline новые 
индексы, и конечно молиться, чтобы ничего не сломалось. :-) Проблему 
распараллеливания и синхронизации цепочек это тоже не решает. А ведь что 
такое pipeline, когда уже есть event-driven механизм, если не "ручное" 
управление порядком загрузки плюс возможность смешивать эти два подхода?


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 19:05       ` Alexey Gladkov
  2021-04-06 19:30         ` Alexey Gladkov
  2021-04-06 23:00         ` Leonid Krivoshein
@ 2021-04-06 23:59         ` Leonid Krivoshein
  2 siblings, 0 replies; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-06 23:59 UTC (permalink / raw)
  To: make-initrd


06.04.2021 22:05, Alexey Gladkov пишет:
> [...]
> Ты мне хочешь показать на bash, что не вписывается в парадигму ?! ))
> Может лучше всё-таки словами ? )))

На пальцах объяснять дольше получается, на баше лаконичней выходит -- 
см. ниже...


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

interactive_on()
{
   :> /.initrd/interactive
   exec </dev/console >/dev/console 2>&1
}

interactive_off()
{
   rm -f /.initrd/interactive
   exec </dev/null >/var/log/pipelined.log 2>&1
}

DLG в описании шага -- аналогичен PASS, но можно открывать интерактивное 
выполнение до запуска скрипта с шагом и не отключать его после, если 
следующий шаг описан тоже как DLG. Конечно, отключать его во всех 
остальных случаях при завершении шага, поскольку дескрипторы открыты в 
цикле верхнего уровня.

Понятно, что использовать перенаправление руками всегда можно, но надо 
ещё въехать в твой код, куда, когда и чего перенаправляется. Тут ещё 
появляется возможность учитывать диалоги при построении параллельно 
работающих цепочек, я-то привёл упрощённую реализацию.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06  8:28   ` Alexey Gladkov
  2021-04-06 16:38     ` Leonid Krivoshein
@ 2021-04-07  1:51     ` Leonid Krivoshein
  2021-04-07 12:57       ` Alexey Gladkov
  1 sibling, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-07  1:51 UTC (permalink / raw)
  To: make-initrd


06.04.2021 11:28, Alexey Gladkov пишет:
> Это сразу наложит ограничение на использование запятой в аргументе. А она
> уже используется как разделитель например в опциях монтирования. Недавно я
> предлагал вариант передачи дополнительных параметров монтирования:
>
> pipeline=waitdev,mountfs \
> 	waitdev=/dev/sda \
> 	mountfs=/dev/sda:nodev,noexec,mode=620
>
> Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
> синтаксисе ?

Вроде как есть два варианта реализации, я склоняюсь ко второму:

1. Использовать register_pipe с разделителем "|" вместо register_string 
для pipeline=... или парсить токены не по запятым, а по "|", тогда 
проблемы с запятыми и двоеточиями отпадают:

pipeline=waitdev=/dev/sda|mountfs=/dev/sda:nodev,noexec,mode=620


2. Сохранить полностью нынешний синтаксис, добавив в него возможность в 
простых случаях (где в значении отсутствуют запятые и двоеточия) 
использовать символ "=" для отделения имени шага от его параметров, 
разделяемых символом ":" или ";":

pipeline=waitdev=/dev/sda,mountfs mountfs=/dev/sda:nodev,noexec,mode=620


Первый вариант решает сразу много проблем, но создаёт проблему 
совместимости (которой, впрочем, можно пренебречь), а также создаёт не 
всегда интуитивно соответствующее восприятие происходящего, поскольку 
запятые отражают последовательность запускаемых шагов (их перечисление), 
тогда как "|" показывает кто-кому передаёт сделанное, а это, как мы 
выяснили, не всегда будет соответствовать написанному.

Второй вариант кажется хорошим компромиссом для экономии байтов в 
/proc/cmdline и не ломает совместимость. В приведённом выше примере 
экономия небольшая, но на больших реальных цепочках она будет ощутимей, 
например:

pipeline=waitdev=/dev/sda,mountfs=:/root,ram=/root/rescue,mountfs=:,live=rw,rootfs
vs
pipeline=waitdev,mountfs,ram,mountfs,live,rootfs waitdev=/dev/sda 
mountfs=:/root ram=/root/rescue mountfs=: live=rw


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 23:00         ` Leonid Krivoshein
@ 2021-04-07 12:11           ` Alexey Gladkov
  0 siblings, 0 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-07 12:11 UTC (permalink / raw)
  To: make-initrd

On Wed, Apr 07, 2021 at 02:00:33AM +0300, Leonid Krivoshein wrote:
> 06.04.2021 22:05, Alexey Gladkov пишет:
> > Если это так бомбит, то можно использовать /run или смонтировать в
> > /dev/pipeline ещё одну tmpfs. Хотя это всё та же память и просто
> > добавляется точка монтирования.
> 
> Бомбит возможность записывать в /dev большие объёмы данных без ограничений
> на их размер и вообще использовать /dev не по назначению. Да, для всех
> не-устройств /run более подходящее место, но я не уверен, что для какой-либо
> цепочки pipeline вообще нужно что-либо переносить целиком в stage2, кроме
> $rootmnt и возможно других одной-пары точек монтирования из initramfs. В
> случае пропагатора переносятся только две: /image и /root, остальное
> находится в /dev/ramN.

Я вижу ты очень любишь /dev/ramN. Есть разница между ramdisk и tmpfs.
Помимо этих различий ramN ограниченное количество и их нужно будет
соотносить с шагами. tmpfs проще монтировать.

> > Вот именно потому что я не могу знать нужны или нет все звенья я их
> > переношу в систему. Ты всегда можешь сделать шаг prune и параметром (или
> > ещё как-нибудь) указать ему какие стадии удалить.
> 
> Какой подход к проблеме не выбери, задача цепочки -- собрать нужное и
> перетащить в stage2. Шагом rootfs ты сейчас говоришь, что из цепочки надо
> перетащить в /root для stage2, остальное перетащится вообще всё.
> 
> При текущем подходе по умолчанию перетаскивается всё, включая ненужное, и
> надо сделать prune для очистки. В предлагаемом подходе потребуется
> альтернатива переноса только нужного. Например, это может быть шаг rootfs.
> Между подходами почти нет разницы, кроме одного: строителю цепочки видней,
> что надо перетаскивать, поэтому не стоит перетаскивать всё по умолчанию.
> Можно пойти и другим путём: использовать /{dev,run}/pipeline/ для размещения
> там только того, что действительно должно попасть в stage2. Я бы размещал на
> "входе" devname, вместо самих устройств и симлинки на каталоги, чтобы
> избавиться от длинных путей в mtab.
> 
> Для наглядности. Вот этот код будет работать при обеих подходах:
> 
> mount -t nfs -o ro,soft,nolock IP:/path/to/images /root
> mount -t iso9660 -o ro,loop /root/path/to/ISO /image
> dd if=/image/rescue of=/dev/ram3 bs=32

Вот тут вот ты переливаешь данные из одной части памяти в другую.

> umount /image /root
> mount /dev/ram3 /root
> 
> Для реализации текущим способом придётся делать prune, иначе всё это
> (ненужное) попадёт в stage2. А нужен здесь только результат последнего шага.
> В предлагаемом подходе при переходе в stage2 ненужное отмонтируется, а всё
> лишнее из initramfs вычистится автоматом. Разница в подходах будет также
> видна в путях как к устройствам, так и к смонтированным каталогам.
> 
> В предлагаемом подходе последняя строчка /proc/mounts:
> 
> /dev/ram3 /root squashfs ro,...

Плевать, что написано в /proc/mounts.

> Что выглядит привычно и интуитивно понятно. В имеющемся это сейчас выглядит
> примерно так:
> 
> /dev/pipeline/dst/pipe3/dev /dev/pipeline/dst/pipe5 squashfs ro,..
> 
> Ну да, здесь по файловой системе ещё можно догадаться. Но если похожих будет
> много, это уже начинает приводить в замешательство.

Пожалуйста, не надо это приводить в качестве аргумента. /proc/mounts это
служебный файл. Там системная информация, а не красивости.

А то так мы дойдём до юникодных human-readable названий "чтобы было
понятно" или стихов вместо имени устройства.

> Что касается монтирования внахлёст, то код:
> 
> mount ... /root
> mount ... /root
> mount ... /root
> 
> чудесно работает и не вызывает проблем,

Ты почему-то игнорируешь юскейс c overlayfs. Расскажи, как просто будет
сделать шаг с подобным подходом ?

Пожалуйста учитывай, что любые изменения должны покрывать всё то, что уже
реализовано.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 23:13           ` Leonid Krivoshein
@ 2021-04-07 12:28             ` Alexey Gladkov
  0 siblings, 0 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-07 12:28 UTC (permalink / raw)
  To: make-initrd

On Wed, Apr 07, 2021 at 02:13:39AM +0300, Leonid Krivoshein wrote:
> 
> 06.04.2021 22:30, Alexey Gladkov пишет:
> > On Tue, Apr 06, 2021 at 09:05:32PM +0200, Alexey Gladkov wrote:
> > > > > > 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
> > > > > > каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
> > > > > > устройств?
> > > > > pipeline=waitdev,waitdev,... \
> > > > > 	waitdev=/dev/cdrom \
> > > > > 	waitdev=/dev/sda
> > > > > 
> > > > > Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
> > > > > не обязательно, что на выходе должно быть что-то, что будет монтироваться.
> > > > > Это может быть шаг с диалоговым окном для корректировки поведения
> > > > > следующих шагов.
> > > > Хорошо, дождались нескольких устройств. Выход получили только от последнего.
> > > Да нет же. Ты получаешь доступ ко _всем_ предыдущим шагам. Ты можешь к ним
> > > обращаться pipeN, N это номер шага.
> > Я знаю, что тут много моей вины. Я не задокументировал это должным
> > образом. Я своё оправдание скажу, что год это никто даже не пробовал
> > использовать.
> > 
> > Но посмотри на реализацию шага overlayfs. Я специально его сделал для
> > иллюстрации того, что возможно использовать несколько предыдущих шагов.
> 
> В коде-то я увидел, потому и спросил в предыдущем письме: Как написать
> универсальный шаг, который обработает результаты нескольких предыдущих?
> Передавать этому шагу номера pipe'ов через cmdline? Что ты ниже и
> предлагаешь:

Можно передавать через cmdline, да. Именно можно, а можно и не передавать.

> 
> > В overlayfs параметр если указан это список того, что будет lowerdir. Для
> > каждого элемента используется resolve_target, которая либо берёт что
> > укажешь, либо если это pipeN вернёт dst этого шага. Таким образом ты
> > можешь указать overlayfs=pipe1,pipe2,pipe3 и собрать три шага в свой dst.
> 
> Пользователь может редактировать cmdline, такой интерфейс я бы не назвал
> безопасным, интуитивно понятным и простым.

Во-первых не всегда может. Ещё во времена lilo уже можно было этим
управлять.

Во-вторых может и что ? Если пользователь имеет доступ к cmdline он может
изменить init=, root=. Давай защищаться от реальных угроз, а не
вымышленных.

Сам initramfs immutable и cmdline это способ указать динамическую
конфигурацию. Интерфейс конфигурации pipeline позволяет сконфигурировать
initramfs, загруженный через PXE например. При этом не нужно создавать
разный набор initramfs под разные конфигурации.

> Нужно хорошо понимать работу pipeline, мысленно переводить строку
> kw1,kw2,kw3,... в массив, производить в уме сдвиги ячеек в нём,
> прописывать в cmdline новые индексы, и конечно молиться, чтобы ничего не
> сломалось. :-)

Прости, это не аргумент. Для правильного указания root= нужно знать UUID
или LABEL рутового устройства, для указания других параметров ядра нужно
знать как они повлияют на ядро.

cmdline это системный интерфейс и требует определённой квалификации.

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

> Проблему распараллеливания и синхронизации цепочек это тоже не решает. А
> ведь что такое pipeline, когда уже есть event-driven механизм, если не
> "ручное" управление порядком загрузки плюс возможность смешивать эти два
> подхода?

Ты всегда упоминаешь некое распараллеливание, но нигде его не описывал.

У меня в голове есть одна схема, где фигурирует слово "распараллеливание",
но я почти уверен, что это не то, что ты имеешь в виду.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  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
  0 siblings, 2 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-07 12:57 UTC (permalink / raw)
  To: make-initrd

On Wed, Apr 07, 2021 at 04:51:15AM +0300, Leonid Krivoshein wrote:
> 
> 06.04.2021 11:28, Alexey Gladkov пишет:
> > Это сразу наложит ограничение на использование запятой в аргументе. А она
> > уже используется как разделитель например в опциях монтирования. Недавно я
> > предлагал вариант передачи дополнительных параметров монтирования:
> > 
> > pipeline=waitdev,mountfs \
> > 	waitdev=/dev/sda \
> > 	mountfs=/dev/sda:nodev,noexec,mode=620
> > 
> > Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
> > синтаксисе ?
> 
> Вроде как есть два варианта реализации, я склоняюсь ко второму:
> 
> 1. Использовать register_pipe с разделителем "|" вместо register_string для
> pipeline=... или парсить токены не по запятым, а по "|", тогда проблемы с
> запятыми и двоеточиями отпадают:
> 
> pipeline=waitdev=/dev/sda|mountfs=/dev/sda:nodev,noexec,mode=620
> 
> 
> 2. Сохранить полностью нынешний синтаксис, добавив в него возможность в
> простых случаях (где в значении отсутствуют запятые и двоеточия)
> использовать символ "=" для отделения имени шага от его параметров,
> разделяемых символом ":" или ";":
> 
> pipeline=waitdev=/dev/sda,mountfs mountfs=/dev/sda:nodev,noexec,mode=620
> 
> 
> Первый вариант решает сразу много проблем, но создаёт проблему совместимости
> (которой, впрочем, можно пренебречь), а также создаёт не всегда интуитивно
> соответствующее восприятие происходящего, поскольку запятые отражают
> последовательность запускаемых шагов (их перечисление), тогда как "|"
> показывает кто-кому передаёт сделанное, а это, как мы выяснили, не всегда
> будет соответствовать написанному.
> 
> Второй вариант кажется хорошим компромиссом для экономии байтов в
> /proc/cmdline и не ломает совместимость. В приведённом выше примере экономия
> небольшая, но на больших реальных цепочках она будет ощутимей, например:
> 
> pipeline=waitdev=/dev/sda,mountfs=:/root,ram=/root/rescue,mountfs=:,live=rw,rootfs
> vs
> pipeline=waitdev,mountfs,ram,mountfs,live,rootfs waitdev=/dev/sda
> mountfs=:/root ram=/root/rescue mountfs=: live=rw

А ещё можно не заниматься метапрограммированием и для сложных случаев
генерировать файлик с массивом и параметрами. Или же совсем иной синтаксис
придумать и прицеплять его к initrd, оставив cmdline для переопределения
того, что сохранено внутри.

Кстати, так сейчас работает root=. При создании initrd текущие параметры
прописываются в внутренний /etc/fstab, а параметры root= из cmdline просто
переопределяет эту запись.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-06 17:38       ` Leonid Krivoshein
@ 2021-04-07 13:13         ` Alexey Gladkov
  0 siblings, 0 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-04-07 13:13 UTC (permalink / raw)
  To: make-initrd

On Tue, Apr 06, 2021 at 08:38:27PM +0300, Leonid Krivoshein wrote:
> 
> 06.04.2021 11:44, Alexey Gladkov пишет:
> > On Tue, Apr 06, 2021 at 01:51:30AM +0300, Leonid Krivoshein wrote:
> > > 8. Можно сделать общее описание входа/выхода для всех поддерживаемых шагов и
> > > выполнять необходимые проверки до и после выполнения шага, чтобы не не
> > > делать этого внутри самих шагов. Такое описание будет полезно и для шага
> > > debug. Шаги могут быть транзитными (pass-thru).
> > Я не хочу навязывать что должны шага принимать и уж тем более нельзя
> > навязывать, что они должны возвращать. Например, waitdev ничего не
> > монтирует т.е. на выходе нет ничего кроме задержки перед следующим шагом.
> > 
> > Могут быть шаги, которые будут спрашивать что-то у пользователя. Описывать
> > такое очень сложно.
> 
> Можно сделать необязательным описание входа. Если не описано, считать, что
> на входе может быть что угодно и задача шага -- проверить это самостоятельно
> и вывести fatal(). Если же есть описание, проверку может делать сам
> pipeline. ANY -- что угодно, DEV -- устройство, DIR -- каталог, PASS -- шаг
> не обрабатывает вход, вместо этого он должен быть напрямую связан с выходом
> без обработки, т.е. в данном случае pipeline должен передать выход
> предыдущего шага на вход следующего шага или первого, который не PASS.
> 
> Иначе каждый шаг начинается с проверок и вывода fatal(), а в конце сейчас
> приходится использовать специально написанную для данного случая
> pass_thru_pipeline(). Именно эту однотипную и примитивную обработку
> предлагаю перетащить в pipeline, чтобы не делать её на каждом шаге.

Я в принципе не против перераспределения обязанностей между шагами и
pipelined. Но я считаю, что децентрализация лучше. Сейчас шаги
предоставлены себе. Они могут быть написаны на bash, на си, на lua.
Демону это не важно. Он лишь отвечает за несколько простых вещей:

1. подготовить директории для данных шага и для результата.
2. запустить программу шага и проконтролировать код возврата.

Он обменивается с шагами только 5ю переменными окружения, которые можно
обработать на любом языке. Остальное шаги делают сами.

Если хочется автоматизировать получение параметра для bash, то можно
написать common-script, который будет сорсится в шагах и который будет
делать:

check_parameter PARAM
param="$(get_parameter PARAM)"

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

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-04-07 12:57       ` Alexey Gladkov
@ 2021-04-07 18:29         ` Leonid Krivoshein
  2021-05-26 15:05         ` Leonid Krivoshein
  1 sibling, 0 replies; 27+ messages in thread
From: Leonid Krivoshein @ 2021-04-07 18:29 UTC (permalink / raw)
  To: make-initrd



07.04.2021 15:57, Alexey Gladkov пишет:
> On Wed, Apr 07, 2021 at 04:51:15AM +0300, Leonid Krivoshein wrote:
>> 06.04.2021 11:28, Alexey Gladkov пишет:
>>> Это сразу наложит ограничение на использование запятой в аргументе. А она
>>> уже используется как разделитель например в опциях монтирования. Недавно я
>>> предлагал вариант передачи дополнительных параметров монтирования:
>>>
>>> pipeline=waitdev,mountfs \
>>> 	waitdev=/dev/sda \
>>> 	mountfs=/dev/sda:nodev,noexec,mode=620
>>>
>>> Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
>>> синтаксисе ?
>> Вроде как есть два варианта реализации, я склоняюсь ко второму:
>>
>> 1. Использовать register_pipe с разделителем "|" вместо register_string для
>> pipeline=... или парсить токены не по запятым, а по "|", тогда проблемы с
>> запятыми и двоеточиями отпадают:
>>
>> pipeline=waitdev=/dev/sda|mountfs=/dev/sda:nodev,noexec,mode=620
>>
>>
>> 2. Сохранить полностью нынешний синтаксис, добавив в него возможность в
>> простых случаях (где в значении отсутствуют запятые и двоеточия)
>> использовать символ "=" для отделения имени шага от его параметров,
>> разделяемых символом ":" или ";":
>>
>> pipeline=waitdev=/dev/sda,mountfs mountfs=/dev/sda:nodev,noexec,mode=620
>>
>>
>> Первый вариант решает сразу много проблем, но создаёт проблему совместимости
>> (которой, впрочем, можно пренебречь), а также создаёт не всегда интуитивно
>> соответствующее восприятие происходящего, поскольку запятые отражают
>> последовательность запускаемых шагов (их перечисление), тогда как "|"
>> показывает кто-кому передаёт сделанное, а это, как мы выяснили, не всегда
>> будет соответствовать написанному.
>>
>> Второй вариант кажется хорошим компромиссом для экономии байтов в
>> /proc/cmdline и не ломает совместимость. В приведённом выше примере экономия
>> небольшая, но на больших реальных цепочках она будет ощутимей, например:
>>
>> pipeline=waitdev=/dev/sda,mountfs=:/root,ram=/root/rescue,mountfs=:,live=rw,rootfs
>> vs
>> pipeline=waitdev,mountfs,ram,mountfs,live,rootfs waitdev=/dev/sda
>> mountfs=:/root ram=/root/rescue mountfs=: live=rw
> А ещё можно не заниматься метапрограммированием и для сложных случаев
> генерировать файлик с массивом и параметрами. Или же совсем иной синтаксис
> придумать и прицеплять его к initrd, оставив cmdline для переопределения
> того, что сохранено внутри.
>
> Кстати, так сейчас работает root=. При создании initrd текущие параметры
> прописываются в внутренний /etc/fstab, а параметры root= из cmdline просто
> переопределяет эту запись.

Тут я был неправ. Второй вариант не получится так реализовать из-за 
register_array и индексов переменных.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  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
  1 sibling, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-26 15:05 UTC (permalink / raw)
  To: make-initrd

Привет!


07.04.2021 15:57, Alexey Gladkov пишет:
> On Wed, Apr 07, 2021 at 04:51:15AM +0300, Leonid Krivoshein wrote:
>> 06.04.2021 11:28, Alexey Gladkov пишет:
>>> Это сразу наложит ограничение на использование запятой в аргументе. А она
>>> уже используется как разделитель например в опциях монтирования. Недавно я
>>> предлагал вариант передачи дополнительных параметров монтирования:
>>>
>>> pipeline=waitdev,mountfs \
>>> 	waitdev=/dev/sda \
>>> 	mountfs=/dev/sda:nodev,noexec,mode=620
>>>
>>> Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
>>> синтаксисе ?
>> Вроде как есть два варианта реализации, я склоняюсь ко второму:
>>
>> 1. Использовать register_pipe с разделителем "|" вместо register_string для
>> pipeline=... или парсить токены не по запятым, а по "|", тогда проблемы с
>> запятыми и двоеточиями отпадают:
>>
>> pipeline=waitdev=/dev/sda|mountfs=/dev/sda:nodev,noexec,mode=620
>>
>>
>> 2. Сохранить полностью нынешний синтаксис, добавив в него возможность в
>> простых случаях (где в значении отсутствуют запятые и двоеточия)
>> использовать символ "=" для отделения имени шага от его параметров,
>> разделяемых символом ":" или ";":
>>
>> pipeline=waitdev=/dev/sda,mountfs mountfs=/dev/sda:nodev,noexec,mode=620
>>
>>
>> Первый вариант решает сразу много проблем, но создаёт проблему совместимости
>> (которой, впрочем, можно пренебречь), а также создаёт не всегда интуитивно
>> соответствующее восприятие происходящего, поскольку запятые отражают
>> последовательность запускаемых шагов (их перечисление), тогда как "|"
>> показывает кто-кому передаёт сделанное, а это, как мы выяснили, не всегда
>> будет соответствовать написанному.
>>
>> Второй вариант кажется хорошим компромиссом для экономии байтов в
>> /proc/cmdline и не ломает совместимость. В приведённом выше примере экономия
>> небольшая, но на больших реальных цепочках она будет ощутимей, например:
>>
>> pipeline=waitdev=/dev/sda,mountfs=:/root,ram=/root/rescue,mountfs=:,live=rw,rootfs
>> vs
>> pipeline=waitdev,mountfs,ram,mountfs,live,rootfs waitdev=/dev/sda
>> mountfs=:/root ram=/root/rescue mountfs=: live=rw
> А ещё можно не заниматься метапрограммированием и для сложных случаев
> генерировать файлик с массивом и параметрами. Или же совсем иной синтаксис
> придумать и прицеплять его к initrd, оставив cmdline для переопределения
> того, что сохранено внутри.
>
> Кстати, так сейчас работает root=. При создании initrd текущие параметры
> прописываются в внутренний /etc/fstab, а параметры root= из cmdline просто
> переопределяет эту запись.

Учёл практически все твои замечания. Всё ещё делаю обещанное, однако 
дело уже близится к концу. В коде ещё остаются захардкореными некоторые 
пути и имена, это потом уберётся в альт-специфичный конфиг.

#271420 -- предыдущая версия "всё в одном", около 3 тыс. строк. По ней 
легче понять задумку. Тут предварительно отлажена локальная загрузка. 
altboot сделан шагом pipeline, который выполняет роль вложенной pipeline.

#272587 -- текущая версия разбита на десяток подпакетов, уже более 4200 
строк, устранены первичные замечания, но понять проще предыдущий 
вариант. Тут тоже работает пока только локальная загрузка, но уже с 
плимутом, liverw надо переделывать, ещё не проверялись: nfs, cifs и 
overlayroot. Однако оценить задумку можно уже сейчас. Документации пока 
тоже нет. Здесь отказался от вложенной pipeline, сделал форк в bootchain 
и значительное расширение его функционала, обратная совместимость с 
pipeline сохранена.


Хотел посоветоваться насчёт setsid, слишком неожиданно для меня его 
поведение в теле скрипта, запущенного через openvt. Он ведёт себя так, 
будто бы его нет, приходится использовать амперсанд (&). При этом, когда 
я делаю то же самое руками в обычном терминале, setsid ведёт себя 
ожидаемым образом. Т.е. одна и та же команда работает по-разному:

setsid sleep 10

работает как:

sleep 10

при открытии через openvt, а в консоли работает как:

sleep 10 &

речь об этом фрагменте: 
bootchain-interactive/data/bin/interactive-sh-functions

...
setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &
message "TTY${_IM_VT_number} will be activated after $((1 + delay)) seconds"
...

(в нынешнем варианте задумка работает, но я считаю это неправильно).


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-26 15:05         ` Leonid Krivoshein
@ 2021-05-26 18:12           ` Alexey Gladkov
  2021-05-26 19:25             ` Leonid Krivoshein
  0 siblings, 1 reply; 27+ messages in thread
From: Alexey Gladkov @ 2021-05-26 18:12 UTC (permalink / raw)
  To: make-initrd

On Wed, May 26, 2021 at 06:05:29PM +0300, Leonid Krivoshein wrote:
> Привет!
> 
> 
> 07.04.2021 15:57, Alexey Gladkov пишет:
> > On Wed, Apr 07, 2021 at 04:51:15AM +0300, Leonid Krivoshein wrote:
> > > 06.04.2021 11:28, Alexey Gladkov пишет:
> > > > Это сразу наложит ограничение на использование запятой в аргументе. А она
> > > > уже используется как разделитель например в опциях монтирования. Недавно я
> > > > предлагал вариант передачи дополнительных параметров монтирования:
> > > > 
> > > > pipeline=waitdev,mountfs \
> > > > 	waitdev=/dev/sda \
> > > > 	mountfs=/dev/sda:nodev,noexec,mode=620
> > > > 
> > > > Я на нём не настаиваю, но как будет выглядеть тоже самое в твоём
> > > > синтаксисе ?
> > > Вроде как есть два варианта реализации, я склоняюсь ко второму:
> > > 
> > > 1. Использовать register_pipe с разделителем "|" вместо register_string для
> > > pipeline=... или парсить токены не по запятым, а по "|", тогда проблемы с
> > > запятыми и двоеточиями отпадают:
> > > 
> > > pipeline=waitdev=/dev/sda|mountfs=/dev/sda:nodev,noexec,mode=620
> > > 
> > > 
> > > 2. Сохранить полностью нынешний синтаксис, добавив в него возможность в
> > > простых случаях (где в значении отсутствуют запятые и двоеточия)
> > > использовать символ "=" для отделения имени шага от его параметров,
> > > разделяемых символом ":" или ";":
> > > 
> > > pipeline=waitdev=/dev/sda,mountfs mountfs=/dev/sda:nodev,noexec,mode=620
> > > 
> > > 
> > > Первый вариант решает сразу много проблем, но создаёт проблему совместимости
> > > (которой, впрочем, можно пренебречь), а также создаёт не всегда интуитивно
> > > соответствующее восприятие происходящего, поскольку запятые отражают
> > > последовательность запускаемых шагов (их перечисление), тогда как "|"
> > > показывает кто-кому передаёт сделанное, а это, как мы выяснили, не всегда
> > > будет соответствовать написанному.
> > > 
> > > Второй вариант кажется хорошим компромиссом для экономии байтов в
> > > /proc/cmdline и не ломает совместимость. В приведённом выше примере экономия
> > > небольшая, но на больших реальных цепочках она будет ощутимей, например:
> > > 
> > > pipeline=waitdev=/dev/sda,mountfs=:/root,ram=/root/rescue,mountfs=:,live=rw,rootfs
> > > vs
> > > pipeline=waitdev,mountfs,ram,mountfs,live,rootfs waitdev=/dev/sda
> > > mountfs=:/root ram=/root/rescue mountfs=: live=rw
> > А ещё можно не заниматься метапрограммированием и для сложных случаев
> > генерировать файлик с массивом и параметрами. Или же совсем иной синтаксис
> > придумать и прицеплять его к initrd, оставив cmdline для переопределения
> > того, что сохранено внутри.
> > 
> > Кстати, так сейчас работает root=. При создании initrd текущие параметры
> > прописываются в внутренний /etc/fstab, а параметры root= из cmdline просто
> > переопределяет эту запись.
> 
> Учёл практически все твои замечания. Всё ещё делаю обещанное, однако дело
> уже близится к концу. В коде ещё остаются захардкореными некоторые пути и
> имена, это потом уберётся в альт-специфичный конфиг.
> 
> #271420 -- предыдущая версия "всё в одном", около 3 тыс. строк. По ней легче
> понять задумку. Тут предварительно отлажена локальная загрузка. altboot
> сделан шагом pipeline, который выполняет роль вложенной pipeline.
> 
> #272587 -- текущая версия разбита на десяток подпакетов, уже более 4200
> строк, устранены первичные замечания, но понять проще предыдущий вариант.
> Тут тоже работает пока только локальная загрузка, но уже с плимутом, liverw
> надо переделывать, ещё не проверялись: nfs, cifs и overlayroot. Однако
> оценить задумку можно уже сейчас. Документации пока тоже нет. Здесь
> отказался от вложенной pipeline, сделал форк в bootchain и значительное
> расширение его функционала, обратная совместимость с pipeline сохранена.

Это невозможно отревьювить в виде одного коммита.
Верю тебе на слово :)

> Хотел посоветоваться насчёт setsid, слишком неожиданно для меня его
> поведение в теле скрипта, запущенного через openvt. Он ведёт себя так, будто
> бы его нет, приходится использовать амперсанд (&). При этом, когда я делаю
> то же самое руками в обычном терминале, setsid ведёт себя ожидаемым образом.
> Т.е. одна и та же команда работает по-разному:

openvt сам сделает setsid, если только ты не делаешь openvt --exec .

> setsid sleep 10
> 
> работает как:
> 
> sleep 10
> 
> при открытии через openvt, а в консоли работает как:
> 
> sleep 10 &

если ты имеешь в виду, что процесс уходит в бэкграунд, то это делает
openvt. Он может так не делать, если выполнять его с опцией --exec.

> речь об этом фрагменте:
> bootchain-interactive/data/bin/interactive-sh-functions
> 
> ...
> setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &
> message "TTY${_IM_VT_number} will be activated after $((1 + delay)) seconds"
> ...
> 
> (в нынешнем варианте задумка работает, но я считаю это неправильно).

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-26 18:12           ` Alexey Gladkov
@ 2021-05-26 19:25             ` Leonid Krivoshein
  2021-05-27  8:37               ` Alexey Gladkov
  0 siblings, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-26 19:25 UTC (permalink / raw)
  To: make-initrd


26.05.2021 21:12, Alexey Gladkov пишет:
> On Wed, May 26, 2021 at 06:05:29PM +0300, Leonid Krivoshein wrote:
>> [...]
>> Учёл практически все твои замечания. Всё ещё делаю обещанное, однако дело
>> уже близится к концу. В коде ещё остаются захардкореными некоторые пути и
>> имена, это потом уберётся в альт-специфичный конфиг.
>>
>> #271420 -- предыдущая версия "всё в одном", около 3 тыс. строк. По ней легче
>> понять задумку. Тут предварительно отлажена локальная загрузка. altboot
>> сделан шагом pipeline, который выполняет роль вложенной pipeline.
>>
>> #272587 -- текущая версия разбита на десяток подпакетов, уже более 4200
>> строк, устранены первичные замечания, но понять проще предыдущий вариант.
>> Тут тоже работает пока только локальная загрузка, но уже с плимутом, liverw
>> надо переделывать, ещё не проверялись: nfs, cifs и overlayroot. Однако
>> оценить задумку можно уже сейчас. Документации пока тоже нет. Здесь
>> отказался от вложенной pipeline, сделал форк в bootchain и значительное
>> расширение его функционала, обратная совместимость с pipeline сохранена.
> Это невозможно отревьювить в виде одного коммита.

Что ты имеешь ввиду? Сделать так, чтобы сначала были отдельно видны 
изменения в коде pipeline несколькими коммитами, остальное доложить ещё 
одним коммитом? Или что слишком большой объём просто нет возможности 
ревьювить? Второе, конечно, понятно. А первое... в принципе, pipeline 
отделён сейчас в bootchain-core и два отдельных метода загрузки 
bootchain-getimage и bootchain-waitdev. Для последнего добавлен 
опциональный общий тайм-аут, и теперь его можно использовать до altboot 
(localdev), что позволит использовать подход пропагатора с диалогами и 
сканированием устройств как fallback, если заданное в /proc/cmdline не 
будет найдено, зато waitdev позволяет более тонко задавать спецификацию 
искомого и искать несколько устройств, включая символьные. То есть, не 
внося изменений в код altboot, можно красиво пристроить слева всю 
цепочку pipeline. А так по дефолту мы собираем образы с root=bootchain 
bootchain=fg,altboot и всё, что было в пропагаторе, сохранено для 
совместимости. Разве что добавили UUID к методам disk и cdrom (в 
automatic=...).


> Верю тебе на слово :)

Спасибо за доверие. :-) Но я "работаю" не один, за мной проверяет на 
образах Антон Мидюков, некоторые коллеги тоже на это посматривают пока 
издалека, надеюсь, скоро присоединятся тестировщики. Не хочется, чтобы 
вышел факап в p10 с заменой пропагатора.


>> Хотел посоветоваться насчёт setsid, слишком неожиданно для меня его
>> поведение в теле скрипта, запущенного через openvt. Он ведёт себя так, будто
>> бы его нет, приходится использовать амперсанд (&). При этом, когда я делаю
>> то же самое руками в обычном терминале, setsid ведёт себя ожидаемым образом.
>> Т.е. одна и та же команда работает по-разному:
> openvt сам сделает setsid, если только ты не делаешь openvt --exec .

Нет, exec не делаю. Но разве запущенный таким образом скрипт не может 
запускать setsid ещё раз? В какой-то момент мне нужно от него снова 
"отделиться" (форкнуться). У тебя в make-initrd setsid используется 
всего в нескольких местах, но очевидно работает ожидаемым образом.


>> setsid sleep 10
>>
>> работает как:
>>
>> sleep 10
>>
>> при открытии через openvt, а в консоли работает как:
>>
>> sleep 10 &
> если ты имеешь в виду, что процесс уходит в бэкграунд, то это делает
> openvt. Он может так не делать, если выполнять его с опцией --exec.

Вопрос терминологии -- у меня всё наоборот. pipeline и bootchain -- 
демоны, они уже работают в фоне, а мне в какой-то момент необходимо 
продолжить выполнение на переднем плане, на конкретном терминале. Это 
отделение происходит в /sbin/bootchain-loop, конкретная реализация в 
/bin/interactive-sh-functions, см. IM_exec() и IM_activate(). В общем, 
тут удивляет, почему форкнутый процесс нельзя снова форкнуть таким 
образом. Потому что не хочется отслеживать потомков и иметь дело с 
зомби, не люблю эти ужастики. ))


>> речь об этом фрагменте:
>> bootchain-interactive/data/bin/interactive-sh-functions
>>
>> ...
>> setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &
>> message "TTY${_IM_VT_number} will be activated after $((1 + delay)) seconds"
>> ...
>>
>> (в нынешнем варианте задумка работает, но я считаю это неправильно).


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-26 19:25             ` Leonid Krivoshein
@ 2021-05-27  8:37               ` Alexey Gladkov
  2021-05-27 12:29                 ` Leonid Krivoshein
  0 siblings, 1 reply; 27+ messages in thread
From: Alexey Gladkov @ 2021-05-27  8:37 UTC (permalink / raw)
  To: make-initrd

On Wed, May 26, 2021 at 10:25:09PM +0300, Leonid Krivoshein wrote:
> > Это невозможно отревьювить в виде одного коммита.
> 
> Что ты имеешь ввиду? Сделать так, чтобы сначала были отдельно видны
> изменения в коде pipeline несколькими коммитами, остальное доложить ещё
> одним коммитом? Или что слишком большой объём просто нет возможности
> ревьювить? Второе, конечно, понятно. А первое... в принципе, pipeline
> отделён сейчас в bootchain-core и два отдельных метода загрузки
> bootchain-getimage и bootchain-waitdev.

Ты переименовал pipeline в bootchain-core и переименовал файлы внутри.
Плюс нет истории. Теперь проследить разницу между ними просто нереально.

В таком виде, как оно есть сейчас, оно только так и может существовать:
как отдельные фичи. В такой ситуации не обязательно держать совместимость
с pipeline.

Я лишь могу посмотреть на разные куски кода и покомментировать.

Например:

	enter "download_image"

	local text left right opts="${CURLOPTS-}"

	[ -n "$dstreg" ] && right=">\"$to\"" ||
		right="|dd \"of=$to\" bs=32k 2>/dev/null"

Вот это одна функция, которая выполняет:

if [ -z "$dstreg" ]; then
	dd "of=$to" bs=32k 2>/dev/null
else
	cat >"$to"
fi

	text="Downloading the $OEM_DISTRIBUTION into $target..."
	message "downloading image: '$url'"

	if [ -n "$srcreg" ]; then
		left="pv -n -i 1 -- \"$url\""
	else
		opts="$opts --silent --no-buffer --connect-timeout 5"
		opts="$opts --max-redirs 5 --max-filesize \"$filesize\""
		[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
			opts="${opts:+$opts }-u \"$user:$pass\""
		left="curl $opts -- \"$url\" |pv -n -i 1 -s \"$filesize\""
	fi

Вот это другая функция.

	debug "RUN: $left $right"
	eval "($left $right)" 2>&1 |

Вот тут ты очень хотел разделить код на функции, но по какой-то причине не
сделал этого и занялся кодогенерацией.

Дело в том, что user, pass ты (насколько я понял) принимаешь от
пользователя и не проверяешь и не квотишь. Также ещё есть url, который
тоже может содержать сюрпризы.

		IM_gauge "[ Downloading image... ]" "$text" ||
			printf '%s\n' "$?" >"$datadir/ERROR"
	[ -s "$datadir/ERROR" ] || run sync

	leave "download_image"

> Для последнего добавлен опциональный
> общий тайм-аут, и теперь его можно использовать до altboot (localdev), что
> позволит использовать подход пропагатора с диалогами и сканированием
> устройств как fallback, если заданное в /proc/cmdline не будет найдено, зато
> waitdev позволяет более тонко задавать спецификацию искомого и искать
> несколько устройств, включая символьные. То есть, не внося изменений в код
> altboot, можно красиво пристроить слева всю цепочку pipeline. А так по
> дефолту мы собираем образы с root=bootchain bootchain=fg,altboot и всё, что
> было в пропагаторе, сохранено для совместимости. Разве что добавили UUID к
> методам disk и cdrom (в automatic=...).

Для fg ты перезапускаешь bootchain-loop. Что будет если кто-нибудь сделает
bootchain=altboot,fg ?

> 
> > Верю тебе на слово :)
> 
> Спасибо за доверие. :-) Но я "работаю" не один, за мной проверяет на образах
> Антон Мидюков, некоторые коллеги тоже на это посматривают пока издалека,
> надеюсь, скоро присоединятся тестировщики. Не хочется, чтобы вышел факап в
> p10 с заменой пропагатора.

Это хорошо, но понимаю кода не помогает.

> > > Хотел посоветоваться насчёт setsid, слишком неожиданно для меня его
> > > поведение в теле скрипта, запущенного через openvt. Он ведёт себя так, будто
> > > бы его нет, приходится использовать амперсанд (&). При этом, когда я делаю
> > > то же самое руками в обычном терминале, setsid ведёт себя ожидаемым образом.
> > > Т.е. одна и та же команда работает по-разному:
> > openvt сам сделает setsid, если только ты не делаешь openvt --exec .
> 
> Нет, exec не делаю. Но разве запущенный таким образом скрипт не может
> запускать setsid ещё раз? В какой-то момент мне нужно от него снова
> "отделиться" (форкнуться). У тебя в make-initrd setsid используется всего в
> нескольких местах, но очевидно работает ожидаемым образом.

Конечно, ты можешь сделать ещё раз setsid.

> 
> > > setsid sleep 10
> > > 
> > > работает как:
> > > 
> > > sleep 10
> > > 
> > > при открытии через openvt, а в консоли работает как:
> > > 
> > > sleep 10 &
> > если ты имеешь в виду, что процесс уходит в бэкграунд, то это делает
> > openvt. Он может так не делать, если выполнять его с опцией --exec.
> 
> Вопрос терминологии -- у меня всё наоборот.

Я говорил относительно кода скрипта.

> pipeline и bootchain -- демоны,
> они уже работают в фоне, а мне в какой-то момент необходимо продолжить
> выполнение на переднем плане, на конкретном терминале. Это отделение
> происходит в /sbin/bootchain-loop, конкретная реализация в
> /bin/interactive-sh-functions, см. IM_exec() и IM_activate(). В общем, тут
> удивляет, почему форкнутый процесс нельзя снова форкнуть таким образом.

Эти функции вызывают у меня вопросы ))

Зачем ты пытаешься использовать ttyN ? Тебе не хватает /dev/console ?

Дело в том, что остальной код make-initrd использует его и я предвижу
сюрпризы тут.

	if [ -n "$delay" ]; then
		exec <"/dev/tty${_IM_VT_number}"
		exec >"/dev/tty${_IM_VT_number}"

exec <"/dev/tty${_IM_VT_number}" >"/dev/tty${_IM_VT_number}"

	fi

	if [ -c "$logfile" ]; then
		exec 2>"$logfile"
	else
		touch "$logfile"

Зачем ?

		exec 2>>"$logfile"
	fi

Весь этот if заменяется на exec 2>>"$logfile" потому что в chardev можно
дописывать.

Если же предположить, что IM_activate делает скрипт "активным" вне
зависимости от delay, то эти два if можно заменить на один exec.

	setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &

Скрипт /bin/activate-interactive-vt и так уже имеет #!/bin/bash. Тут ты
вызываешь баш только для того чтобы распарсить строчку.

Если ты используешь setsid из util-linux:

setsid -f /bin/activate-interactive-vt "$delay"

должно работать ровно также как у тебя написано. Если же это busybox, то

https://git.busybox.net/busybox/tree/util-linux/setsid.c#n44

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27  8:37               ` Alexey Gladkov
@ 2021-05-27 12:29                 ` Leonid Krivoshein
  2021-05-27 13:53                   ` Alexey Gladkov
  0 siblings, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-27 12:29 UTC (permalink / raw)
  To: make-initrd


27.05.2021 11:37, Alexey Gladkov пишет:
> On Wed, May 26, 2021 at 10:25:09PM +0300, Leonid Krivoshein wrote:
>>> Это невозможно отревьювить в виде одного коммита.
>> Что ты имеешь ввиду? Сделать так, чтобы сначала были отдельно видны
>> изменения в коде pipeline несколькими коммитами, остальное доложить ещё
>> одним коммитом? Или что слишком большой объём просто нет возможности
>> ревьювить? Второе, конечно, понятно. А первое... в принципе, pipeline
>> отделён сейчас в bootchain-core и два отдельных метода загрузки
>> bootchain-getimage и bootchain-waitdev.
> Ты переименовал pipeline в bootchain-core и переименовал файлы внутри.
> Плюс нет истории. Теперь проследить разницу между ними просто нереально.

Отделил пока всё в bc-wip, чтобы тебе не мешаться, т.к. реально ещё 
work-in-progress, но это всё и не предполагается пока ревьювить и 
коммитить в таком виде. Разумеется, в финальном варианте оригинальный 
код будет сохранён и сделаны правильные коммиты с историей, чтобы это 
стало частью make-initrd, а не отдельным пакетом с фичами к нему. 
Конечно, есть вариант оставить оригинальное название pipeline, но это 
имя у нынешних линуксовых айтишников ассоциируется с другими вещами, 
bootchain мне кажется более подходящим.


> В таком виде, как оно есть сейчас, оно только так и может существовать:
> как отдельные фичи. В такой ситуации не обязательно держать совместимость
> с pipeline.

Совместимость с ним позволит строить комбинированные цепочки.


> Я лишь могу посмотреть на разные куски кода и покомментировать.

Это безусловно очень полезно, твои советы особенно ценны для меня, хоть 
и жаль твоего времени, т.к. код пока не финальный. За вчера добил 
liverw, сейчас чиню checksum. Всё же я имел ввиду оценить идею, в целом. 
Например, мне кажется, разделение на суб-фичи для bootchain само 
напрашивается. Но вот стоит ли делить на под-пакеты -- вопрос?


> Например:
>
> 	enter "download_image"
>
> 	local text left right opts="${CURLOPTS-}"
>
> 	[ -n "$dstreg" ] && right=">\"$to\"" ||
> 		right="|dd \"of=$to\" bs=32k 2>/dev/null"
>
> Вот это одна функция, которая выполняет:
>
> if [ -z "$dstreg" ]; then
> 	dd "of=$to" bs=32k 2>/dev/null
> else
> 	cat >"$to"
> fi
>
> 	text="Downloading the $OEM_DISTRIBUTION into $target..."
> 	message "downloading image: '$url'"
>
> 	if [ -n "$srcreg" ]; then
> 		left="pv -n -i 1 -- \"$url\""
> 	else
> 		opts="$opts --silent --no-buffer --connect-timeout 5"
> 		opts="$opts --max-redirs 5 --max-filesize \"$filesize\""
> 		[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
> 			opts="${opts:+$opts }-u \"$user:$pass\""
> 		left="curl $opts -- \"$url\" |pv -n -i 1 -s \"$filesize\""
> 	fi
>
> Вот это другая функция.
>
> 	debug "RUN: $left $right"
> 	eval "($left $right)" 2>&1 |
>
> Вот тут ты очень хотел разделить код на функции, но по какой-то причине не
> сделал этого и занялся кодогенерацией.

Как раз нет, тут левая и правая части выражения вычисляются, их 
приходится делать через eval из-за "|" и ">", в зависимости от ситуации, 
т.к. общий вывод перенаправляется в конечном итоге в диалоговое окно. 
Возможно, это и можно переписать так, чтобы вызывались отдельные 
функции, но у меня сходу не получилось. Могу попробовать ещё раз.


> Дело в том, что user, pass ты (насколько я понял) принимаешь от
> пользователя и не проверяешь и не квотишь. Также ещё есть url, который
> тоже может содержать сюрпризы.

Ты прав, спасибо за замечание. Весь ввод, конечно, надо брать в кавычки.


> 		IM_gauge "[ Downloading image... ]" "$text" ||
> 			printf '%s\n' "$?" >"$datadir/ERROR"
> 	[ -s "$datadir/ERROR" ] || run sync
>
> 	leave "download_image"
>
>> Для последнего добавлен опциональный
>> общий тайм-аут, и теперь его можно использовать до altboot (localdev), что
>> позволит использовать подход пропагатора с диалогами и сканированием
>> устройств как fallback, если заданное в /proc/cmdline не будет найдено, зато
>> waitdev позволяет более тонко задавать спецификацию искомого и искать
>> несколько устройств, включая символьные. То есть, не внося изменений в код
>> altboot, можно красиво пристроить слева всю цепочку pipeline. А так по
>> дефолту мы собираем образы с root=bootchain bootchain=fg,altboot и всё, что
>> было в пропагаторе, сохранено для совместимости. Разве что добавили UUID к
>> методам disk и cdrom (в automatic=...).
> Для fg ты перезапускаешь bootchain-loop. Что будет если кто-нибудь сделает
> bootchain=altboot,fg ?

fg -- это переключение в интерактивный режим, для altboot он обязателен, 
без него он не будет работать, так что пользователь сам себе злобный 
Буратино. Но я для того и разделил демона и главный цикл, чтобы второй 
можно было перезапускать в любой момент. И вот так всё будет работать 
просто отлично, я проверял:

bootchain=waitdev,waitdev,fg,altboot waitdev=LABEL=RW-OVERLAY waitdev=CDROM:

Цикл демона опционально поддерживает интерактивный режим, может 
перезапуститься и перейти на передний план в любой момент. fg -- это 
псевдо-шаг в цепочке, чтобы поддерживать такой перезапуск, приходится 
экспортировать ряд дополнительных переменных. Теоретически, ничто не 
мешает сделать псевдо-шаг bg для возвращения обратно в фоновый режим. 
Результат последнего waitdev будет использован шагом localdev, который 
запустит altboot.

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


>>> Верю тебе на слово :)
>> Спасибо за доверие. :-) Но я "работаю" не один, за мной проверяет на образах
>> Антон Мидюков, некоторые коллеги тоже на это посматривают пока издалека,
>> надеюсь, скоро присоединятся тестировщики. Не хочется, чтобы вышел факап в
>> p10 с заменой пропагатора.
> Это хорошо, но понимаю кода не помогает.

Сделаю нормальную документацию и на ближайшей конференции постараюсь 
рассказать, как это работает. Но лучше чтения кода ничего нет. А к тебе 
это ближе всего. :-)


>>>> Хотел посоветоваться насчёт setsid, слишком неожиданно для меня его
>>>> поведение в теле скрипта, запущенного через openvt. Он ведёт себя так, будто
>>>> бы его нет, приходится использовать амперсанд (&). При этом, когда я делаю
>>>> то же самое руками в обычном терминале, setsid ведёт себя ожидаемым образом.
>>>> Т.е. одна и та же команда работает по-разному:
>>> openvt сам сделает setsid, если только ты не делаешь openvt --exec .
>> Нет, exec не делаю. Но разве запущенный таким образом скрипт не может
>> запускать setsid ещё раз? В какой-то момент мне нужно от него снова
>> "отделиться" (форкнуться). У тебя в make-initrd setsid используется всего в
>> нескольких местах, но очевидно работает ожидаемым образом.
> Конечно, ты можешь сделать ещё раз setsid.
>
>>>> setsid sleep 10
>>>>
>>>> работает как:
>>>>
>>>> sleep 10
>>>>
>>>> при открытии через openvt, а в консоли работает как:
>>>>
>>>> sleep 10 &
>>> если ты имеешь в виду, что процесс уходит в бэкграунд, то это делает
>>> openvt. Он может так не делать, если выполнять его с опцией --exec.
>> Вопрос терминологии -- у меня всё наоборот.
> Я говорил относительно кода скрипта.
>
>> pipeline и bootchain -- демоны,
>> они уже работают в фоне, а мне в какой-то момент необходимо продолжить
>> выполнение на переднем плане, на конкретном терминале. Это отделение
>> происходит в /sbin/bootchain-loop, конкретная реализация в
>> /bin/interactive-sh-functions, см. IM_exec() и IM_activate(). В общем, тут
>> удивляет, почему форкнутый процесс нельзя снова форкнуть таким образом.
> Эти функции вызывают у меня вопросы ))
>
> Зачем ты пытаешься использовать ttyN ? Тебе не хватает /dev/console ?

Нужно собрать диск с таксом, чтобы было наглядней. Хотя уже скоро соберу 
новый. Сейчас "новый пропагатор" (altboot) вообще как бы "невидим". 
Переключение на tty2 происходит спустя некое время, либо сразу, если там 
есть диалог ввода. Поскольку в большинстве случаев загрузка 
автоматическая, ввода от пользователя не требуется и занимает считанные 
секунды, создаваемые "новым пропагатором" и bootchain консоли tty2 и 
tty3 бесследно исчезают, не создавая лишних мельканий на экране. Ещё 
красивее с плимутом -- всё происходит под "червячком", а вот если tty2 
активируется, то отключается ещё и rootdelay.


> Дело в том, что остальной код make-initrd использует его и я предвижу
> сюрпризы тут.
>
> 	if [ -n "$delay" ]; then
> 		exec <"/dev/tty${_IM_VT_number}"
> 		exec >"/dev/tty${_IM_VT_number}"
>
> exec <"/dev/tty${_IM_VT_number}" >"/dev/tty${_IM_VT_number}"
>
> 	fi

У меня как раз были проблемы до тех пор, пока я использовал 
/dev/console. Сейчас _IM_VT_number можно переопределить в одном месте и 
проблем пока не выявлено.


> 	if [ -c "$logfile" ]; then
> 		exec 2>"$logfile"
> 	else
> 		touch "$logfile"
>
> Зачем ?
>
> 		exec 2>>"$logfile"
> 	fi
>
> Весь этот if заменяется на exec 2>>"$logfile" потому что в chardev можно
> дописывать.

Хорошо, это переделаю.


> Если же предположить, что IM_activate делает скрипт "активным" вне
> зависимости от delay, то эти два if можно заменить на один exec.
>
> 	setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &
>
> Скрипт /bin/activate-interactive-vt и так уже имеет #!/bin/bash. Тут ты
> вызываешь баш только для того чтобы распарсить строчку.
>
> Если ты используешь setsid из util-linux:
>
> setsid -f /bin/activate-interactive-vt "$delay"
>
> должно работать ровно также как у тебя написано. Если же это busybox, то
>
> https://git.busybox.net/busybox/tree/util-linux/setsid.c#n44

Да я собственно из-за этого фрагмента и написал тебе, переделывал его 
раз 20, но так и не понял. Выше ты пишешь, что да, можно запускать 
setsid второй раз, это и есть как бы второй запуск (первый -- openvt). 
Если убрать тут setsid, результат будет таким же. Если убрать не setsid, 
а амперсанд в конце, тут будет задержка в $selay, чего я никак не мог 
победить. В обычной консоли оно себя так не ведёт. Потому и стоит сейчас 
if, а вообще предполагалось так: setsid activate-interactive-vt $delay 
безо всяких проверок и условий.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27 12:29                 ` Leonid Krivoshein
@ 2021-05-27 13:53                   ` Alexey Gladkov
  2021-05-27 15:10                     ` Leonid Krivoshein
  2021-05-30 20:34                     ` Leonid Krivoshein
  0 siblings, 2 replies; 27+ messages in thread
From: Alexey Gladkov @ 2021-05-27 13:53 UTC (permalink / raw)
  To: make-initrd

On Thu, May 27, 2021 at 03:29:50PM +0300, Leonid Krivoshein wrote:
> 
> 27.05.2021 11:37, Alexey Gladkov пишет:
> > On Wed, May 26, 2021 at 10:25:09PM +0300, Leonid Krivoshein wrote:
> > > > Это невозможно отревьювить в виде одного коммита.
> > > Что ты имеешь ввиду? Сделать так, чтобы сначала были отдельно видны
> > > изменения в коде pipeline несколькими коммитами, остальное доложить ещё
> > > одним коммитом? Или что слишком большой объём просто нет возможности
> > > ревьювить? Второе, конечно, понятно. А первое... в принципе, pipeline
> > > отделён сейчас в bootchain-core и два отдельных метода загрузки
> > > bootchain-getimage и bootchain-waitdev.
> > Ты переименовал pipeline в bootchain-core и переименовал файлы внутри.
> > Плюс нет истории. Теперь проследить разницу между ними просто нереально.
> 
> Отделил пока всё в bc-wip, чтобы тебе не мешаться, т.к. реально ещё
> work-in-progress, но это всё и не предполагается пока ревьювить и коммитить
> в таком виде. Разумеется, в финальном варианте оригинальный код будет
> сохранён и сделаны правильные коммиты с историей, чтобы это стало частью
> make-initrd, а не отдельным пакетом с фичами к нему. Конечно, есть вариант
> оставить оригинальное название pipeline, но это имя у нынешних линуксовых
> айтишников ассоциируется с другими вещами, bootchain мне кажется более
> подходящим.

Ок, теперь ясно.

> > Я лишь могу посмотреть на разные куски кода и покомментировать.
> 
> Это безусловно очень полезно, твои советы особенно ценны для меня, хоть и
> жаль твоего времени, т.к. код пока не финальный. За вчера добил liverw,
> сейчас чиню checksum. Всё же я имел ввиду оценить идею, в целом. Например,
> мне кажется, разделение на суб-фичи для bootchain само напрашивается. Но вот
> стоит ли делить на под-пакеты -- вопрос?

Если это упростит сопровождение, то почему бы нет. Вопрос в том, насколько
будет сложно реализовать суб-фичи.

> 
> > Например:
> > 
> > 	enter "download_image"
> > 
> > 	local text left right opts="${CURLOPTS-}"
> > 
> > 	[ -n "$dstreg" ] && right=">\"$to\"" ||
> > 		right="|dd \"of=$to\" bs=32k 2>/dev/null"
> > 
> > Вот это одна функция, которая выполняет:
> > 
> > if [ -z "$dstreg" ]; then
> > 	dd "of=$to" bs=32k 2>/dev/null
> > else
> > 	cat >"$to"
> > fi
> > 
> > 	text="Downloading the $OEM_DISTRIBUTION into $target..."
> > 	message "downloading image: '$url'"
> > 
> > 	if [ -n "$srcreg" ]; then
> > 		left="pv -n -i 1 -- \"$url\""
> > 	else
> > 		opts="$opts --silent --no-buffer --connect-timeout 5"
> > 		opts="$opts --max-redirs 5 --max-filesize \"$filesize\""
> > 		[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
> > 			opts="${opts:+$opts }-u \"$user:$pass\""
> > 		left="curl $opts -- \"$url\" |pv -n -i 1 -s \"$filesize\""
> > 	fi
> > 
> > Вот это другая функция.
> > 
> > 	debug "RUN: $left $right"
> > 	eval "($left $right)" 2>&1 |
> > 
> > Вот тут ты очень хотел разделить код на функции, но по какой-то причине не
> > сделал этого и занялся кодогенерацией.
> 
> Как раз нет, тут левая и правая части выражения вычисляются, их приходится
> делать через eval из-за "|" и ">", в зависимости от ситуации, т.к. общий
> вывод перенаправляется в конечном итоге в диалоговое окно. Возможно, это и
> можно переписать так, чтобы вызывались отдельные функции, но у меня сходу не
> получилось. Могу попробовать ещё раз.

У тебя могло бы быть что-то вроде:

save_image() { # right
	if [ -z "$dstreg" ]; then
		dd "of=$to" bs=32k 2>/dev/null
	else
		cat >"$to"
	fi
}

read_image() { # left
	if [ -n "$srcreg" ]; then
		pv -n -i 1 -- "$url"
		return
	fi

	opts="$opts --silent --no-buffer --connect-timeout 5"
	opts="$opts --max-redirs 5 --max-filesize $filesize"
	
	[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
		opts="${opts:+$opts }-u \"$user:$pass\""

	curl $opts -- "$url" |
		pv -n -i 1 -s "$filesize"
}

{ read_image | save_image } 2>&1 |
	IM_gauge "[ Downloading image... ]" "$text"

> > > Для последнего добавлен опциональный
> > > общий тайм-аут, и теперь его можно использовать до altboot (localdev), что
> > > позволит использовать подход пропагатора с диалогами и сканированием
> > > устройств как fallback, если заданное в /proc/cmdline не будет найдено, зато
> > > waitdev позволяет более тонко задавать спецификацию искомого и искать
> > > несколько устройств, включая символьные. То есть, не внося изменений в код
> > > altboot, можно красиво пристроить слева всю цепочку pipeline. А так по
> > > дефолту мы собираем образы с root=bootchain bootchain=fg,altboot и всё, что
> > > было в пропагаторе, сохранено для совместимости. Разве что добавили UUID к
> > > методам disk и cdrom (в automatic=...).
> > Для fg ты перезапускаешь bootchain-loop. Что будет если кто-нибудь сделает
> > bootchain=altboot,fg ?
> 
> fg -- это переключение в интерактивный режим, для altboot он обязателен, без
> него он не будет работать, так что пользователь сам себе злобный Буратино.
> Но я для того и разделил демона и главный цикл, чтобы второй можно было
> перезапускать в любой момент. И вот так всё будет работать просто отлично, я
> проверял:
> 
> bootchain=waitdev,waitdev,fg,altboot waitdev=LABEL=RW-OVERLAY waitdev=CDROM:
> 
> Цикл демона опционально поддерживает интерактивный режим, может
> перезапуститься и перейти на передний план в любой момент. fg -- это
> псевдо-шаг в цепочке, чтобы поддерживать такой перезапуск, приходится
> экспортировать ряд дополнительных переменных. Теоретически, ничто не мешает
> сделать псевдо-шаг bg для возвращения обратно в фоновый режим. Результат
> последнего waitdev будет использован шагом localdev, который запустит
> altboot.
> 
> Точнее, цепочку можно ещё и перезагружать в любой момент, меняя часть
> переменных в главном цикле демона. Благодаря этому реализованы циклы,
> условные переходы, в диалогах теперь можно возвращаться назад, что стало
> намного удобнее, чем было в пропагаторе.

Как будет готово нужно будет получше посмотреть на эту идею.

> > > > Верю тебе на слово :)
> > > Спасибо за доверие. :-) Но я "работаю" не один, за мной проверяет на образах
> > > Антон Мидюков, некоторые коллеги тоже на это посматривают пока издалека,
> > > надеюсь, скоро присоединятся тестировщики. Не хочется, чтобы вышел факап в
> > > p10 с заменой пропагатора.
> > Это хорошо, но понимаю кода не помогает.
> 
> Сделаю нормальную документацию и на ближайшей конференции постараюсь
> рассказать, как это работает. Но лучше чтения кода ничего нет. А к тебе это
> ближе всего. :-)

Да, я люблю код читать ))

> > Зачем ты пытаешься использовать ttyN ? Тебе не хватает /dev/console ?
> 
> Нужно собрать диск с таксом, чтобы было наглядней. Хотя уже скоро соберу
> новый. Сейчас "новый пропагатор" (altboot) вообще как бы "невидим".
> Переключение на tty2 происходит спустя некое время, либо сразу, если там
> есть диалог ввода. Поскольку в большинстве случаев загрузка автоматическая,
> ввода от пользователя не требуется и занимает считанные секунды, создаваемые
> "новым пропагатором" и bootchain консоли tty2 и tty3 бесследно исчезают, не
> создавая лишних мельканий на экране. Ещё красивее с плимутом -- всё
> происходит под "червячком", а вот если tty2 активируется, то отключается ещё
> и rootdelay.

Ааааа ... я забыл про plymouth.

> > зависимости от delay, то эти два if можно заменить на один exec.
> > 
> > 	setsid /bin/bash -c "/bin/activate-interactive-vt $delay" &
> > 
> > Скрипт /bin/activate-interactive-vt и так уже имеет #!/bin/bash. Тут ты
> > вызываешь баш только для того чтобы распарсить строчку.
> > 
> > Если ты используешь setsid из util-linux:
> > 
> > setsid -f /bin/activate-interactive-vt "$delay"
> > 
> > должно работать ровно также как у тебя написано. Если же это busybox, то
> > 
> > https://git.busybox.net/busybox/tree/util-linux/setsid.c#n44
> 
> Да я собственно из-за этого фрагмента и написал тебе, переделывал его раз
> 20, но так и не понял. Выше ты пишешь, что да, можно запускать setsid второй
> раз, это и есть как бы второй запуск (первый -- openvt). Если убрать тут
> setsid, результат будет таким же. Если убрать не setsid, а амперсанд в
> конце, тут будет задержка в $selay, чего я никак не мог победить. В обычной
> консоли оно себя так не ведёт. Потому и стоит сейчас if, а вообще
> предполагалось так: setsid activate-interactive-vt $delay безо всяких
> проверок и условий.

Там написано, что форк будет сделан только если просто sedsid отвалится.
"But doesn't fail if shell is not interactive". У тебя он как раз не
интерактивный. Поэтому setsid activate-interactive-vt просто висит.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27 13:53                   ` Alexey Gladkov
@ 2021-05-27 15:10                     ` Leonid Krivoshein
  2021-05-27 17:04                       ` Alexey Gladkov
  2021-05-30 20:34                     ` Leonid Krivoshein
  1 sibling, 1 reply; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-27 15:10 UTC (permalink / raw)
  To: make-initrd


27.05.2021 16:53, Alexey Gladkov пишет:
> On Thu, May 27, 2021 at 03:29:50PM +0300, Leonid Krivoshein wrote:
> [...]
>>> Я лишь могу посмотреть на разные куски кода и покомментировать.
>> Это безусловно очень полезно, твои советы особенно ценны для меня, хоть и
>> жаль твоего времени, т.к. код пока не финальный. За вчера добил liverw,
>> сейчас чиню checksum. Всё же я имел ввиду оценить идею, в целом. Например,
>> мне кажется, разделение на суб-фичи для bootchain само напрашивается. Но вот
>> стоит ли делить на под-пакеты -- вопрос?
> Если это упростит сопровождение, то почему бы нет. Вопрос в том, насколько
> будет сложно реализовать суб-фичи.
>

Глядя на другие проще. И ещё сделал в корне mix-altboot для 
разработчиков. Он не только смешивает все шаги в один каталог data 
подобно тому, как это делает make-initrd при создании образа, но и 
создаёт подкаталог hooks, в котором "склеивает" все пронумерованные 
хуки, чтобы легче было понять, куда вставлять свой новый код. Ищутся они 
через git grep use_hooks и будут описаны на ВиКи.


>> [...] Могу попробовать ещё раз.
> У тебя могло бы быть что-то вроде:
>
> save_image() { # right
> 	if [ -z "$dstreg" ]; then
> 		dd "of=$to" bs=32k 2>/dev/null
> 	else
> 		cat >"$to"
> 	fi
> }
>
> read_image() { # left
> 	if [ -n "$srcreg" ]; then
> 		pv -n -i 1 -- "$url"
> 		return
> 	fi
>
> 	opts="$opts --silent --no-buffer --connect-timeout 5"
> 	opts="$opts --max-redirs 5 --max-filesize $filesize"
> 	
> 	[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
> 		opts="${opts:+$opts }-u \"$user:$pass\""
>
> 	curl $opts -- "$url" |
> 		pv -n -i 1 -s "$filesize"
> }
>
> { read_image | save_image } 2>&1 |
> 	IM_gauge "[ Downloading image... ]" "$text"

Спасибо, попробую.


> [...]
>>> Зачем ты пытаешься использовать ttyN ? Тебе не хватает /dev/console ?
>> Нужно собрать диск с таксом, чтобы было наглядней. Хотя уже скоро соберу
>> новый. Сейчас "новый пропагатор" (altboot) вообще как бы "невидим".
>> Переключение на tty2 происходит спустя некое время, либо сразу, если там
>> есть диалог ввода. Поскольку в большинстве случаев загрузка автоматическая,
>> ввода от пользователя не требуется и занимает считанные секунды, создаваемые
>> "новым пропагатором" и bootchain консоли tty2 и tty3 бесследно исчезают, не
>> создавая лишних мельканий на экране. Ещё красивее с плимутом -- всё
>> происходит под "червячком", а вот если tty2 активируется, то отключается ещё
>> и rootdelay.
> Ааааа ... я забыл про plymouth.

Если ты про BUG #40090 , то я тестирую на срезе Сизифа, где make-initrd 
ещё 2.16.0 без этой баги, но обход уже известен.


>>> [...]
>> Да я собственно из-за этого фрагмента и написал тебе, переделывал его раз
>> 20, но так и не понял. Выше ты пишешь, что да, можно запускать setsid второй
>> раз, это и есть как бы второй запуск (первый -- openvt). Если убрать тут
>> setsid, результат будет таким же. Если убрать не setsid, а амперсанд в
>> конце, тут будет задержка в $selay, чего я никак не мог победить. В обычной
>> консоли оно себя так не ведёт. Потому и стоит сейчас if, а вообще
>> предполагалось так: setsid activate-interactive-vt $delay безо всяких
>> проверок и условий.
> Там написано, что форк будет сделан только если просто sedsid отвалится.
> "But doesn't fail if shell is not interactive". У тебя он как раз не
> интерактивный. Поэтому setsid activate-interactive-vt просто висит.

Так вот оно в чём дело! Тогда понятно... Обойдусь одним амперсандом. И, 
судя по этой реализации setsid, за зомбоками там тоже предлагается самим 
присматривать. :-) У меня вызов wait уже стоит перед выходом.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27 15:10                     ` Leonid Krivoshein
@ 2021-05-27 17:04                       ` Alexey Gladkov
  2021-05-27 17:11                         ` Leonid Krivoshein
  0 siblings, 1 reply; 27+ messages in thread
From: Alexey Gladkov @ 2021-05-27 17:04 UTC (permalink / raw)
  To: make-initrd

On Thu, May 27, 2021 at 06:10:48PM +0300, Leonid Krivoshein wrote:
> > > Да я собственно из-за этого фрагмента и написал тебе, переделывал его раз
> > > 20, но так и не понял. Выше ты пишешь, что да, можно запускать setsid второй
> > > раз, это и есть как бы второй запуск (первый -- openvt). Если убрать тут
> > > setsid, результат будет таким же. Если убрать не setsid, а амперсанд в
> > > конце, тут будет задержка в $selay, чего я никак не мог победить. В обычной
> > > консоли оно себя так не ведёт. Потому и стоит сейчас if, а вообще
> > > предполагалось так: setsid activate-interactive-vt $delay безо всяких
> > > проверок и условий.
> > Там написано, что форк будет сделан только если просто sedsid отвалится.
> > "But doesn't fail if shell is not interactive". У тебя он как раз не
> > интерактивный. Поэтому setsid activate-interactive-vt просто висит.
> 
> Так вот оно в чём дело! Тогда понятно... Обойдусь одним амперсандом. И, судя
> по этой реализации setsid, за зомбоками там тоже предлагается самим
> присматривать. :-) У меня вызов wait уже стоит перед выходом.

Ты реально видел зомбей после того как твой код (без wait и приседаний)
отработал ?

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27 17:04                       ` Alexey Gladkov
@ 2021-05-27 17:11                         ` Leonid Krivoshein
  0 siblings, 0 replies; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-27 17:11 UTC (permalink / raw)
  To: make-initrd


27.05.2021 20:04, Alexey Gladkov пишет:
> On Thu, May 27, 2021 at 06:10:48PM +0300, Leonid Krivoshein wrote:
>>>> Да я собственно из-за этого фрагмента и написал тебе, переделывал его раз
>>>> 20, но так и не понял. Выше ты пишешь, что да, можно запускать setsid второй
>>>> раз, это и есть как бы второй запуск (первый -- openvt). Если убрать тут
>>>> setsid, результат будет таким же. Если убрать не setsid, а амперсанд в
>>>> конце, тут будет задержка в $selay, чего я никак не мог победить. В обычной
>>>> консоли оно себя так не ведёт. Потому и стоит сейчас if, а вообще
>>>> предполагалось так: setsid activate-interactive-vt $delay безо всяких
>>>> проверок и условий.
>>> Там написано, что форк будет сделан только если просто sedsid отвалится.
>>> "But doesn't fail if shell is not interactive". У тебя он как раз не
>>> интерактивный. Поэтому setsid activate-interactive-vt просто висит.
>> Так вот оно в чём дело! Тогда понятно... Обойдусь одним амперсандом. И, судя
>> по этой реализации setsid, за зомбоками там тоже предлагается самим
>> присматривать. :-) У меня вызов wait уже стоит перед выходом.
> Ты реально видел зомбей после того как твой код (без wait и приседаний)
> отработал ?

В rdshell? Конечно.
Понятно, что это всё убивается после перехода в stage2.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1
  2021-05-27 13:53                   ` Alexey Gladkov
  2021-05-27 15:10                     ` Leonid Krivoshein
@ 2021-05-30 20:34                     ` Leonid Krivoshein
  1 sibling, 0 replies; 27+ messages in thread
From: Leonid Krivoshein @ 2021-05-30 20:34 UTC (permalink / raw)
  To: make-initrd

Привет!


27.05.2021 16:53, Alexey Gladkov пишет:
> On Thu, May 27, 2021 at 03:29:50PM +0300, Leonid Krivoshein wrote:
>> [...]
>> Отделил пока всё в bc-wip, чтобы тебе не мешаться, т.к. реально ещё
>> work-in-progress, но это всё и не предполагается пока ревьювить и коммитить
>> в таком виде. Разумеется, в финальном варианте оригинальный код будет
>> сохранён и сделаны правильные коммиты с историей, чтобы это стало частью
>> make-initrd, а не отдельным пакетом с фичами к нему. Конечно, есть вариант
>> оставить оригинальное название pipeline, но это имя у нынешних линуксовых
>> айтишников ассоциируется с другими вещами, bootchain мне кажется более
>> подходящим.
> Ок, теперь ясно.

В том же таске #272587 версия посвежее -- сложил туда логи загрузки в 
разных режимах, пример отдельно выносимого конфига и несколько 
скриншотов. Помимо всяких локальных методов загрузки уже заработали в 
первом приближении и сетевые, так что ключевая концепция стабильно 
зафиксирована, возможно придётся поработать над nfs и cifs методами.  
Новая напасть -- какая-то ошибка в dialog, не выводит backtitle при 
первом вызове после отделения через openvt, хотя и окружение одинаковое, 
и переменная туда точно передаётся. Пришлось пока сделать финт с WARM 
UP. И ещё меня предупредили о проблеме с выбором VT: она ожидается на 
машинах без графики, типа Power. Придётся придумать, как с этим жить.


> [...]
> У тебя могло бы быть что-то вроде:
>
> save_image() { # right
> 	if [ -z "$dstreg" ]; then
> 		dd "of=$to" bs=32k 2>/dev/null
> 	else
> 		cat >"$to"
> 	fi
> }
>
> read_image() { # left
> 	if [ -n "$srcreg" ]; then
> 		pv -n -i 1 -- "$url"
> 		return
> 	fi
>
> 	opts="$opts --silent --no-buffer --connect-timeout 5"
> 	opts="$opts --max-redirs 5 --max-filesize $filesize"
> 	
> 	[ "$method" != ftp ] || [ -z "$user" ] || [ -z "$pass" ] ||
> 		opts="${opts:+$opts }-u \"$user:$pass\""
>
> 	curl $opts -- "$url" |
> 		pv -n -i 1 -s "$filesize"
> }
>
> { read_image | save_image } 2>&1 |
> 	IM_gauge "[ Downloading image... ]" "$text"

Практически без изменений вставил, исправил и другие твои замечания, 
вынес всё АЛЬТ-специфичное в конфиг, который уедет в m-p. В этой связи, 
возможно, где-то будет лучше тебе самому править после принятия 
мега-патча, чтобы было видно, что это твои правки. :-)


>>>> Для последнего добавлен опциональный
>>>> общий тайм-аут, и теперь его можно использовать до altboot (localdev), что
>>>> позволит использовать подход пропагатора с диалогами и сканированием
>>>> устройств как fallback, если заданное в /proc/cmdline не будет найдено, зато
>>>> waitdev позволяет более тонко задавать спецификацию искомого и искать
>>>> несколько устройств, включая символьные. То есть, не внося изменений в код
>>>> altboot, можно красиво пристроить слева всю цепочку pipeline. А так по
>>>> дефолту мы собираем образы с root=bootchain bootchain=fg,altboot и всё, что
>>>> было в пропагаторе, сохранено для совместимости. Разве что добавили UUID к
>>>> методам disk и cdrom (в automatic=...).
>>> Для fg ты перезапускаешь bootchain-loop. Что будет если кто-нибудь сделает
>>> bootchain=altboot,fg ?
>> fg -- это переключение в интерактивный режим, для altboot он обязателен, без
>> него он не будет работать, так что пользователь сам себе злобный Буратино.
>> Но я для того и разделил демона и главный цикл, чтобы второй можно было
>> перезапускать в любой момент. И вот так всё будет работать просто отлично, я
>> проверял:
>>
>> bootchain=waitdev,waitdev,fg,altboot waitdev=LABEL=RW-OVERLAY waitdev=CDROM:
>>
>> Цикл демона опционально поддерживает интерактивный режим, может
>> перезапуститься и перейти на передний план в любой момент. fg -- это
>> псевдо-шаг в цепочке, чтобы поддерживать такой перезапуск, приходится
>> экспортировать ряд дополнительных переменных. Теоретически, ничто не мешает
>> сделать псевдо-шаг bg для возвращения обратно в фоновый режим. Результат
>> последнего waitdev будет использован шагом localdev, который запустит
>> altboot.
>>
>> Точнее, цепочку можно ещё и перезагружать в любой момент, меняя часть
>> переменных в главном цикле демона. Благодаря этому реализованы циклы,
>> условные переходы, в диалогах теперь можно возвращаться назад, что стало
>> намного удобнее, чем было в пропагаторе.
> Как будет готово нужно будет получше посмотреть на эту идею.

Думаю, core + interactive революционно меняться не будут, там всё 
готово, не считая Power. Буду думать на qemu с -no-graphics. Ещё виджеты 
можно подрихтовать, но это если очень сильно придираться.


>>>>> Верю тебе на слово :)
>>>> Спасибо за доверие. :-) Но я "работаю" не один, за мной проверяет на образах
>>>> Антон Мидюков, некоторые коллеги тоже на это посматривают пока издалека,
>>>> надеюсь, скоро присоединятся тестировщики. Не хочется, чтобы вышел факап в
>>>> p10 с заменой пропагатора.
>>> Это хорошо, но понимаю кода не помогает.
>> Сделаю нормальную документацию и на ближайшей конференции постараюсь
>> рассказать, как это работает. Но лучше чтения кода ничего нет. А к тебе это
>> ближе всего. :-)
> Да, я люблю код читать ))

А что насчёт логов? :-) Выложил все возможные варианты локальной 
загрузки с методом CD-ROM и комбинированной загрузки live-rootfs. В 
последний момент допустил оплошность с LiveCD-слоями, в двух логах это 
заметно, буду переделывать. И мне осталось сделать сетевой стенд для 
проверки NFS/SAMBA и более тщательной проверки HTTP/FTP-методов. 
Появилась поддержка overlayroot (для обычного корня) и LiveCD-слои 
(сквоши) для локальной загрузки в Live/Rescue.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2021-05-30 20:34 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-05 20:33 ` [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 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
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

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