[make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/21/2019 03:43 PM, Alexey Gladkov wrote:

>> А есть еще какой-то "payload" для тестирования сетевой загрузки?
> 
> Не очень понял вопроса.

Какая-нибудь фича, которая бы пользовалась сетью для обретения корневой 
FS. Ну, чтобы система полностью могла загрузиться.

nfsroot не работает, CLB на новую версию не спортировано, netboot 
(который выкачивал tgz и распаковывал в tmpfs) тоже не спортирован.
А больше мне ничего на ум не приходит.


> Попробую сделать это в ближайшее время. Буду признателен, если
> заинтересованные в таком варианте протестируют перед релизом.

Разумеется.
Думаю, было бы неплохо так же рассматривать NFS как транспорт для других 
фич, по давним замерам производительности смонтировать squashfs по NFS 
может оказаться заметно быстрее, чем чистый корень:

https://lists.altlinux.org/pipermail/ltsp-server/2012-August/002532.html


>> Еще большой вопрос - как написать фичу? Есть какая-то образцовая
>> работающая фича? Или документация, с бест-практиками, примерами...
> 
> Каждая фича приносит какой-то новый функционал. У меня нет документации
> для этого. Бест-практики появляются, когда достаточное количество людей
> занимаются их написанием. В моём случае это не так.

Боюсь, тут может быть некоторый замкнутый круг.
Чтобы появилось хоть некоторое количество таких людей, у них должно быть 
понимание, как это делать. Или хотя бы с чего начать.

В старой версии M-I я попытался взять за основу упомянутый netboot и 
написать свою фичу по его мотивам. Результат, конечно, так себе, и далёк 
от любых бест-практик, но оно хотя бы заработало. И было некое 
понимание, что скрипт в post/udev/ выполнится после работы udev'а, и в 
рамках этого скрипта можно реализовать всю необходимую логику.

Сейчас, с новой версией M-I, нет ни понимания, ни документации, ни 
работающего референсного примера.
Я смутно догадываюсь, что сейчас фичу нужно оформлять какими-то 
udev-коллбеками, фильтрами и хуками, но абсолютно не представляю, с чего 
начать.

Поэтому буду рад любым советам и намёкам (варианты for dummies, in a 
nutshell вообще бесценны для снижения порога вхождения и сглаживания 
лёрнинг курвы :)


>> Я думал попробовать взять за основу nfsroot, но, похоже, он вообще не
>> "запускается". По крайней мере ни одного упоминания в /var/log нет, в
>> dmesg только о загруженном модуле nfs.
> 
> Безотносительно работает nfsmount или нет эта фича хорошо показывает как
> добавляются новые варианты загрузки.

Меня только смущает, что эта фича даже не пробует начать работать в boot 
runtime, по крайней мере, я не никакого признака не заметил - в логах 
пусто, в /.initrd/ ничего не грепается и не ищется.
И, взяв её за пример, я рискую получить еще одну неработающую фичу.


rules.mk, config.mk - тут в принципе понятно. Но я наткнулся на странный 
результат с модулем nfs. В первый раз, когда я делал образ initrd с этой 
фичей, в него попал модуль nfs, согласно
NFS_PRELOAD	= af_packet nfs
...
MODULES_PRELOAD	+= $(NFS_PRELOAD)

Однако, после нескольких попыток разобраться, почему она не работает, и 
в частности после попытки применения рецепта с вики DISABLE_GUESS = root 
(https://www.altlinux.org/Make-initrd#nfsroot), этот модуль попадать в 
образ initrd перестал, даже с явным указанием MODULES_ADD += nfs в 
/etc/initrd.mk.
Получается, сборка образа initrd не совсем воспроизводима, и от раза к 
разу может давать разные результаты? Может, есть где сказать нечто вроде 
"make clean"? Я впервые сталкиваюсь с таким поведением, и даже не знаю, 
куда посмотреть.


/etc/initrd/cmdline.d/nfsroot - тут, как я полагаю, нужно 
зарегистрировать все-все boot parameters, которыми фича собирается 
пользоваться.
Чем отличается register_parameter от register_array (и, судя по 
исходникам, есть еще register_alias), в каких случаях пользоваться той 
или иной функцией, какой синтаксис для _array - указывать несколько раз 
один и тот же параметр, или внутри одного параметра что-то перечислить 
через запятую? Разглядывание лаконичного кода этих функций в исходниках 
просветления, увы, не принесло...
Как дальше пользоваться этими параметрами? делать в каждом скрипте 
инклюд . /.initrd/initenv, и ссылаться на переменную параметра, как уже 
существующую? В cmdline писать параметр маленькими буковками, а 
переменную ожидать, что она существует с именем заглавными буквами?


/etc/udev/rules.d/99-nfsroot.rules - так, тут какое-то правило udev.
SUBSYSTEM=="net", ACTION=="online", RUN+="/lib/uevent/filters/nfsroot"
т.е. когда сеть будет в онлайне, начнёт действовать фильтр событий 
/lib/uevent/filters/nfsroot, если я правильно трактую.
Наверное, для всех сетевых фич это будет более-менее однотипно.
"Пользовательским фичам" рекомендуется использовать номер 99-?



/lib/uevent/filters/nfsroot - этот файл уже значительно менее понятен.
[ -n "$NFSROOT" ] || [ "$ROOT" != '/dev/nfs' ] ||
	NFSROOT='auto'

[ -n "$NFSROOT" ] ||
	exit 0

exit 0 нужно использовать, когда мы недовольны качеством предоставленных 
параметров, еще чем-нибудь, и не хотим оказывать услугу?

event="$(make_event)"
showenv -q > "$event"
release_event nfsroot "$event"

Эти заклинания использовать, как_есть?
Я посмотрел доступные файлы в /lib/uevent/filters, но никакой системы 
использования понять не сумел, все они достаточно разношерстные.



/lib/uevent/handlers/040-nfsroot - это уже похоже на скрипт, в котором 
делается реальная работа.
Всю логику необходимо помещать внутрь функции handler() как я понимаю.

for e in "$eventdir"/nfsroot.*; do
         [ -f "$e" ] || break
         ( . "$e"; handler; ) ||
                 rc=1
         done_event "$e"
done
Эти заклинания будут неизменны?

Во всех просмотренных хандлерах ссылка на эвенты выглядит как
"$eventdir"/nfsroot.*, "$eventdir/network.$ev_type", 
"$eventdir"/mountdev.*, etc.
Однако, внутри этой директории /.initrd/uevent-events находятся файлы вида:
done.network.addr.update.29.84.XXXNRubtr
done.network.addr.update.29.85.XXXHB5F1u
done.network.config.update.13.56.XXXPsND17
done.network.config.update.13.59.XXXJrrdH9
done.network.hostname.update.29.84.XXXwup0dr

т.е. они не подпадают под ожидаемые маски. Это нормально?



В некоторых фичах оформляется еще служба init.d, однако, в nfsroot 
например такой службы нет. В каких случаях делать, в каких не надо?

Если есть init.d/service, как можно в рантайме сделать на него ссылки в 
rcN.d (есть ли местный аналог chkconfig)?

Если в рантайме нужно делать какие-то мелкие действия, обязательно ли 
оформлять для этого init.d/сервис, или есть какой-то аналог rc.local? 
Работают ли еще старые механизмы pre/ post/ скриптов?




Замечания, появляющиеся в ходе тестирования сети, предпочтительней 
оформлять багами или для начала лучше писать сюда (для обсуждения и 
понимания, баг это или фича)?