[make-initrd] polld и проверка наличия /root/sbin/init

[make-initrd] polld и проверка наличия /root/sbin/init

[Антон Мидюков]

Здравствуйте

Предыстория: https://bugzilla.altlinux.org/44111

Заглавный вопрос: "в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется?"

Мне кажется, ответ найден: "При распараллеливании процесса монтирования корня (из сквоша, как минимум) на медленном сетевом соединении или достаточно медленном локальном накопителе".
Сейчас проблема стала хорошо воспроизводиться на ядре 6.2 при подключении по nfs или загрузке через ventoy и монтировании сквоша (без предварительной загрузки сквоша в память) на многоядерных процессорах.
Если ядро одно, то проблемы нет (проверено в виртуалке).
В ядре включили алгоритм монтирования оверлея CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU, и это проблему усугубило.
Но проблему крайне редко можно было поймать и раньше.

Отсюда выводы:
1. Факт монтирования корня недостаточное условие, существует переходный процесс монтирования
2. Обнаружение /sbin/init также не является достаточным условием, что можно продолжать загрузку, переходный процесс может оказаться длинным

Гипотеза о переходном процессе основана на сопоставлении двух логов chaind.log и polld.log
Ошибка об отсутствии /sbin/init была выдана на 1 секунду раньше, чем было завершено монтирование оверлея (оно занимало две секунды).

И другая проблема, вытекающая из этих:
bootchain после монтирования /sbin/init совершает ещё действия, поэтому нужно дождаться его выполнения.
В случае bootchain было бы надёжным запускать polld только тогда, когда он завершил свою работу.
Такое в принципе возможно?

-- 
С уважением, Антон Мидюков <antohami@basealt.ru>

Re: [make-initrd] polld и проверка наличия /root/sbin/init

[Leonid Krivoshein]

Добрый день!


On 4/6/23 04:28, Антон Мидюков wrote:
> Здравствуйте
>
> Предыстория: https://bugzilla.altlinux.org/44111
>
> Заглавный вопрос: "в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется?"

На p10 с пропагатором и более старым ядром не проявляется, так что все 
под подозрением, кроме этих двоих.))


> Мне кажется, ответ найден: "При распараллеливании процесса монтирования корня (из сквоша, как минимум) на медленном сетевом соединении или достаточно медленном локальном накопителе".
> Сейчас проблема стала хорошо воспроизводиться на ядре 6.2 при подключении по nfs или загрузке через ventoy и монтировании сквоша (без предварительной загрузки сквоша в память) на многоядерных процессорах.
> Если ядро одно, то проблемы нет (проверено в виртуалке).
> В ядре включили алгоритм монтирования оверлея CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU, и это проблему усугубило.
> Но проблему крайне редко можно было поймать и раньше.

А на p10 с пропагатором удавалось воспроизвести? Мне ни разу не удалось, 
хотя концовка с монтированием оверлея на скриптах у них схожа.


> Отсюда выводы:
> 1. Факт монтирования корня недостаточное условие, существует переходный процесс монтирования

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


> 2. Обнаружение /sbin/init также не является достаточным условием, что можно продолжать загрузку, переходный процесс может оказаться длинным

Получается, грубо говоря, что мы не знаем, в скольких тредах выполнения 
(снаружи bootchain) должна пройти синхронизация и чего именно ожидать. В 
bootchain команда mount завершилась успешно, ядро смонтировало 
устройства. Но polld почему-то об этом ничего не знает. По идее polld 
должен начинать проверку только после выхода из bootchain на вызове 
telinit 2, если эта проверка на нём.


> Гипотеза о переходном процессе основана на сопоставлении двух логов chaind.log и polld.log
> Ошибка об отсутствии /sbin/init была выдана на 1 секунду раньше, чем было завершено монтирование оверлея (оно занимало две секунды).

Похоже на какой-то глюк с ходом часов (хотя monotonic timestamp 
используется) или особенность работы telinit 2. У меня нет идей.


