Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Thu, Apr 26, 2018 at 11:24:04PM +0300, Leonid Krivoshein wrote:
> 
> 26.04.2018 13:21, Alexey Gladkov пишет:
> > Мне нужна помощь в написании грамотных фичей. Сейчас мне нужна фича
> > настройки сети так как в make-initrd она ооочень условная и сделана через
> > утилиту ipconfig из klibc, которая, скажем так, очень стабильная.
> 
> Уже говорил, что пока более-менее я осилил make-initrd только из p8, 
> надеюсь по фичам там нет больших отличий в v2+?

Концептуально нет. В остальном есть.

> Мне по-любому придётся 
> разбираться с сетью, так что можно будет отталкиваться от моего 
> чернового варианта, сделанного под задачи деплоя на скорую руку. Но на 
> грамотную чистовую реализацию в виде конечной фичи пока не претендую. 
> Если правильно понял, ipconfig лучше не использовать. Согласен, потому 
> что лучше ip из пакета iproute2 -- его одного хватит для всех задач.

Я не хочу реализовывать свою систему управления сетью.

> > Я разговаривал ldv, glebfm, wladmis и пришёл к выводу, что стоит
> > использовать etcnet в образе.
> 
> Тоже об этом думал. Чтобы не изобретать велосипед, для более сложных 
> случаев, конечно, можно. Но у нас ни один пакет с таким названием, а как 
> минимум четыре.

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

> > Так что, нужно написать фичу для этого, плюс
> > придумать настройку в рантайме, плюс конвертер параметра `ip=` в
> > конфигурацию etcnet.
> 
> Видел готовые реализации в Gentoo. Правда, не под etcnet, но диалоги 
> готовые. Может получится перетащить что-то из этого. См.: 
> http://www.reactivated.net/weblog/archives/2006/06/net-setup-enhancements/ 

Это диалоги для настройки сети. Если их нельзя взять "как есть", то их
придётся дорабатывать под систему конфигурации сети и как следствие
придётся взять эту подсистему из gentoo. Если её нельзя использовать
отдельно от gentoo (а скорее всего так и есть), это будет форк, а я не
хочу разрабатывать свою систему управления сетью.

> . Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP 
> возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю 
> невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot 
> поддержку Wi-Fi?

Нужно сделать так, чтобы была возможность расширения функционала. Даже
если сейчас это не нужно, то уверен, что рано или поздно появится некто,
хотящий корень по HTTPS-over-Wifi.

> Что касается параметров ip=... и nfsroot=... -- тут я 
> убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что 
> они предназначены для самого ядра и, если эти параметры указаны, ядро 
> само их парсит и начинает поднимать сеть, искать и пытаться монтировать 
> корень, итд...

Вы неправы. Это _уже_ используется и используется это очень давно.
Поддержка этих параметров есть и она должна сохраниться для обратной
совместимости.

В качестве троллического отступления хочу напомнить, что параметр root=
тоже разбирается ядром.

> В случае успеха, до запуска initrd дело вообще не должно 
> дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я 
> полагаю, и поэтому мы можем видеть очень длительную задержку во время 
> запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом 
> на выходе. По этой причине я бы не стал использовать в initrd параметры 
> загрузки с такими названиями. Меня удивило их наличие в скриптах 
> make-initrd после прочтения документации и проверки методом научного 
> тыка. Поправьте, если ошибаюсь.

Повторюсь, это очень старые параметры. Proof:

http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l82
http://git.altlinux.org/gears/m/mkinitrd.git?p=mkinitrd.git;a=blob;f=init.sh#l94

> Кроме того, я бы предложил использовать 
> ещё один механизм для передачи параметров -- через соответствующий 
> конфиг. Например, как это сделано тут: 
> http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf 
> -- просто, чтобы была возможность не только системных умолчаний, но и 
> сборочных (при сборке образа initrd), чтобы не тащить большой список 
> параметров в kernel cmdline.

Да, это правильно. Такой механизм уже используется в makе-initrd для
корня.

> > Также нужно посмотреть etcnet на предмет его работы с
> > утилитами busybox и возможность использования в нём udhcp.
> 
> Вот в этом мне видится большое противоречие. Для простых случаев 
> достаточно ручного парсинга и утилиты ip, потому что etcnet много чего 
> за собой потянет, особенно etcnet-full.

Он модульный. В идеале я хотел бы, чтобы фича etcnet была не монолитной.

> > Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
> > востребован функционал с nfs. Если востребован, то это будет ещё один
> > пласт работ.
> 
> С ним не всё хорошо и толком разобраться пока не получилось. Удалось 
> лишь добиться, чтобы хоть как-то по нему грузилось. При этом я могу 
> видеть сегфолты в ядре на стороне сервера. Вообще не уверен, что 
> nfsmount стоит использовать, хотя видел, что к ней вернулись из-за 
> проблем с mount.nfs/mount.nfs4. Но у меня в скриптах сейчас со вторыми 
> проблем меньше, propagator же умеет только nfsmount. Видимо придётся 
> делить на NFSv3 и NFSv4, и разбираться с каждым по отдельности.

Вот поэтому вопрос открыт ))

> > Также я занимаюсь анализом init-bottom перед похоронами этого скрипта.
> 
> Про преемственность я уже говорил. Стоит позаботиться о полном 
> сохранении совместимости 

О какой совместимости вы говорите ? О параметрах cmdline ? Они разумеется
останутся как были.

> Подытожу. Возможности заняться написанием конкретной фичи в нужном 
> формате в чистовом варианте в ближайший месяц-два у меня точно не будет. 

Я собственно не настаиваю. Я просто поставил всех заинтересованных в
известность о том, что нужно, чтобы "успеть к P9". А дальше решайте сами.
Мне некуда торопиться и я буду реализовывать, что задумал чтобы в
make-initrd появился функционал аналогичный propagator. Когда такой
функционал появится, тогда можно будет закопать propagator. Если у меня на
его реализацию уйдёт год, то значит через год его можно будет закопать.

> По основной работе буду заниматься схожими боданиями с начальной 
> загрузкой по сети, и эти наработки как черновой материал можно будет 
> потом подтащить в make-initrd.

При всём уважении я не приму код, который решает какую-то частную задачу.
Этот подход был использован при разработке propagator. Он весь состоит из
решений частных задач.

Кроме того, мне некуда торопиться. Есть время для нормального
проектирования.

-- 
Rgrds, legion