Просуммирую тут, что есть, что обсудили, и чего надо делать...

Как показывает связанный баг #44111, да и по логике, никакого отношения bootchain к зависанию и анализу параметра init= не имеет. К этому моменту он уже отработал и вышел, далее работает код в make-initrd и в смежном баге говорится о выдаче ошибки при проверке перед запуском второй стадии. Так что заголовок бага некорректен.

Другое дело, что в altboot, если включены диалоги ввода (а по умолчанию они включены), нам ничто не мешает сделать ещё одну проверку на предмет наличия init-скрипта во второй стадии, и, если видна проблема, выдавать диалог с ошибкой. Сделать это лучше всего на последнем шаге liveboot. Но тогда это уже не баг, а фичреквест.

Однако почти каждый шаг altboot может работать как сам по себе (повторяться в цепочке bootchain), так и в режиме совместимости с пропагатором, где есть определённая последовательность и каждый шаг выполняется лишь единожды. По умолчанию при загрузке на Сизифе сейчас используется второй вариант. Думаю, проверка и диалог в liveboot на последнем этапе должны выполняться только в этом втором режиме совместимости с пропагатором.

Собрал пробное задание #308896. Хорошо бы тоже проверить. Потом можно будет объединить все успешные изменения.

(Ответ для Leonid Krivoshein на комментарий #2)
> Собрал пробное задание #308896. Хорошо бы тоже проверить. Потом можно будет
> объединить все успешные изменения.

Не работает, в логе ошибка:
/lib/bootchain/liveboot: line 158: IM_errmsg: command not found

И почему нужно проверять в liveboot, а не в rootfs? В rootfs гораздо логичнее и универсальнее. И почему бы не текстом вывести, если не хочется в rootfs графику тащить?

(Ответ для Антон Мидюков на комментарий #3)
> Не работает, в логе ошибка:
> /lib/bootchain/liveboot: line 158: IM_errmsg: command not found
Мой косяк, переделаю. Нужно было эту форму заинклюдить.

> И почему нужно проверять в liveboot, а не в rootfs? В rootfs гораздо
> логичнее и универсальнее.
rootfs -- это шаг bootchain, т.е. изначально pipeline. Его задача перевести загрузку на уровень telinit 2. Ещё он может последний шаг переместить в /root, но в пропагаторном режиме это уже и так сделано ранее. Главным образом rootfs не имеет никакого отношения к altboot, к диалогам, к каким-либо проверкам.

liveboot -- последний шаг altboot в режиме совместимости с пропагатором, и только в этом режиме стоит проверять и выводить диалог по выше обозначенной причине.

> И почему бы не текстом вывести, если не хочется в rootfs графику тащить?
Насколько я понимаю, к задаче bootchain/altboot это уже не относится и какая-то диагностика в логах или где-то ещё при такой ошибке будет предоставлена самим make-initrd, судя по смежной задаче. Мы тут средствами altboot просто чуть раньше проверяем то же самое и выводим диалог более красиво.

(Ответ для Leonid Krivoshein на комментарий #4)
> (Ответ для Антон Мидюков на комментарий #3)
> > И почему бы не текстом вывести, если не хочется в rootfs графику тащить?
> Насколько я понимаю, к задаче bootchain/altboot это уже не относится и
> какая-то диагностика в логах или где-то ещё при такой ошибке будет
> предоставлена самим make-initrd, судя по смежной задаче. Мы тут средствами
> altboot просто чуть раньше проверяем то же самое и выводим диалог более
> красиво.

legion@ обещает скоро в Сизифе, так что предлагаю, пока ничего не делать.

Исправления:
https://bugzilla.altlinux.org/show_bug.cgi?id=44111

вполне достаточно. Ничего в bootchain делать не требуется.

Баг в том, что если после шага squashfs  /root нет $INIT, то по крайней мере в диалоговом режиме altboot нет смысла накладывать оверлей, есть смысл вывести диалог о фатальной ошибке. Исправил в #318262.

make-initrd-bootchain-0.1.5-alt12 -> sisyphus:

 Sun Apr 09 2023 Leonid Krivoshein <klark@altlinux> 0.1.5-alt12
 - bootchain-altboot: use altboot forever by check logic (ALT #45787)
 - bootchain-core: delay switching to localdev boot method after loop
 - download: don't set NFS method when loading via HTTP (ALT #43970)
 - liveboot: add check for init= in propagator mode (ALT #44061)