> И другая проблема, вытекающая из этих:
> bootchain после монтирования /sbin/init совершает ещё действия, поэтому нужно дождаться его выполнения.

В нём это делать бесполезно, там всё хорошо будет.


> В случае bootchain было бы надёжным запускать polld только тогда, когда он завершил свою работу.
> Такое в принципе возможно?

Тут большой вопрос, кто кого запускает. Не знаю назначение polld, но мне 
кажется именно его сообщения мы видим на /dev/console о запуске и 
завершении служб. Я считаю, что несмотря на пошаговую загрузку в 
bootchain, мы не можем останавливать event-driven механизм.



-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] polld и проверка наличия /root/sbin/init

[Leonid Krivoshein]

[-- Attachment #1: Type: text/plain, Size: 3840 bytes --]


On 4/6/23 09:00, Leonid Krivoshein wrote:
>> Отсюда выводы:
>> 1. Факт монтирования корня недостаточное условие, существует 
>> переходный процесс монтирования
>
> Насколько я понимаю, у каждой группы процессов может быть собственное 
> пространство имён монтирования, но описываемое поведение говорит о 
> том, что polld и chaind находятся в разных пространствах имён и ещё 
> что-то заставляет перемещать структуры в ядре от одной из групп к 
> другой. В общем странно и невероятно, потому что по идее, если 
> пространства разные, они изолированы, а если одинаковые, все процессы 
> должны увидеть изменения мгновенно. Тем не менее, мы наблюдаем именно 
> такое поведение, описанное Антоном. Весьма похоже на ядерный рейс, 
> поскольку на начальном этапе загрузка работой сильная и "мгновенности" 
> не случается. 

Сказанное выше больше похоже на тонкую шутку. На самом деле всё может 
быть проще...

Если какой-то внешний процесс по отношению bootchain среагировал на 
событие, увидев /root/sbin/init или что-то ещё, он же может вызвать 
telinit 2? Но на шаге squahfs это ещё не было финальным монтированием. В 
тот же момент bootchain продолжает процесс загрузки в шаге overlayfs, но 
polld, получив сигнал, уже начинает проверку финального условия.

bootchain выполняет telinit 2 только на последнем шаге rootfs, и раз 
polld начинает обработку раньше, сигнал посылает кто-то ещё и это 
следует из журнала chaind.log. Возможно, остановка polld на время работы 
bootchain поможет, я просто не знаю, можно ли это делать. Но я 
сталкивался с двойной обработкой события на финальном этапе в другом 
коде при использовании как раз метода загрузки.

При написании прототипа отдельной фичи overlayroot (вложил), закрывающей 
обычный корень на запись, приходится проверять повторный вход в 
/lib/initrd/boot/scripts/overlayroot. Без это оверлеи монтируются 
неправильно и система просто не грузится. А откуда возникает второе 
событие при срабатывании события "корень найден -- пора в stage2"? 
Раньше я полагал, что его создаёт монтирование overlay.

Драка между bootchain и polld может быть не результатом "гонки" в ядре 
или сторонним вызовом telinit 2, а результатом обработки этого второго 
события. Но я не так хорошо знаю архитектуру make-initrd.


-- 
WBR, Leonid Krivoshein.

[-- Attachment #2: overlayroot --]
[-- Type: text/plain, Size: 3806 bytes --]

#!/bin/sh -efu

. shell-error

OVERLAY="${1:-tmpfs}"
BASE=/usr/share/make-initrd/data

case "$OVERLAY" in
-i|--install)
	OVERLAY="${2:-tmpfs}"
	;;

-u|--uninstall)
	[ -d "$BASE/lib/initrd/boot/scripts" ] ||
		fatal "make-initrd is not installed."
	[ -x "$BASE/lib/initrd/boot/scripts/$PROG" ] ||
		fatal "The $PROG feature is not installed."
	sed -i -E "/\.\/$PROG/d" "$BASE"/lib/initrd/boot/method/localdev/check
	sed -i -E "/register_parameter string OVERLAYROOT/d" \
			"$BASE"/etc/initrd/cmdline.d/base
	sed -i -E "/MODULES_TRY_ADD \+= overlay/d" /etc/initrd.mk
	sed -i -E "/PUT_FILES \+= \/etc\/$PROG\.conf/d" /etc/initrd.mk
	rm -f -- "/etc/$PROG.conf" "$BASE/lib/initrd/boot/scripts/$PROG"
	echo "The $PROG feature was uninstalled!"
	exit 0
	;;

