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

[Alexey Gladkov]

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