[make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1

Thu May 27 15:29:50 MSK 2021

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.