[devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов

[Leonid Krivoshein]

13.09.2021 4:27, Антон Мидюков пишет:
> 13.09.2021 06:01, Leonid Krivoshein пишет:
>> Всем привет!
>>
>>
>> Антону Мидюкову практически удалось воплотить в m-p идею мини-образа ISO, позволяющего устанавливать (загружать или запускать) другие "большие" дистрибутивы без предварительного скачивания и записи на флэшку. В мини-образе netstart нет собственного stage2, есть только ядро и initrd, даже несколько на выбор. Основной дистрибутив он закачивает по сети прямо с нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо ещё не всё дотестировано и не удаётся добиться идеала, а у меня как раз возникло понимание причин и хотел бы это здесь обсудить.
>>
> Анонса не было, так как у меня, как помнишь, установка regular-jeos-sysv.iso дальше первого шага не идёт :-)

Забыл, но теперь вспомнил. Скрипт remount в инсталляторе давно пора 
капитально отремонтировать.


>> I. Зачем вообще нужен netstart?
>>
>> 1. Можно не записывать образы на флэшку, а ставить систему или загружать live сразу по сети.
> Но не хватает возможность вбить имя stage2 в bootchain. Да и выбора, как в propagator, между dhcp и настройки static в altboot нет.

В altboot пока нет диалогов для ручной настройки сети. Но параметрами 
запуска сетевые настройки сейчас задаются в самом make-initrd (фича 
network), причём поддерживается куда больше, чем умел propagator: IPv4, 
IPv6, и даже дюальный стек. В altboot поддержка пока только для IPv4 
сделана, но сети там совсем мало пока, так что расширить будет несложно.


>> 2. С его помощью можно тестировать сетевую загрузку силами сообщества на очень разном железе.
> Можно, но нужно, чтобы сервер отдавал быстро образы. Наверное, стоит использовать зеркало яндекса.

Да. А nightly там тоже зеркалируется? В netstart хорошо бы ещё и зеркало 
выбирать сразу.


>> 3. Потенциально можно отказаться от main repo на диске и использовать сетевой репозиторий, тогда и установочный диск станет очень небольшим, а ставиться будет лишь актуальная пакетная база. Для Сизифа это особенно интересная возможность, т.к. он меняется непрерывно.
> Это отдельная задача же. Реализуется правкой инсталятора. Но, как гарантировать, стабильность установки в условиях изменяющейся пакетной базы, вопрос актуальный.

Уточню: стабильность установки в течении недели до выпуска следующей 
партии регулярок. Никак. Но на то он и Сизиф. :-)


>> 4. Сильно упрощается жизнь желающим попробовать сразу несколько регулярок или стартеров. В перспективе это можно использовать и для продуктов.
>>
>> II. Ограничения.
>>
>> 1. Модули ядра в stage2 загружаемого дистрибутива должны соответствовать ядру и набору модулей в netstart. Хотя, я загружался и без полного соответствия.
> Главное, чтобы совпадала версия ядра.
>
>> 2. Бесполезно задавать ramdisk_size=... -- размер скачиваемого образа заранее неизвестен. Данная проблема уже решена: нужно просто не указывать этот аргумент изначально и для методов http/ftp будет закачиваться образ в /run/boot-image.iso (tmpfs).
> Отлично. Но я пока не проверял. Торопишься с анонсом :-)

Вообще я проверил, но только на rescue. Теперь надо снова проверять с 
RT-ядром и желательно сразу сетевую загрузку live.


>> 3. Параметры запуска каждого пункта загрузочного меню дистрибутива определяются в netstart, но сейчас это не мульти-загрузочный диск. Например, stagename=live бесполезно указывать в /proc/cmdline, т.к. заранее неизвестно, какой пункт какого дистрибутива будет загружаться.
> Нужна возможность задавать в altboot.
>

Выбирать на шаге netstart, который будет альтернативой шагу altboot.


>> 4. Сейчас приходится добивать руками конечную часть пути к скачиваемому ISO-образу дистрибутива, тут легко ошибиться. Да и вообще надо знать, что и откуда скачивать. Проще выбирать, а не набивать.
> Было бы здорово получать список на выбор.
>
>> III. Предложение к обсуждению.
>>
>> Для поддержки netstart можно с пачкой ISO'шников выкладывать на сервер текстовый файл, который будет описывать загружаемые дистрибутивы и предлагаемые ими пункты меню. Тогда через bootchain можно будет загружаться так: bootchain=fg,netstart. Здесь netstart -- это шаг, который скачивает описание с ftp/http-сервера и формирует необходимые диалоги. Возможно, лучше даже не выкладывать описание на сервер, а включать его в образ stage1, поскольку конкретный netstart пригоден для вполне конкретной пачки ISO'шников и только для той же архитектуры. Изменить таким способом получится н
>   е все параметры /proc/cmdline, а только те, что известны заранее, типа automatic, stagename или lowmem.
>
> Есть же MD5SUM. Может ориентироваться на него и за одно проверять контрольную сумму?

Сначала я тоже так думал: взять его за основу, отфильтровать 
неподходящие под netstart-диск архитектуры. Но информации в нём явно 
недостаточно. Есть только имена файлов и контрольные суммы MD5. Для 
ISO-образов они традиционно привычны, но предпочтительно использовать 
хотя бы SHA-256 во-избежании коллизий. На nightly считаются такие же 
бесполезные SHA-1. Нет размеров файлов, описаний дисков, списка 
доступных вариантов загрузки (пунктов меню), соответствующих им опций 
загрузки.


> А список получать при условии, что указан не образ, а каталог или же заданный образ не существует?

А как идея зашивать список в образ самого netstart? Можно реализовать 
оба варианта: если не зашит, тогда скачивать с сервера. Если указаны все 
параметры, необходимые для загрузки конкретного образа, использовать 
обычный синтаксис bootchain=fg,altboot automatic=... stagename=..., а 
список нужен, чтобы внутри make-initrd сформировать параметры для 
последующих шагов altboot и оптимизировать загрузку. Например, не все 
сервера отдают корректный размер файла, вообще его могут не все 
отдавать, к тому же это лишнее обращение к серверу.


> automatic переопределять, думаю, не нужно, как и lowmem. Достаточно только stagename, в том же шаге,
> где прописываем путь до образа.

Именно в automatic=... указывается почти всё самое важное: сервер, путь 
к образу, как же его не переопределять.


> Также зачастую на образе есть только один из вариантов stage2. Можно перебирать последовательно: altinst, live, rescue.
> Для регулярок это актуальная фича.

Типа stagename=auto?


>> IV. Вопрос.
>>
>> Существует ли мульти-загрузка ISO'шников по сети? Например, через специально собранный ipxe, чтобы не указывать в нём путь, откуда загружаться.
>>
>

-- 
Best regards,
Leonid Krivoshein.