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

[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 и переименовал файлы внутри.
Плюс нет истории. Теперь проследить разницу между ними просто нереально.

В таком виде, как оно есть сейчас, оно только так и может существовать:
как отдельные фичи. В такой ситуации не обязательно держать совместимость
с 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