https://github.com/LAKostis/mkimage-profiles - ссылка на мои изменения, ветка master.

Образ при помощи dd записан на флешку?

Привет! Очень интересная ошибка! Какой-то необычный образ. Ранее altboot не сталкивался с отсутствием свободных loop-устройств, когда losetup -f ничего не выдаёт. Похожее было с /dev/ramN, но для них сделан fallback на tmpfs. Если тут задействован режим forensic, возможно спасёт какой-нибудь max_loop=...

Подебажить можно так: добавив параметр bc_debug, можно увидеть все детали происходящего в /var/log/chaind.log , можно добавить rdshell для получения shell в stage1. Если хитрое железо, можно перенаправить журнал сразу на консоль или в /dev/ttyprintk (на earlycon), для этого указываются rdlog=console console=ttyS0,... или rdlog=printk console=ttyS0,... earlycon=... igonre_loglevel.

(In reply to Антон Мидюков from comment #2)
> Образ при помощи dd записан на флешку?

да

Я предполагаю, что проблема в отсутствии обработки ситуации, когда поддержки loop нет в ядре и оно модулем (см. скриншоты).

Created attachment 9899 [details]
squashfs step failed

Created attachment 9900 [details]
missing loop module

После загрузки loop и передачи параметра callnum squashfs отработал без ошибок.

(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #7)
> После загрузки loop и передачи параметра callnum squashfs отработал без
> ошибок.
Понятно. Первый раз вижу, чтобы loop загружался модулем, ибо даже в писании сказано, что м.б. только Y и N: https://github.com/torvalds/linux/blob/master/drivers/block/Kconfig#L156 . В такой необычной конфигурации воркэраундом может быть добавление в /etc/initrd.mk строки MODULES_PRELOAD += loop . Хм, а как вообще правильно? Ведь в большинстве конфигураций он не модулем собирается.

Нет, модулем тоже можно. Но всё равно такого не встречал. Тогда в будущей версии altboot стоит добавить что-то вроде: modprobe loop 2>/dev/null ||: или не стоит?

(In reply to Leonid Krivoshein from comment #9)
> Нет, модулем тоже можно. Но всё равно такого не встречал. Тогда в будущей
> версии altboot стоит добавить что-то вроде: modprobe loop 2>/dev/null ||:
> или не стоит?

ну я себе добавил ;)

(In reply to Leonid Krivoshein from comment #8)
> (Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #7)
> > После загрузки loop и передачи параметра callnum squashfs отработал без
> > ошибок.
> Понятно. Первый раз вижу, чтобы loop загружался модулем, ибо даже в писании
> сказано, что м.б. только Y и N:
> https://github.com/torvalds/linux/blob/master/drivers/block/Kconfig#L156 . В
> такой необычной конфигурации воркэраундом может быть добавление в
> /etc/initrd.mk строки MODULES_PRELOAD += loop . Хм, а как вообще правильно?
> Ведь в большинстве конфигураций он не модулем собирается.

Думаю это тяжелое наследие propagator, и когда то (в эпоху дискет :) этот модуль был обычным явлением.

В моих ядрах (wks) я эту конфигурацию точно не менял и она переехала еще с альтовых ядер имени vsu@

(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #10)
> (In reply to Leonid Krivoshein from comment #9)
> > Тогда в будущей версии altboot стоит добавить что-то вроде:
> > modprobe loop 2>/dev/null ||: или не стоит?
> ну я себе добавил ;)
Интересно узнать, что чем это закончится. :-)

(Ответ для Konstantin A Lepikhov (L.A. Kostis) на комментарий #11)
> (In reply to Leonid Krivoshein from comment #8)
> > В такой необычной конфигурации воркэраундом может быть добавление в
> > /etc/initrd.mk строки MODULES_PRELOAD += loop . Хм, а как вообще правильно?
> > Ведь в большинстве конфигураций он не модулем собирается.
> Думаю это тяжелое наследие propagator, и когда то (в эпоху дискет :) этот
> модуль был обычным явлением.
Эти две стадии установщика жёстко связаны: http://git.altlinux.org/gears/i/installer.git?p=installer.git;a=blob;f=installer/preinstall.d/99-cdrom.sh;h=ffc9fd7b32405d130669b5eae6ac3859a01a1b04;hb=8d89471c308ae386e780da15a0e17ba95d19091c -- нельзя без loop, там подменяется backing device в процессе установки, так что не только от пропагатора зависит.

Так может достаточно просто добавить loop в initrd, а он сам подгрузится при обращении к losetup? Или модуль в initrd был, но не подгрузился?

(Ответ для Антон Мидюков на комментарий #13)
> Так может достаточно просто добавить loop в initrd, а он сам подгрузится при
> обращении к losetup? Или модуль в initrd был, но не подгрузился?
Модуль в initramfs был, но он не подгрузился. В следующем релизе исправлю. Однако есть нюанс -- как сделать опциональное дотаскивание модуля в initramfs? Достаточно ли будет добавить здесь: http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=bootchain-altboot/config.mk;h=4572f4cb72f24c84a2e8f52539905a52c5222c8d;hb=d9135c3936ee28b0153746d690724c6f650b5a07 чего-то вроде: BOOTCHAIN_ALTBOOT_MODULES = loop ? Не будет ли это ломать сборку, если модуль вкомпилирован в ядро?

Task #288727, надо проверять...

Проверил на rescue с включенным режимом forensic, вроде ничего не сломалось. Отправлю тогда в Сизиф...

(Ответ для Leonid Krivoshein на комментарий #16)
> Проверил на rescue с включенным режимом forensic, вроде ничего не сломалось.
> Отправлю тогда в Сизиф...

Ругани точно никакой? Типа Modules preload failed

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

 Tue Nov 02 2021 Leonid Krivoshein <klark@altlinux> 0.1.5-alt7
 - bootchain-altboot: try to load module 'loop' (ALT #41263).

(Ответ для Антон Мидюков на комментарий #17)
> Ругани точно никакой? Типа Modules preload failed
Не, всё хорошо. Модуль добавляется через MODULES_TRY_ADD += ..., загрузка выполняется единожды и с подавлением вывода об ошибках.