-h|--help)
	cat <<-EOF
	Usage $PROG [<command> | UUID=... | LABEL=... | <device>]

	Commands:
	  -i, --install     Install $PROG feature.
	  -u, --uninstall   Uninstall $PROG feature.
	  -h, --help        Show this help message and exit.

	UUID=, LABEL= and /dev/device specified a device with the R/W layer.
	By default R/W layer will be created on the TMPFS at the install time.
	After install or uninstall don't forget to run make-initrd [<args>]...
	EOF
	exit 0
	;;
esac

# Install feature
[ -d "$BASE/lib/initrd/boot/scripts" ] ||
	fatal "make-initrd is not installed."
[ ! -f "$BASE/lib/initrd/boot/scripts/$PROG" ] ||
	fatal "The $PROG feature already installed."
grep -qw "./$PROG" "$BASE"/lib/initrd/boot/method/localdev/check ||
	echo "./$PROG" >> "$BASE"/lib/initrd/boot/method/localdev/check
grep -qw "OVERLAYROOT" "$BASE"/etc/initrd/cmdline.d/base ||
	echo "register_parameter string OVERLAYROOT" \
		>> "$BASE"/etc/initrd/cmdline.d/base
echo "$PROG=$OVERLAY" > "/etc/$PROG.conf"
grep -qw "/etc/$PROG.conf" /etc/initrd.mk ||
	echo "PUT_FILES += /etc/$PROG.conf" >> /etc/initrd.mk
grep -w "MODULES_TRY_ADD" /etc/initrd.mk |grep -qw overlay ||
	echo "MODULES_TRY_ADD += overlay" >> /etc/initrd.mk
cat > "$BASE/lib/initrd/boot/scripts/$PROG" <<EOF
#!/bin/bash -efu

. shell-error
. /.initrd/initenv

# Handle first event only
[ ! -f /.initrd/$PROG ] ||
	exit 0
[ -n "\${$PROG-}" ] || [ ! -s /etc/$PROG.conf ] ||
	. /etc/$PROG.conf
:> /.initrd/$PROG

case "\${$PROG-}" in
"")	# Silent use default boot
	exit 0
	;;
disabled)
	echo "rootfs has return back to the read/write mode" >&2
	exit 0
	;;
tmpfs)
	echo "rootfs switched to the read-only mode, using tmpfs as overlay" >&2
	device=
	;;
UUID=?*)
	device="/dev/disk/by-uuid/\${$PROG##UUID=}"
	;;
LABEL=?*)
	device="/dev/disk/by-label/\${$PROG##LABEL=}"
	;;
/dev/?*)
	device="\$$PROG"
	;;
*)
	fatal "\$$PROG: invalid $PROG"
	;;
esac

# Wait the device
if [ -n "\$device" ]; then
	i=10

	while [ "\$i" != 0 ]; do
		dev="\$(readlink-e "\$device" 2>/dev/null ||:)"
		[ -z "\$dev" ] || [ ! -b "\$dev" ] ||
			break
		i="\$((\$i - 1))"
		sleep .5
	done

	[ -n "\$dev" ] && [ -b "\$dev" ] ||
		fatal "\$$PROG: invalid device specification"
	echo "rootfs switched to the read-only mode, using \$dev as overlay" >&2
	device="\$dev"
fi

echo "remounting / with overlayfs" >&2

mkdir -p -- "\$rootmnt.rw" "\$rootmnt.ro"

if [ -n "\$device" ]; then
	mount -- "\$device" "\$rootmnt.rw"
