Bug 41462

К сожалению, не приведён журнал загрузки chaind.log. Судя по ошибке "пытается скачать /dist/regular-xfce-20211124-aarch64.iso/live", используется ошибочная строка запуска с указанием ramdisksize=... Дело в том, что сейчас она служит "индикатором" для вариантов загрузки по FTP/HTTP. Если указан ramdisksize=..., образ на сервере должен быть распакован, этого ожидает инсталлятор. Если нет параметра ramdisksize=..., должна получиться совсем иная цепочка загрузки и такой ошибки вылезти не должно.

(In reply to Leonid Krivoshein from comment #1)
> К сожалению, не приведён журнал загрузки chaind.log.

До него невозможно добраться: диалог "HTTP-server connection data" блокирует консоль.
На Ctrl+C не реагирует, пролистать вверх не даёт (даже лог ядра не прочитать).
Есть, конечно, замечательная (без тени иронии) кнопка "Cancel", но после нажатия
появляется не менее назойливый диалог "Please choose...", и добраться до shell из
него ничуть не легче.

> Судя по ошибке "пытается скачать /dist/regular-xfce-20211124-aarch64.iso/live",
> используется ошибочная строка запуска с указанием ramdisksize=...

Во-первых, нет. Как уже написал ранее, командная строка ядра:

root=bootchain bootchain=fg,altboot ip=dhcp4 changedisk fastboot live automatic=method:http,network:dhcp,server:10.42.0.4,directory:/dist/regular-xfce-20211124-aarch64.iso stagename=live showopts

> Дело в том, что сейчас она служит "индикатором" для вариантов загрузки по FTP/HTTP.
> Если указан ramdisksize=..., образ на сервере должен быть распакован,

Странная логика. Почему бы просто не сделать HEAD http://${server}/${directory}
(HEAD http://10.42.0.4/dist/regular-xfce-20211124-aarch64.iso), и не посмотреть, что это.
Например, если Content-Type "application/octet-stream", то скорее всего это ISO, а не директория.

> этого ожидает инсталлятор.

1. Я liveCD пытаюсь загрузить, какая разница, что ожидает инсталлятор.
2. Инсталлятор мог бы проверить наличие репозитория в директории /image/ALTLinux, а не пользоваться необоснованными предположениями.

> Если нет параметра ramdisksize=..., должна получиться совсем иная цепочка загрузки и такой ошибки вылезти не должно.

В теории может и не должно, но на практике таки есть.

(Ответ для Alexey Sheplyakov на комментарий #2)
> До него невозможно добраться: диалог "HTTP-server connection data" блокирует
> консоль.
Его можно изначально направить на ttyS0 или на earlycon, отключив вывод диалогов. Просто добавьте bc_debug noaskuser к параметрам загрузки.

> Во-первых, нет. Как уже написал ранее, командная строка ядра:
Без журнала я не смогу понять, в чём проблема. Нужно также знать, с какой версией make-initrd-bootchain собирался образ.

> Странная логика.
Логика такая: с ramdisk_size=... -- поведение пропагатора, без него -- новый вариант для netstart.

> Почему бы просто не сделать HEAD
Потому что я не знаю надёжного способа определения по FTP и HTTP того, что мы имеем дело с файлом, а не каталогом. Но использовать что-то другое для переключения логики, думаю, можно реализовать.

> Я liveCD пытаюсь загрузить, какая разница, что ожидает инсталлятор.
Разница в том, что будет экспортировано в stage2, а поддерживаются оба варианта загрузки по FTP/HTTP, они реализованы по-разному.

> Инсталлятор мог бы проверить наличие репозитория в директории
Нужно переделывать инсталлятор, altboot должен быть совместим с ним без такой необходимости.

> В теории может и не должно, но на практике таки есть.
Так мы сетевую загрузку проверяем на всех архитектурах и я бы даже сказал, что от процессора сетевая загрузка совсем не зависит. Надо спросить у Антона Мидюкова: когда последний раз проверялась сетевая загрузка на aarch64 и riscv64? Я проверял на x86, но это можно и сейчас на любой регулярке проверить.

(Ответ для Leonid Krivoshein на комментарий #3)
> (Ответ для Alexey Sheplyakov на комментарий #2)
> > В теории может и не должно, но на практике таки есть.
> Так мы сетевую загрузку проверяем на всех архитектурах и я бы даже сказал,
> что от процессора сетевая загрузка совсем не зависит. Надо спросить у Антона
> Мидюкова: когда последний раз проверялась сетевая загрузка на aarch64 и
> riscv64? Я проверял на x86, но это можно и сейчас на любой регулярке
> проверить.

На riscv64 проверялась только локальная в qemu. Образы iso только на позапрошлой недели впервые были собраны. Так что это какой-то странный вопрос про riscv64.

Сетевую три недели назад пробовал.

(Ответ для Антон Мидюков на комментарий #4)
> На riscv64 проверялась только локальная в qemu.
Их нельзя пока на FTP/HTTP выкладывать?

> Сетевую три недели назад пробовал.
Сейчас проверил, всё работает ровно так, как я описал выше. Любой желающий может легко повторить с такими же параметрами загрузки. Только я увидел один момент, он видимо в m-p: мы же переименовали журнал в chaind.log, а в новых образ он почему-то по-старому называется /var/log/bootchained.log. Прилагаю оба -- нормальный без ramdisk_size и с ramdisk_size, где ищется ISO-образ/rescue с ошибкой 404.

Created attachment 10003 [details]
успешная загрузка по HTTP если не указывать ramdisk_size

Created attachment 10004 [details]
загрузка целого образа по HTTP невозможна при указании ramdisk_size

На всякий, для проверки использовал ISO-образ последней ALT Rescu от 24.11.2021:
https://mirror.yandex.ru/altlinux-nightly/current/regular-rescue-latest-x86_64.iso

Created attachment 10005 [details]
загрузка целого образа по HTTP при полном отсутвии видео-карты

Ещё вариант успешной загрузки с того же образа, но уже максимально приближенный к Baikal-M: здесь нет никаких диалогов совсем, через 180 секунд при неуспехе появится обычный rdshell, но в данном случае загрузка прошла успешно, подключаться к машине пришлось по ssh, поэтому параметры такие. В случае LiveCD я бы подключался по VNC к этой виртуалке.

(Ответ для Alexey Sheplyakov на комментарий #2)
> До него невозможно добраться: диалог "HTTP-server connection data" блокирует
> консоль.
> На Ctrl+C не реагирует, пролистать вверх не даёт (даже лог ядра не
> прочитать).
> Есть, конечно, замечательная (без тени иронии) кнопка "Cancel", но после
> нажатия
> появляется не менее назойливый диалог "Please choose...", и добраться до
> shell из
> него ничуть не легче.

Тут: https://bugzilla.altlinux.org/show_bug.cgi?id=41097#c6 и в предыдущем комментарии подробно расписаны все варианты для Байкал-М, специально же делал по вашему запросу. Сейчас не может возникнуть ситуации, что нельзя добраться до журнала, а по журналу происходящее всегда очевидно.