ALT Linux Distributions development
 help / color / mirror / Atom feed
* [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
@ 2021-09-12 23:01 Leonid Krivoshein
  2021-09-13  1:27 ` Антон Мидюков
  2021-09-13  2:06 ` Vladimir D. Seleznev
  0 siblings, 2 replies; 9+ messages in thread
From: Leonid Krivoshein @ 2021-09-12 23:01 UTC (permalink / raw)
  To: Distributions development

Всем привет!


Антону Мидюкову практически удалось воплотить в m-p идею мини-образа 
ISO, позволяющего устанавливать (загружать или запускать) другие 
"большие" дистрибутивы без предварительного скачивания и записи на 
флэшку. В мини-образе netstart нет собственного stage2, есть только ядро 
и initrd, даже несколько на выбор. Основной дистрибутив он закачивает по 
сети прямо с нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо 
ещё не всё дотестировано и не удаётся добиться идеала, а у меня как раз 
возникло понимание причин и хотел бы это здесь обсудить.

I. Зачем вообще нужен netstart?

1. Можно не записывать образы на флэшку, а ставить систему или загружать 
live сразу по сети.
2. С его помощью можно тестировать сетевую загрузку силами сообщества на 
очень разном железе.
3. Потенциально можно отказаться от main repo на диске и использовать 
сетевой репозиторий, тогда и установочный диск станет очень небольшим, а 
ставиться будет лишь актуальная пакетная база. Для Сизифа это особенно 
интересная возможность, т.к. он меняется непрерывно.
4. Сильно упрощается жизнь желающим попробовать сразу несколько 
регулярок или стартеров. В перспективе это можно использовать и для 
продуктов.

II. Ограничения.

1. Модули ядра в stage2 загружаемого дистрибутива должны соответствовать 
ядру и набору модулей в netstart. Хотя, я загружался и без полного 
соответствия.
2. Бесполезно задавать ramdisk_size=... -- размер скачиваемого образа 
заранее неизвестен. Данная проблема уже решена: нужно просто не 
указывать этот аргумент изначально и для методов http/ftp будет 
закачиваться образ в /run/boot-image.iso (tmpfs).
3. Параметры запуска каждого пункта загрузочного меню дистрибутива 
определяются в netstart, но сейчас это не мульти-загрузочный диск. 
Например, stagename=live бесполезно указывать в /proc/cmdline, т.к. 
заранее неизвестно, какой пункт какого дистрибутива будет загружаться.
4. Сейчас приходится добивать руками конечную часть пути к скачиваемому 
ISO-образу дистрибутива, тут легко ошибиться. Да и вообще надо знать, 
что и откуда скачивать. Проще выбирать, а не набивать.

III. Предложение к обсуждению.

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

IV. Вопрос.

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


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-12 23:01 [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов Leonid Krivoshein
@ 2021-09-13  1:27 ` Антон Мидюков
  2021-09-13  2:25   ` Leonid Krivoshein
  2021-09-13  2:06 ` Vladimir D. Seleznev
  1 sibling, 1 reply; 9+ messages in thread
From: Антон Мидюков @ 2021-09-13  1:27 UTC (permalink / raw)
  To: devel-distro

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

Анонса не было, так как у меня, как помнишь, установка regular-jeos-sysv.iso дальше первого шага не идёт :-)

> I. Зачем вообще нужен netstart?
> 
> 1. Можно не записывать образы на флэшку, а ставить систему или загружать live сразу по сети.

Но не хватает возможность вбить имя stage2 в bootchain. Да и выбора, как в propagator, между dhcp и настройки static в altboot нет.

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

Можно, но нужно, чтобы сервер отдавал быстро образы. Наверное, стоит использовать зеркало яндекса. 

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

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

> 4. Сильно упрощается жизнь желающим попробовать сразу несколько регулярок или стартеров. В перспективе это можно использовать и для продуктов.
> 
> II. Ограничения.
> 
> 1. Модули ядра в stage2 загружаемого дистрибутива должны соответствовать ядру и набору модулей в netstart. Хотя, я загружался и без полного соответствия.

Главное, чтобы совпадала версия ядра.

> 2. Бесполезно задавать ramdisk_size=... -- размер скачиваемого образа заранее неизвестен. Данная проблема уже решена: нужно просто не указывать этот аргумент изначально и для методов http/ftp будет закачиваться образ в /run/boot-image.iso (tmpfs).

Отлично. Но я пока не проверял. Торопишься с анонсом :-)

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

Нужна возможность задавать в altboot.

> 4. Сейчас приходится добивать руками конечную часть пути к скачиваемому ISO-образу дистрибутива, тут легко ошибиться. Да и вообще надо знать, что и откуда скачивать. Проще выбирать, а не набивать.

Было бы здорово получать список на выбор.

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

Есть же MD5SUM. Может ориентироваться на него и за одно проверять контрольную сумму?
А список получать при условии, что указан не образ, а каталог или же заданный образ не существует?
automatic переопределять, думаю, не нужно, как и lowmem. Достаточно только stagename, в том же шаге,
где прописываем путь до образа.

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

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


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-12 23:01 [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов Leonid Krivoshein
  2021-09-13  1:27 ` Антон Мидюков
@ 2021-09-13  2:06 ` Vladimir D. Seleznev
  2021-09-13  2:34   ` Leonid Krivoshein
  1 sibling, 1 reply; 9+ messages in thread
From: Vladimir D. Seleznev @ 2021-09-13  2:06 UTC (permalink / raw)
  To: Distributions development

On Mon, Sep 13, 2021 at 02:01:37AM +0300, Leonid Krivoshein wrote:
> Всем привет!

Hi!

> Антону Мидюкову практически удалось воплотить в m-p идею мини-образа 
> ISO, позволяющего устанавливать (загружать или запускать) другие 
> "большие" дистрибутивы без предварительного скачивания и записи на 
> флэшку. В мини-образе netstart нет собственного stage2, есть только ядро 
> и initrd, даже несколько на выбор. Основной дистрибутив он закачивает по 
> сети прямо с нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо 
> ещё не всё дотестировано и не удаётся добиться идеала, а у меня как раз 
> возникло понимание причин и хотел бы это здесь обсудить.

Будет ли проверятся аутентичность скачиваемых образов, и если да, то
как?

-- 
   WBR,
   Vladimir D. Seleznev


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13  1:27 ` Антон Мидюков
@ 2021-09-13  2:25   ` Leonid Krivoshein
  2021-09-13  3:48     ` Антон Мидюков
  0 siblings, 1 reply; 9+ messages in thread
From: Leonid Krivoshein @ 2021-09-13  2:25 UTC (permalink / raw)
  To: devel-distro


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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13  2:06 ` Vladimir D. Seleznev
@ 2021-09-13  2:34   ` Leonid Krivoshein
  2021-09-13 14:49     ` Vladimir D. Seleznev
  0 siblings, 1 reply; 9+ messages in thread
From: Leonid Krivoshein @ 2021-09-13  2:34 UTC (permalink / raw)
  To: devel-distro


13.09.2021 5:06, Vladimir D. Seleznev пишет:
> On Mon, Sep 13, 2021 at 02:01:37AM +0300, Leonid Krivoshein wrote:
>> Всем привет!
> Hi!
>
>> Антону Мидюкову практически удалось воплотить в m-p идею мини-образа
>> ISO, позволяющего устанавливать (загружать или запускать) другие
>> "большие" дистрибутивы без предварительного скачивания и записи на
>> флэшку. В мини-образе netstart нет собственного stage2, есть только ядро
>> и initrd, даже несколько на выбор. Основной дистрибутив он закачивает по
>> сети прямо с нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо
>> ещё не всё дотестировано и не удаётся добиться идеала, а у меня как раз
>> возникло понимание причин и хотел бы это здесь обсудить.
> Будет ли проверятся аутентичность скачиваемых образов, и если да, то
> как?

Проверять контрольную сумму надо обязательно после загрузки образа. А 
вот GPG-подпись до сих пор не реализована всеми выпускающими для 
продуктов, её нет и для регулярок, и для стартеров. Равно как и гостовую 
сумму пока не все выкладывают. Хорошо бы сделать GPG, т.к. это есть у 
всех дистрибутивов. Вот что-то такое: 
http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/x86_64/ 
было бы достаточно (с открепляемой GPG-подписью)? Тогда запрашивать ещё 
и asc-файл, и, если он есть, сразу проверять GPG.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13  2:25   ` Leonid Krivoshein
@ 2021-09-13  3:48     ` Антон Мидюков
  2021-09-13 11:42       ` Leonid Krivoshein
  0 siblings, 1 reply; 9+ messages in thread
From: Антон Мидюков @ 2021-09-13  3:48 UTC (permalink / raw)
  To: devel-distro

13.09.2021 09:25, Leonid Krivoshein пишет:
> 
> 13.09.2021 4:27, Антон Мидюков пишет:
>> 13.09.2021 06:01, Leonid Krivoshein пишет:
[...]
>>> 2. С его помощью можно тестировать сетевую загрузку силами сообщества на очень разном железе.
>> Можно, но нужно, чтобы сервер отдавал быстро образы. Наверное, стоит использовать зеркало яндекса.
> 
> Да. А nightly там тоже зеркалируется? В netstart хорошо бы ещё и зеркало выбирать сразу.
> 

Пока только nightly.altlinux.org/sisyphus/ и nightly.altlinux.org/p9
Но мы это собирались исправить.

> 
>>> 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.

Нет. Надо добавить поле stagename на шаге указывания пути до сервера и образа. Зачем усложнять на ровном месте?

> 
>>> 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. Нет размеров файлов, описаний дисков, списка доступных вариантов загрузки (пунктов меню), соответствующих им опций загрузки.

Хорошо, буду выкладывать ещё и SHA256SUM.
Мне кажется, что эти плюшки уже через чур.
По крайней мере на первом этапе, это не нужно.

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

Не надо вводить новых шагов, тогда не нужен будет и список с настройками, только сам список.

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

Путь к образу и серверу то зачем? Стандартные зашиваем. Может список серверов, кстати, сделать для метода http?
Что касается методов, то у нас четыре варианта в субменю grub.

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

Типа, если не указан stagename=такой-то.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13  3:48     ` Антон Мидюков
@ 2021-09-13 11:42       ` Leonid Krivoshein
  0 siblings, 0 replies; 9+ messages in thread
From: Leonid Krivoshein @ 2021-09-13 11:42 UTC (permalink / raw)
  To: devel-distro


13.09.2021 6:48, Антон Мидюков пишет:
> 13.09.2021 09:25, Leonid Krivoshein пишет:
>> 13.09.2021 4:27, Антон Мидюков пишет:
>> [...] 
>> Выбирать на шаге netstart, который будет альтернативой шагу altboot.
> Нет. Надо добавить поле stagename на шаге указывания пути до сервера и образа. Зачем усложнять на ровном месте?
>
>>>> 4. Сейчас приходится добивать руками конечную часть пути к скачиваемому ISO-образу дистрибутива, тут легко ошибиться. Да и вообще надо знать, что и откуда скачивать. Проще выбирать, а не набивать.
>>> Было бы здорово получать список на выбор.
>>>
>>> [...]
> Не надо вводить новых шагов, тогда не нужен будет и список с настройками, только сам список.
>
>>> automatic переопределять, думаю, не нужно, как и lowmem. Достаточно только stagename, в том же шаге,
>>> где прописываем путь до образа.
>> Именно в automatic=... указывается почти всё самое важное: сервер, путь к образу, как же его не переопределять.
> Путь к образу и серверу то зачем? Стандартные зашиваем. Может список серверов, кстати, сделать для метода http?
> Что касается методов, то у нас четыре варианта в субменю grub.

Тут сплошные противоречия. Вывод списка дистрибутивов -- диалог. Вывод 
списка зеркалов HTTP/FTP -- диалог. Вывод вариантов stage2 -- диалог. 
Каждый диалог -- это шаг bootchain. Шаги altboot не умеют желаемого и 
вносить некоторые изменения в них сложнее, чем сделать отдельный шаг. У 
нас уже есть два похожих шага "altboot" и "overlayroot", можно добавить 
"netstart", у которого будет такой же принцип действия.

Шаг "download" либо получает готовые параметры, либо выводит диалоги, 
чтобы их получить. Он не сможет склеить начальную часть пути с отдельно 
где-то выбранным названием дистрибутива. Шаг "netstart" сможет после 
выбора дистрибутива сформировать для шага "atboot" правильный параметр 
automatic=server:путь.

Не согласен, что параметры загрузки не нужны, а нужен только stagename. 
Как раз параметры могут быть весьма специфичны для каждого пункта меню, 
но боюсь, что эту проблему так просто не решить. Потому что утилиты, 
разбирающие эти параметры, ожидают увидеть их в /proc/cmdline. Т.е. в 
идеале весь выбор должен осуществляться средствами меню загрузчика, 
тогда решать её лучше в m-p. Есть идея, как разобрать пачку лежащих в 
каталоге ISO'шек и сгенерировать на их основе список, но лучше, чтобы 
его обрабатывал m-p.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13  2:34   ` Leonid Krivoshein
@ 2021-09-13 14:49     ` Vladimir D. Seleznev
  2021-09-13 14:52       ` Denis Medvedev
  0 siblings, 1 reply; 9+ messages in thread
From: Vladimir D. Seleznev @ 2021-09-13 14:49 UTC (permalink / raw)
  To: Distributions development

On Mon, Sep 13, 2021 at 05:34:25AM +0300, Leonid Krivoshein wrote:
> 
> 13.09.2021 5:06, Vladimir D. Seleznev пишет:
> > On Mon, Sep 13, 2021 at 02:01:37AM +0300, Leonid Krivoshein wrote:
> >> Всем привет!
> > Hi!
> >
> >> Антону Мидюкову практически удалось воплотить в m-p идею мини-образа
> >> ISO, позволяющего устанавливать (загружать или запускать) другие
> >> "большие" дистрибутивы без предварительного скачивания и записи на
> >> флэшку. В мини-образе netstart нет собственного stage2, есть только ядро
> >> и initrd, даже несколько на выбор. Основной дистрибутив он закачивает по
> >> сети прямо с нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо
> >> ещё не всё дотестировано и не удаётся добиться идеала, а у меня как раз
> >> возникло понимание причин и хотел бы это здесь обсудить.
> > Будет ли проверятся аутентичность скачиваемых образов, и если да, то
> > как?
> 
> Проверять контрольную сумму надо обязательно после загрузки образа. А 
> вот GPG-подпись до сих пор не реализована всеми выпускающими для 
> продуктов, её нет и для регулярок, и для стартеров. Равно как и гостовую 
> сумму пока не все выкладывают. Хорошо бы сделать GPG, т.к. это есть у 
> всех дистрибутивов. Вот что-то такое: 
> http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/x86_64/ 
> было бы достаточно (с открепляемой GPG-подписью)? Тогда запрашивать ещё 
> и asc-файл, и, если он есть, сразу проверять GPG.

Думаю, да, проверять GPG-подпись было бы достаточно. А вот использовать
DSA уже не стоило бы :)

-- 
   WBR,
   Vladimir D. Seleznev


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов
  2021-09-13 14:49     ` Vladimir D. Seleznev
@ 2021-09-13 14:52       ` Denis Medvedev
  0 siblings, 0 replies; 9+ messages in thread
From: Denis Medvedev @ 2021-09-13 14:52 UTC (permalink / raw)
  To: Vladimir D. Seleznev; +Cc: Distributions development

В Mon, 13 Sep 2021 14:49:04 +0000
"Vladimir D. Seleznev" <vseleznv@altlinux.org> пишет:

> On Mon, Sep 13, 2021 at 05:34:25AM +0300, Leonid Krivoshein wrote:
> > 
> > 13.09.2021 5:06, Vladimir D. Seleznev пишет:  
> > > On Mon, Sep 13, 2021 at 02:01:37AM +0300, Leonid Krivoshein
> > > wrote:  
> > >> Всем привет!  
> > > Hi!
> > >  
> > >> Антону Мидюкову практически удалось воплотить в m-p идею
> > >> мини-образа ISO, позволяющего устанавливать (загружать или
> > >> запускать) другие "большие" дистрибутивы без предварительного
> > >> скачивания и записи на флэшку. В мини-образе netstart нет
> > >> собственного stage2, есть только ядро и initrd, даже несколько
> > >> на выбор. Основной дистрибутив он закачивает по сети прямо с
> > >> нашего http/ftp-сервера. Анонса ещё не было, т.к. видимо ещё не
> > >> всё дотестировано и не удаётся добиться идеала, а у меня как раз
> > >> возникло понимание причин и хотел бы это здесь обсудить.  
> > > Будет ли проверятся аутентичность скачиваемых образов, и если да,
> > > то как?  
> > 
> > Проверять контрольную сумму надо обязательно после загрузки образа.
> > А вот GPG-подпись до сих пор не реализована всеми выпускающими для 
> > продуктов, её нет и для регулярок, и для стартеров. Равно как и
> > гостовую сумму пока не все выкладывают. Хорошо бы сделать GPG, т.к.
> > это есть у всех дистрибутивов. Вот что-то такое: 
> > http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/images/education/x86_64/ 
> > было бы достаточно (с открепляемой GPG-подписью)? Тогда запрашивать
> > ещё и asc-файл, и, если он есть, сразу проверять GPG.  
> 
> Думаю, да, проверять GPG-подпись было бы достаточно. А вот
> использовать DSA уже не стоило бы :)
> 

Есть такой пакет alt-checksums, который снимает контрольные суммы со
всех исполяемых файлов установленного в заданной
конфигурации дистрибутива и формирует файл с ними. Может быть полезно
в некоторых случаях.
Его можно запускать в инсталляторе.
Можно поставлять такой список вместе с системой отдельно от нее.


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-09-13 14:52 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-12 23:01 [devel-distro] netstart: ядро+initrd для сетевой загрузки других дистрибутивов Leonid Krivoshein
2021-09-13  1:27 ` Антон Мидюков
2021-09-13  2:25   ` Leonid Krivoshein
2021-09-13  3:48     ` Антон Мидюков
2021-09-13 11:42       ` Leonid Krivoshein
2021-09-13  2:06 ` Vladimir D. Seleznev
2021-09-13  2:34   ` Leonid Krivoshein
2021-09-13 14:49     ` Vladimir D. Seleznev
2021-09-13 14:52       ` Denis Medvedev

ALT Linux Distributions development

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \
		devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com
	public-inbox-index devel-distro

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-distro


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git