else
	mount -t tmpfs -o mode=755 -- none "\$rootmnt.rw"
fi

opts="lowerdir=\$rootmnt.ro"
opts="\$opts,upperdir=\$rootmnt.rw/rw"
opts="\$opts,workdir=\$rootmnt.rw/wk"

mkdir -p -- "\$rootmnt.rw/rw" "\$rootmnt.rw/wk"
mount --move -- "\$rootmnt" "\$rootmnt.ro"
mount -t overlay -o "\$opts" -- overlay "\$rootmnt"
mkdir -p -- "\$rootmnt/.ro" "\$rootmnt/.rw"
mount --move -- "\$rootmnt.ro" "\$rootmnt/.ro"
mount --move -- "\$rootmnt.rw" "\$rootmnt/.rw"
rmdir -- "\$rootmnt.rw" "\$rootmnt.ro"

echo "rootfs overlayed with overlayfs" >&2
EOF
chmod +x "$BASE/lib/initrd/boot/scripts/$PROG"
echo "The $PROG feature was installed!"

Re: [make-initrd] polld и проверка наличия /root/sbin/init

[Alexey Gladkov]

On Fri, Apr 07, 2023 at 01:27:13AM +0300, Leonid Krivoshein wrote:
> 
> On 4/6/23 09:00, Leonid Krivoshein wrote:
> >> Отсюда выводы:
> >> 1. Факт монтирования корня недостаточное условие, существует 
> >> переходный процесс монтирования
> >
> > Насколько я понимаю, у каждой группы процессов может быть собственное 
> > пространство имён монтирования, но описываемое поведение говорит о 
> > том, что polld и chaind находятся в разных пространствах имён

Это называется mount namespace. Для использования другого mountns нужно
сделать unshare/clone т.е. определённые действия. Просто так это не
случается. polld не меняет свой mountns. В make-initrd вообще никто не
использует namespaces поскольку это необязательная фича ядра и для задачи
не требуется.

> > и ещё 
> > что-то заставляет перемещать структуры в ядре от одной из групп к 
> > другой. В общем странно и невероятно, потому что по идее, если 
> > пространства разные, они изолированы, а если одинаковые, все процессы 
> > должны увидеть изменения мгновенно. Тем не менее, мы наблюдаем именно 
> > такое поведение, описанное Антоном. Весьма похоже на ядерный рейс, 
> > поскольку на начальном этапе загрузка работой сильная и "мгновенности" 
> > не случается. 
> 
> Сказанное выше больше похоже на тонкую шутку. На самом деле всё может 
> быть проще...
> 
> Если какой-то внешний процесс по отношению bootchain среагировал на 
> событие, увидев /root/sbin/init или что-то ещё, он же может вызвать 
> telinit 2?

Такой процесс есть - polld. Я же про это уже говорил.

> Но на шаге squahfs это ещё не было финальным монтированием. В 
> тот же момент bootchain продолжает процесс загрузки в шаге overlayfs, но 
> polld, получив сигнал, уже начинает проверку финального условия.
> 
> bootchain выполняет telinit 2 только на последнем шаге rootfs, и раз 
> polld начинает обработку раньше, сигнал посылает кто-то ещё и это 
> следует из журнала chaind.log. Возможно, остановка polld на время работы 
> bootchain поможет, я просто не знаю, можно ли это делать. Но я 
> сталкивался с двойной обработкой события на финальном этапе в другом 
> коде при использовании как раз метода загрузки.
> 
> При написании прототипа отдельной фичи overlayroot (вложил), закрывающей 
> обычный корень на запись, приходится проверять повторный вход в 
> /lib/initrd/boot/scripts/overlayroot. Без это оверлеи монтируются 
> неправильно и система просто не грузится. А откуда возникает второе 
> событие при срабатывании события "корень найден -- пора в stage2"? 
> Раньше я полагал, что его создаёт монтирование overlay.
> 
> Драка между bootchain и polld может быть не результатом "гонки" в ядре 
> или сторонним вызовом telinit 2, а результатом обработки этого второго 
> события. Но я не так хорошо знаю архитектуру make-initrd.
> 
> 
> -- 
> WBR, Leonid Krivoshein.

