1. Беру образ http://nightly.altlinux.org/sisyphus-aarch64/snapshots/20211124/regular-xfce-20211124-aarch64.iso 2. Извлекаю файлы /boot/vmlinuz, /boot/initrd.img, кладу в директорию, доступную по tftp 3. Образ кладу в директорию, доступную по http. 4. Пытаюсь загрузиться по сети. Командная строка ядра: 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 Ожидания: компьютер грузится по сети, скачивает ISO по http, и далее запускается с него. Реальность: наблюдаю диалог "HTTP-server connection data". Это провал, т.к. загрузка должна быть полностью автоматической. Судя по логам nginx, вместо /dist/regular-xfce-20211124-aarch64.iso initramfs упорно пытается скачать /dist/regular-xfce-20211124-aarch64.iso/live (которого нет). Даже если в диалоге "HTTP-server connection data" указать правильный путь (/dist/regular-xfce-20211124-aarch64.iso)
К сожалению, не приведён журнал загрузки 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 и в предыдущем комментарии подробно расписаны все варианты для Байкал-М, специально же делал по вашему запросу. Сейчас не может возникнуть ситуации, что нельзя добраться до журнала, а по журналу происходящее всегда очевидно.
