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

[Leonid Krivoshein]

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/ 
. Стоит сразу определиться: сетевая загрузка корня с NFS/FTP/HTTP 
возможна даже по вай-фаю, но PXE-загрузка ядра и initrd по вай-фаю 
невозможна, если не ошибаюсь. Исходя из этого стоит ли тащить в liveboot 
поддержку Wi-Fi? Что касается параметров ip=... и nfsroot=... -- тут я 
убеждён в обратном. Их нельзя как-либо использовать в initrd, потому что 
они предназначены для самого ядра и, если эти параметры указаны, ядро 
само их парсит и начинает поднимать сеть, искать и пытаться монтировать 
корень, итд... В случае успеха, до запуска initrd дело вообще не должно 
дойти. Однако наше ядро собирается без DHCP- и NFS- клиентов, как я 
полагаю, и поэтому мы можем видеть очень длительную задержку во время 
запуска и загрузки ядра с любым из этих параметров и с нулевым эффектом 
на выходе. По этой причине я бы не стал использовать в initrd параметры 
загрузки с такими названиями. Меня удивило их наличие в скриптах 
make-initrd после прочтения документации и проверки методом научного 
тыка. Поправьте, если ошибаюсь. Кроме того, я бы предложил использовать 
ещё один механизм для передачи параметров -- через соответствующий 
конфиг. Например, как это сделано тут: 
http://git.altlinux.org/people/klark/packages/deploy-project.git?p=deploy-project.git;a=blob;f=stage1/etc/deploy.conf 
-- просто, чтобы была возможность не только системных умолчаний, но и 
сборочных (при сборке образа initrd), чтобы не тащить большой список 
параметров в kernel cmdline.


> Также нужно посмотреть etcnet на предмет его работы с
> утилитами busybox и возможность использования в нём udhcp.

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


> Открытым остаётся вопрос об использовании nfsmount. Я не знаю насколько
> востребован функционал с nfs. Если востребован, то это будет ещё один
> пласт работ.

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


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

Про преемственность я уже говорил. Стоит позаботиться о полном 
сохранении совместимости для простоты перехода с пропагатора на 
liveboot, вплоть до полной поддержки его kernel cmdline. Иначе переход 
на liveboot будет сильно затруднён необходимостью правки неведанного 
числа пакетов, типа alterator-netinst и задача превратится в нерешаемую.


* * *


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


-- 
Best regards,
Leonid Krivoshein.