> #!/bin/sh -efu
> 
> . shell-error
> 
> OVERLAY="${1:-tmpfs}"
> BASE=/usr/share/make-initrd/data
> 
> case "$OVERLAY" in
> -i|--install)
> 	OVERLAY="${2:-tmpfs}"
> 	;;
> 
> -u|--uninstall)
> 	[ -d "$BASE/lib/initrd/boot/scripts" ] ||
> 		fatal "make-initrd is not installed."
> 	[ -x "$BASE/lib/initrd/boot/scripts/$PROG" ] ||
> 		fatal "The $PROG feature is not installed."
> 	sed -i -E "/\.\/$PROG/d" "$BASE"/lib/initrd/boot/method/localdev/check
> 	sed -i -E "/register_parameter string OVERLAYROOT/d" \
> 			"$BASE"/etc/initrd/cmdline.d/base
> 	sed -i -E "/MODULES_TRY_ADD \+= overlay/d" /etc/initrd.mk
> 	sed -i -E "/PUT_FILES \+= \/etc\/$PROG\.conf/d" /etc/initrd.mk
> 	rm -f -- "/etc/$PROG.conf" "$BASE/lib/initrd/boot/scripts/$PROG"
> 	echo "The $PROG feature was uninstalled!"
> 	exit 0
> 	;;
> 
> -h|--help)
> 	cat <<-EOF
> 	Usage $PROG [<command> | UUID=... | LABEL=... | <device>]
> 
> 	Commands:
> 	  -i, --install     Install $PROG feature.
> 	  -u, --uninstall   Uninstall $PROG feature.
> 	  -h, --help        Show this help message and exit.
> 
> 	UUID=, LABEL= and /dev/device specified a device with the R/W layer.
> 	By default R/W layer will be created on the TMPFS at the install time.
> 	After install or uninstall don't forget to run make-initrd [<args>]...
> 	EOF
> 	exit 0
> 	;;
> esac
> 
> # Install feature
> [ -d "$BASE/lib/initrd/boot/scripts" ] ||
> 	fatal "make-initrd is not installed."
> [ ! -f "$BASE/lib/initrd/boot/scripts/$PROG" ] ||
> 	fatal "The $PROG feature already installed."
> grep -qw "./$PROG" "$BASE"/lib/initrd/boot/method/localdev/check ||
> 	echo "./$PROG" >> "$BASE"/lib/initrd/boot/method/localdev/check
> grep -qw "OVERLAYROOT" "$BASE"/etc/initrd/cmdline.d/base ||
> 	echo "register_parameter string OVERLAYROOT" \
> 		>> "$BASE"/etc/initrd/cmdline.d/base
> echo "$PROG=$OVERLAY" > "/etc/$PROG.conf"
> grep -qw "/etc/$PROG.conf" /etc/initrd.mk ||
> 	echo "PUT_FILES += /etc/$PROG.conf" >> /etc/initrd.mk
> grep -w "MODULES_TRY_ADD" /etc/initrd.mk |grep -qw overlay ||
> 	echo "MODULES_TRY_ADD += overlay" >> /etc/initrd.mk
> cat > "$BASE/lib/initrd/boot/scripts/$PROG" <<EOF
> #!/bin/bash -efu
> 
> . shell-error
> . /.initrd/initenv
> 
> # Handle first event only
> [ ! -f /.initrd/$PROG ] ||
> 	exit 0
> [ -n "\${$PROG-}" ] || [ ! -s /etc/$PROG.conf ] ||
> 	. /etc/$PROG.conf
> :> /.initrd/$PROG
> 
> case "\${$PROG-}" in
> "")	# Silent use default boot
> 	exit 0
> 	;;
> disabled)
> 	echo "rootfs has return back to the read/write mode" >&2
> 	exit 0
> 	;;
> tmpfs)
> 	echo "rootfs switched to the read-only mode, using tmpfs as overlay" >&2
> 	device=
> 	;;
> UUID=?*)
> 	device="/dev/disk/by-uuid/\${$PROG##UUID=}"
> 	;;
> LABEL=?*)
> 	device="/dev/disk/by-label/\${$PROG##LABEL=}"
> 	;;
> /dev/?*)
> 	device="\$$PROG"
> 	;;
> *)
> 	fatal "\$$PROG: invalid $PROG"
> 	;;
> esac
> 
> # Wait the device
> if [ -n "\$device" ]; then
> 	i=10
> 
> 	while [ "\$i" != 0 ]; do
> 		dev="\$(readlink-e "\$device" 2>/dev/null ||:)"
> 		[ -z "\$dev" ] || [ ! -b "\$dev" ] ||
> 			break
> 		i="\$((\$i - 1))"
> 		sleep .5
> 	done
> 
> 	[ -n "\$dev" ] && [ -b "\$dev" ] ||
> 		fatal "\$$PROG: invalid device specification"
> 	echo "rootfs switched to the read-only mode, using \$dev as overlay" >&2
> 	device="\$dev"
> fi
> 
> echo "remounting / with overlayfs" >&2
> 
> mkdir -p -- "\$rootmnt.rw" "\$rootmnt.ro"
> 
> if [ -n "\$device" ]; then
> 	mount -- "\$device" "\$rootmnt.rw"
> else
> 	mount -t tmpfs -o mode=755 -- none "\$rootmnt.rw"
> fi
> 
> opts="lowerdir=\$rootmnt.ro"
> opts="\$opts,upperdir=\$rootmnt.rw/rw"
> opts="\$opts,workdir=\$rootmnt.rw/wk"
> 
> mkdir -p -- "\$rootmnt.rw/rw" "\$rootmnt.rw/wk"
> mount --move -- "\$rootmnt" "\$rootmnt.ro"
> mount -t overlay -o "\$opts" -- overlay "\$rootmnt"
> mkdir -p -- "\$rootmnt/.ro" "\$rootmnt/.rw"
> mount --move -- "\$rootmnt.ro" "\$rootmnt/.ro"
> mount --move -- "\$rootmnt.rw" "\$rootmnt/.rw"
> rmdir -- "\$rootmnt.rw" "\$rootmnt.ro"
> 
> echo "rootfs overlayed with overlayfs" >&2
> EOF
> chmod +x "$BASE/lib/initrd/boot/scripts/$PROG"
> echo "The $PROG feature was installed!"

> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd


-- 
Rgrds, legion

Re: [make-initrd] polld и проверка наличия /root/sbin/init

[Alexey Gladkov]

On Thu, Apr 06, 2023 at 08:28:20AM +0700, Антон Мидюков wrote:
> Здравствуйте
> 
> Предыстория: https://bugzilla.altlinux.org/44111
> 
> Заглавный вопрос: "в каком случае может быть так, что init в смонтированном корне в первые секунды нет, а потом оно чудесным образом появляется?"
> 
> Мне кажется, ответ найден: "При распараллеливании процесса монтирования корня (из сквоша, как минимум) на медленном сетевом соединении или достаточно медленном локальном накопителе".
> Сейчас проблема стала хорошо воспроизводиться на ядре 6.2 при подключении по nfs или загрузке через ventoy и монтировании сквоша (без предварительной загрузки сквоша в память) на многоядерных процессорах.
> Если ядро одно, то проблемы нет (проверено в виртуалке).
> В ядре включили алгоритм монтирования оверлея CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU, и это проблему усугубило.
> Но проблему крайне редко можно было поймать и раньше.
> 
> Отсюда выводы:
> 1. Факт монтирования корня недостаточное условие, существует переходный процесс монтирования
> 2. Обнаружение /sbin/init также не является достаточным условием, что можно продолжать загрузку, переходный процесс может оказаться длинным

Для обычных систем обнаружения INIT необходимое и достаточное условие.
initramfs ничего не знает о системе, кроме того, что там должен быть INIT.

Для более сложных случаев можно указать свой boot method:

/lib/initrd/boot/method/SOMETHING/check
/lib/initrd/boot/method/SOMETHING/action

echo SOMETHING > /etc/initrd/method

> Гипотеза о переходном процессе основана на сопоставлении двух логов chaind.log и polld.log
> Ошибка об отсутствии /sbin/init была выдана на 1 секунду раньше, чем было завершено монтирование оверлея (оно занимало две секунды).
> 
> И другая проблема, вытекающая из этих:
> bootchain после монтирования /sbin/init совершает ещё действия, поэтому нужно дождаться его выполнения.
> В случае bootchain было бы надёжным запускать polld только тогда, когда он завершил свою работу.
> Такое в принципе возможно?

В новой версии make-initrd у pipeline будет шаг останавливающий или
запускающий сервисы. В bootchain вы может сделать такой же шаг. Хотя я
считаю более правильным сделать свой boot method с нужными дополнительными
проверками.

-- 
Rgrds, legion

Re: [make-initrd] polld и проверка наличия /root/sbin/init

[Leonid Krivoshein]

Привет!


On 4/6/23 12:29, Alexey Gladkov wrote:
> [...]
> Для более сложных случаев можно указать свой boot method:
>
> /lib/initrd/boot/method/SOMETHING/check
> /lib/initrd/boot/method/SOMETHING/action
>
> echo SOMETHING > /etc/initrd/method

Спасибо! Предположительно помогло создание симлинка check => /bin/false 
в altboot, т.е. способ решения проблемы через boot method сработал: ALT 
#45787. Но проблема была в другом месте...


>> [...]
>> bootchain после монтирования /sbin/init совершает ещё действия, поэтому нужно дождаться его выполнения.
>> В случае bootchain было бы надёжным запускать polld только тогда, когда он завершил свою работу.
>> Такое в принципе возможно?
> В новой версии make-initrd у pipeline будет шаг останавливающий или
> запускающий сервисы. В bootchain вы может сделать такой же шаг.

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


> Хотя я
> считаю более правильным сделать свой boot method с нужными дополнительными
> проверками.

В ходе разборок заметил странную штуку...

1. pipeline раньше использовал telinit 2 в шаге rootfs.
2. bootchain делал изначально точно так же.
3. В какой-то момент в pipeline/rootfs поменялся механизм: вместо 
telinit 2 стал перезаписываться boot method => localdev.
4. Почти сразу я портировал это изменение в bootchain/rootfs.
5. И pipeline, и bootchain изначально меняют boot method на себя и оба 
не предоставляют функций check и action для проверки специального 
условия нахождения корня, полагаясь на то, что когда цепочка будет 
завершена, метод загрузки переключится на localdev и там уже есть нужный 
функционал проверки.
7. Странное и неожиданное здесь то, что данный функционал работает 
параллельно с pipeline или bootchain несмотря на то, что метод загрузки 
изменён в самом начале цепочки -- это и есть причина рейса.
8. Для pipeline данная проблема остаётся в равной степени актуальной.
9. Для bootchain сделал лишь одно изменение: перенёс переключение на 
метод localdev из шага rootfs за конец цикла демона chaind чтобы 
успевать переписать в stage2 файл журнала.
10. Добавлять в bootchain или pipeline проверку успешности прохождения 
цепочки, наверное, можно, но я не стал городить огород, поскольку на 
Сизифных регулярках, в основном, используется altboot поверх bootchain.
11. Проверять что-либо в altboot смысла не было -- он не первый и не 
последний шаг bootchain, просто переписать boot method -- недостаточно, 
т.к. bootchain это делает, а толку ноль, но объединив всё вместе с 
симлинком на /bin/false результат неожиданно проблему вылечил.

Короче говоря, в make-initrd проверка метода localdev почему-то 
срабатывает, даже если метод загрузки установлен не localdev, и побороть 
это помогает только создание собственного check.



-- 
WBR, Leonid Krivoshein.