Re: [make-initrd] [devel] syslinux

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Доброго времени!


21.01.2019 18:37, Michael A. Kangin пишет:
> On 01/16/2019 08:29 PM, Leonid Krivoshein wrote:
>
>> Можем объединить наши усилия,
>
> Ну, по возможности. Есть какие-то конкретные задачи?
>

Наконец, появилась вполне конкретная задача! Алексей Гладков добавил 
полноценную поддержку сети в make-initrd и планирует в ближайшее время 
добавить поддержку загрузки методом "cdrom". С загрузкой по NFS это 
закроет 99% случаев использования заменяемого им пропагатора. Он собрал 
task #226775 и просит подключиться к тестированию новых сетевых 
возможностей make-initrd: 
https://github.com/legionus/make-initrd/blob/master/docs/BootParameters.md#network-parameters

Я планирую потестировать сначала ipv4 на виртуальных стендах. Если всё 
пойдёт хорошо, попробую собрать что-нибудь деплойное и потестить на 
реальном железе. Если кто-то сможет помочь с ipv6 и вообще с сетью, было 
бы здорово! Технология тестирования мне самому пока не ясна до конца, 
legion@ говорит, что загрузка по NFS уже должна работать.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

Есть ли готовые образы для тестирования?
сам initrd, рескью какой может быть.

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

colaboot проверить не смогу, он с этой версией M-I несовместим.
Есть ли документация, как правильно фичи писать?



On 04/16/2019 01:27 AM, Leonid Krivoshein wrote:
> Доброго времени!
> 
> 
> 21.01.2019 18:37, Michael A. Kangin пишет:
>> On 01/16/2019 08:29 PM, Leonid Krivoshein wrote:
>>
>>> Можем объединить наши усилия,
>>
>> Ну, по возможности. Есть какие-то конкретные задачи?
>>
> 
> Наконец, появилась вполне конкретная задача! Алексей Гладков добавил 
> полноценную поддержку сети в make-initrd и планирует в ближайшее время 
> добавить поддержку загрузки методом "cdrom". С загрузкой по NFS это 
> закроет 99% случаев использования заменяемого им пропагатора. Он собрал 
> task #226775 и просит подключиться к тестированию новых сетевых 
> возможностей make-initrd: 
> https://github.com/legionus/make-initrd/blob/master/docs/BootParameters.md#network-parameters 
> 
> 
> Я планирую потестировать сначала ipv4 на виртуальных стендах. Если всё 
> пойдёт хорошо, попробую собрать что-нибудь деплойное и потестить на 
> реальном железе. Если кто-то сможет помочь с ipv6 и вообще с сетью, было 
> бы здорово! Технология тестирования мне самому пока не ясна до конца, 
> legion@ говорит, что загрузка по NFS уже должна работать.
> 
> 

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Привет!

Вот и я долго мучился: у нас же нет нет образов live/rescue/install без 
пропагатора, который, попадая в initramfs, закрывает собой всю логику 
make-initrd. Поэтому решил накостылить такое решение для тестирования на 
реальном железе:

cd $TMPDIR
mkdir nfs data

cat >initrd.mk <<-EOF
AUTODETECT =
FEATURES += nfsroot
PUT_DIRS += $TMPDIR/data/
EOF

cp -ar /lib/modules data/
cp -ar /lib/firmware data/
find data/firmware -type f -iname '*.txt' -delete

make-initrd -c $TMPDIR/initrd.mk -b $TMPDIR/nfs

Получается всеядный initrd.img, 250М в сильно сжатом виде. Всё это я 
проделываю на Сизифной виртуалке, обновив make-initrd из таска. В 
результате можно брать ядро из /boot и initrd.img из $TMPDIR/nfs и 
выкладывать сие на NFS-сервер, писать на флэшку, итд. И уже начинать 
играться с параметрами загрузки. Пока дальше я этот квест не проходил.


17.04.2019 17:27, Michael A. Kangin пишет:
> Есть ли готовые образы для тестирования?
> сам initrd, рескью какой может быть.
>
> Я попробую что-то собрать, но с сизифом и с непривычки это займёт не 
> один день, только для организации стенда.
>
> colaboot проверить не смогу, он с этой версией M-I несовместим.
> Есть ли документация, как правильно фичи писать?
>
>
>
> On 04/16/2019 01:27 AM, Leonid Krivoshein wrote:
>> Доброго времени!
>>
>>
>> 21.01.2019 18:37, Michael A. Kangin пишет:
>>> On 01/16/2019 08:29 PM, Leonid Krivoshein wrote:
>>>
>>>> Можем объединить наши усилия,
>>>
>>> Ну, по возможности. Есть какие-то конкретные задачи?
>>>
>>
>> Наконец, появилась вполне конкретная задача! Алексей Гладков добавил 
>> полноценную поддержку сети в make-initrd и планирует в ближайшее 
>> время добавить поддержку загрузки методом "cdrom". С загрузкой по NFS 
>> это закроет 99% случаев использования заменяемого им пропагатора. Он 
>> собрал task #226775 и просит подключиться к тестированию новых 
>> сетевых возможностей make-initrd: 
>> https://github.com/legionus/make-initrd/blob/master/docs/BootParameters.md#network-parameters 
>>
>>
>> Я планирую потестировать сначала ipv4 на виртуальных стендах. Если 
>> всё пойдёт хорошо, попробую собрать что-нибудь деплойное и потестить 
>> на реальном железе. Если кто-то сможет помочь с ipv6 и вообще с 
>> сетью, было бы здорово! Технология тестирования мне самому пока не 
>> ясна до конца, legion@ говорит, что загрузка по NFS уже должна работать.
>>
>>
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

Так, я собрал себе M-I 2.3.0-alt1, там вроде сеть уже заявлена была.
Скачал сизифный найтбилд с xfce, поставил этот MI, собрал initrd:

AUTODETECT = all
MODULES_PRELOAD += autofs4
FEATURES += nfsroot
DISABLE_GUESS += ucode

Содержимое корня с установленной на диск системы расшарил по NFS:
/home/sisyphus 
192.168.222.0/24(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
reboo

Получившийся initrd пытаюсь загрузить с такими опциями:
:alt
set boot-path http://192.168.222.1/alt
kernel ${boot-path}/vmlinuz ip=dhcp4 nfsroot=192.168.222.1:/home/sisyphus
initrd ${boot-path}/initrd.img
boot



Инитрд сеть инициапизирует, однако фича nfsroot так никогда кажется и не 
начинает работать - процесс загрузки висит до таймаута с "starting udevd 
service", потом вываливается в шелл (rdshell: the waiting time expired)
grep -i nfs /var/log/* ничего не показывает.
По сети ни одного пакета, после получения адреса, не прилетает.

Из забавного - сеть с такой конфигурацией инициализируется довольно 
долго. Причина из ueventd.log:
lo: waiting 16 seconds for configuration by dhcp ...
...
lo: dhcp done

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


Буду благодарен за рецепты - методы отладки initrd, какие логи смотреть, 
как их добывать, и так далее.
Так же, если nfs должно работать, очевидно я как-то не так его вызываю. 
Есть образец удачной конфигурации?


On 04/17/2019 05:16 PM, Leonid Krivoshein wrote:
> Привет!
> 
> Вот и я долго мучился: у нас же нет нет образов live/rescue/install без 
> пропагатора, который, попадая в initramfs, закрывает собой всю логику 
> make-initrd. Поэтому решил накостылить такое решение для тестирования на 
> реальном железе:
> 
> cd $TMPDIR
> mkdir nfs data
> 
> cat >initrd.mk <<-EOF
> AUTODETECT =
> FEATURES += nfsroot
> PUT_DIRS += $TMPDIR/data/
> EOF
> 
> cp -ar /lib/modules data/
> cp -ar /lib/firmware data/
> find data/firmware -type f -iname '*.txt' -delete
> 
> make-initrd -c $TMPDIR/initrd.mk -b $TMPDIR/nfs
> 
> Получается всеядный initrd.img, 250М в сильно сжатом виде. Всё это я 
> проделываю на Сизифной виртуалке, обновив make-initrd из таска. В 
> результате можно брать ядро из /boot и initrd.img из $TMPDIR/nfs и 
> выкладывать сие на NFS-сервер, писать на флэшку, итд. И уже начинать 
> играться с параметрами загрузки. Пока дальше я этот квест не проходил.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Не, до NFS ещё видимо никто не доходил! :) А тестировать можно с опциями 
debug, rdshell или STOP=,шаг, -- про это есть в документации и на ВиКи. 
Может, не попадает нужных модулей в такой initrd?


19.04.2019 02:00, Michael A. Kangin пишет:
> Так, я собрал себе M-I 2.3.0-alt1, там вроде сеть уже заявлена была.
> Скачал сизифный найтбилд с xfce, поставил этот MI, собрал initrd:
>
> AUTODETECT = all
> MODULES_PRELOAD += autofs4
> FEATURES += nfsroot
> DISABLE_GUESS += ucode
>
> Содержимое корня с установленной на диск системы расшарил по NFS:
> /home/sisyphus 
> 192.168.222.0/24(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
> reboo
>
> Получившийся initrd пытаюсь загрузить с такими опциями:
> :alt
> set boot-path http://192.168.222.1/alt
> kernel ${boot-path}/vmlinuz ip=dhcp4 nfsroot=192.168.222.1:/home/sisyphus
> initrd ${boot-path}/initrd.img
> boot
>
>
>
> Инитрд сеть инициапизирует, однако фича nfsroot так никогда кажется и 
> не начинает работать - процесс загрузки висит до таймаута с "starting 
> udevd service", потом вываливается в шелл (rdshell: the waiting time 
> expired)
> grep -i nfs /var/log/* ничего не показывает.
> По сети ни одного пакета, после получения адреса, не прилетает.
>
> Из забавного - сеть с такой конфигурацией инициализируется довольно 
> долго. Причина из ueventd.log:
> lo: waiting 16 seconds for configuration by dhcp ...
> ...
> lo: dhcp done
>
> Это результаты первого взгляда, потом потестирую поподробнее, может, с 
> учётом замечаний.
>
>
> Буду благодарен за рецепты - методы отладки initrd, какие логи 
> смотреть, как их добывать, и так далее.
> Так же, если nfs должно работать, очевидно я как-то не так его 
> вызываю. Есть образец удачной конфигурации?
>
>
> On 04/17/2019 05:16 PM, Leonid Krivoshein wrote:
>> Привет!
>>
>> Вот и я долго мучился: у нас же нет нет образов live/rescue/install 
>> без пропагатора, который, попадая в initramfs, закрывает собой всю 
>> логику make-initrd. Поэтому решил накостылить такое решение для 
>> тестирования на реальном железе:
>>
>> cd $TMPDIR
>> mkdir nfs data
>>
>> cat >initrd.mk <<-EOF
>> AUTODETECT =
>> FEATURES += nfsroot
>> PUT_DIRS += $TMPDIR/data/
>> EOF
>>
>> cp -ar /lib/modules data/
>> cp -ar /lib/firmware data/
>> find data/firmware -type f -iname '*.txt' -delete
>>
>> make-initrd -c $TMPDIR/initrd.mk -b $TMPDIR/nfs
>>
>> Получается всеядный initrd.img, 250М в сильно сжатом виде. Всё это я 
>> проделываю на Сизифной виртуалке, обновив make-initrd из таска. В 
>> результате можно брать ядро из /boot и initrd.img из $TMPDIR/nfs и 
>> выкладывать сие на NFS-сервер, писать на флэшку, итд. И уже начинать 
>> играться с параметрами загрузки. Пока дальше я этот квест не проходил.
>
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/19/2019 06:01 AM, Leonid Krivoshein wrote:

> Не, до NFS ещё видимо никто не доходил! :) А тестировать можно с опциями 
> debug, rdshell или STOP=,шаг, -- про это есть в документации и на ВиКи. 

Не так давно rdshell была полностью сломана, теперь вроде починилась.. 
Ладно, уже хлеб

А вот это вот - "- `stop=<comma-separated list>` specifies the list of 
stages to where it's necessary to open emergency console." - есть список 
актуальных stages? мне показалось что в новой версии он значительно 
изменился

> Может, не попадает нужных модулей в такой initrd?

Как минимум для сетевой карты попадает (виртуалка в kvm)

Для nfs не знаю, что ему надо - модули nfs/lockd/sunrpc там есть.
Однако, этот nfsmount, который то ли из klibc, то ли kinit utils, будучи 
вручную запущенным, так же не работает с глубокомысленной диагностикой
~:# nfsmount 192.168.222.1:/home/sisyphus /root/
connect: Connection refused
read: Connection refused
read: Connection refused

Не знаю, правильно ли его так вызывать - документации не нашёл.
Впрочем, на моей памяти он кажется никогда не работал.


Если внутрь initrd положить человеческий mount.nfs с доп.модулями типа 
nfsv4, то ручками корень монтируется без проблем.
~:# mount.nfs 192.168.222.1:/home/sisyphus /root/
~:# ls /root/
bin         etc         lib64       media       proc        sbin 
sys         var
boot        home        libx32      mnt         root        selinux     tmp
dev         lib         lost+found  opt         run         srv         usr


Однако, дальше ничего не происходит - если покинуть теперь шелл, то 
инитрд продолжает висеть вечно и чего-то ждать, даже по таймауту не 
отваливается.

Резюмируя:
- сеть кое_как работает,  её на данном этапе можно потестировать только 
вручную, можно проверить все заявленные режимы-параметры.
- nfsroot не работает ваааще.
- пытаться смигрировать CLB, основываясь на чтении исходников 
неработающей фичи, неразумно и преждевременно.
- пожалуй, сейчас стоит пообщать Алексея, чтобы не играть в догадки и не 
тратить время впустую.

Я выложил дополнительные образы http://mak.complife.ru/MI2/
как минимум удобно пользовать debug.cpio, с ним можно пользоваться башем 
и запустить (пока ручками) dropbear (/etc/init.d/dropbear start). Вшитый 
ключик приаттачил.
Если будете грузить доп. образы с модулями, не забудьте первым делом 
сказать depmod -a, автоматику пока не развёл.

Образец меню для iPXE:
:alt
set boot-path http://192.168.222.1/alt
kernel ${boot-path}/vmlinuz ip=dhcp4 root=/dev/nfs 
nfsroot=192.168.222.1:/home/sisyphus debug rdshell
initrd ${boot-path}/initrd.img
initrd ${boot-path}/debug.cpio
initrd ${boot-path}/nfs.cpio
# initrd ${boot-path}/common_boot.modules.5.0.6-un-def-alt1.cpio
initrd ${boot-path}/nfs.modules.5.0.6-un-def-alt1.cpio
boot


common_boot.modules не обязателен, но там расширенный набор модулей для 
разных сетевух и флешек/hdd/iso, может быть полезен.



> Вот не думаю, что Dracut будет лучше для Альта, тем более, M-I вполне интересное решение. В любом случае я просил legion@ смотреть и на Dracut, и live-boot из Debian, хотя все они примерно ровесники. 

Есть еще и RHEL.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Всем привет!


Раз так, то давайте подключим Алексея.

Мне тоже казалось, что nfsmount никогда толком не работал. А через 
mount.nfs монтировать удавалось. Просто немного приболел, поэтому до 
подготовленного железного стенда на работе пока не доехал. И сначала на 
виртуалках хочу собрать деплойный вариант подключения NFS-раздела. 
Может, смогу в эти выходные.

Как я понял, dhcpv4 пытается авто-конфигурировать lo интерфейс и 
отваливается по таймауту.

Скрипт /data/etc/rc.d/rc начиная с комментария "Now run the START 
scripts" определяет логику интерактивного запуска служб из 
/etc/rc.d/rc$LEVEL.d/S?? -- перед всеми (all) или перед указанными 
выполняется запрос на подтверждение.


19.04.2019 19:33, Michael A. Kangin пишет:
> On 04/19/2019 06:01 AM, Leonid Krivoshein wrote:
>
>> Не, до NFS ещё видимо никто не доходил! :) А тестировать можно с 
>> опциями debug, rdshell или STOP=,шаг, -- про это есть в документации 
>> и на ВиКи. 
>
> Не так давно rdshell была полностью сломана, теперь вроде починилась.. 
> Ладно, уже хлеб
>
> А вот это вот - "- `stop=<comma-separated list>` specifies the list of 
> stages to where it's necessary to open emergency console." - есть 
> список актуальных stages? мне показалось что в новой версии он 
> значительно изменился
>
>> Может, не попадает нужных модулей в такой initrd?
>
> Как минимум для сетевой карты попадает (виртуалка в kvm)
>
> Для nfs не знаю, что ему надо - модули nfs/lockd/sunrpc там есть.
> Однако, этот nfsmount, который то ли из klibc, то ли kinit utils, 
> будучи вручную запущенным, так же не работает с глубокомысленной 
> диагностикой
> ~:# nfsmount 192.168.222.1:/home/sisyphus /root/
> connect: Connection refused
> read: Connection refused
> read: Connection refused
>
> Не знаю, правильно ли его так вызывать - документации не нашёл.
> Впрочем, на моей памяти он кажется никогда не работал.
>
>
> Если внутрь initrd положить человеческий mount.nfs с доп.модулями типа 
> nfsv4, то ручками корень монтируется без проблем.
> ~:# mount.nfs 192.168.222.1:/home/sisyphus /root/
> ~:# ls /root/
> bin         etc         lib64       media       proc        sbin 
> sys         var
> boot        home        libx32      mnt         root selinux     tmp
> dev         lib         lost+found  opt         run srv         usr
>
>
> Однако, дальше ничего не происходит - если покинуть теперь шелл, то 
> инитрд продолжает висеть вечно и чего-то ждать, даже по таймауту не 
> отваливается.
>
> Резюмируя:
> - сеть кое_как работает,  её на данном этапе можно потестировать 
> только вручную, можно проверить все заявленные режимы-параметры.
> - nfsroot не работает ваааще.
> - пытаться смигрировать CLB, основываясь на чтении исходников 
> неработающей фичи, неразумно и преждевременно.
> - пожалуй, сейчас стоит пообщать Алексея, чтобы не играть в догадки и 
> не тратить время впустую.
>
> Я выложил дополнительные образы http://mak.complife.ru/MI2/
> как минимум удобно пользовать debug.cpio, с ним можно пользоваться 
> башем и запустить (пока ручками) dropbear (/etc/init.d/dropbear 
> start). Вшитый ключик приаттачил.
> Если будете грузить доп. образы с модулями, не забудьте первым делом 
> сказать depmod -a, автоматику пока не развёл.
>
> Образец меню для iPXE:
> :alt
> set boot-path http://192.168.222.1/alt
> kernel ${boot-path}/vmlinuz ip=dhcp4 root=/dev/nfs 
> nfsroot=192.168.222.1:/home/sisyphus debug rdshell
> initrd ${boot-path}/initrd.img
> initrd ${boot-path}/debug.cpio
> initrd ${boot-path}/nfs.cpio
> # initrd ${boot-path}/common_boot.modules.5.0.6-un-def-alt1.cpio
> initrd ${boot-path}/nfs.modules.5.0.6-un-def-alt1.cpio
> boot
>
>
> common_boot.modules не обязателен, но там расширенный набор модулей 
> для разных сетевух и флешек/hdd/iso, может быть полезен.
>
>
>
>> Вот не думаю, что Dracut будет лучше для Альта, тем более, M-I вполне 
>> интересное решение. В любом случае я просил legion@ смотреть и на 
>> Dracut, и live-boot из Debian, хотя все они примерно ровесники. 
>
> Есть еще и RHEL.
>
>
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

On 04/19/2019 08:14 PM, Leonid Krivoshein wrote:

>> start). Вшитый ключик приаттачил.

Упс, не приаттачил

[-- Attachment #2: id_rsa_initrd --]
[-- Type: text/plain, Size: 1823 bytes --]

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAoDv9b/gKAI4490qd5IbOomrmtO1eKHqzn6w3ugiDtZ4GDn2fwdbc
5FKMHEEQ4xBUwNqBIyek9uI7rEepBUaNjMtxxNMu9/dEBcE19xgUVa0qvI0sxvPkHEP2ed
inB2gVsvjXmqCclU1HO/IDvs2asM7he8a0Iw1v9PG78LD5dt6ZkMFEqninl1JbRK0j4o+A
CKqxkQ1KkSnBQ8vszpSgbmQV5SfV1mwReLUjX1W4wP9/R8vwNYi0wx11G+YphwRnFu4YO4
upcLnWMWmvZL2i28g88e5YLxQkZXVemd1t+Ta6y26bCBiAJhF+aGen1MZ30oFtUswX86CG
Tswf4QgAVwAAA8jjZKo842SqPAAAAAdzc2gtcnNhAAABAQCgO/1v+AoAjjj3Sp3khs6iau
a07V4oerOfrDe6CIO1ngYOfZ/B1tzkUowcQRDjEFTA2oEjJ6T24jusR6kFRo2My3HE0y73
90QFwTX3GBRVrSq8jSzG8+QcQ/Z52KcHaBWy+NeaoJyVTUc78gO+zZqwzuF7xrQjDW/08b
vwsPl23pmQwUSqeKeXUltErSPij4AIqrGRDUqRKcFDy+zOlKBuZBXlJ9XWbBF4tSNfVbjA
/39Hy/A1iLTDHXUb5imHBGcW7hg7i6lwudYxaa9kvaLbyDzx7lgvFCRldV6Z3W35NrrLbp
sIGIAmEX5oZ6fUxnfSgW1SzBfzoIZOzB/hCABXAAAAAwEAAQAAAQAJhodyeJRfpBTO3qi0
RS9TiHdemh3W2jSDcYF+lbL+wP4rLlyo8VUAXcfmhhey5+2h6Vtz849i/d/+ReROY/tWO2
HwCX3pT9HDZdEHd27+COVZgCsBSM5uv7uPUsnbLtzbXt+yWYn1djqd3a1LUn23tRTCfvWG
f+3/6b76eArcfhcY8fb9xd1ruaoIEDFrF9RNzHhz3i9Ne0wRFBpLP62QFaWJF2Y0K6AUwU
TFiPFxLQ8faN0uHwSevKSWBPLqvbXVKlWOGmzPJWuNRbvvJmzYFB4Eps/MKLQVVojBtv1n
0XWucAiYI47l/kJjpUXg0lcUAiLulv829de27Iy3HSUBAAAAgGZXnVmugKp5MxWhU8FzIY
+OZ5f/gp/PRWn0s7tbBadnRdmrDn2mcu/vxIfZoWbidWxuhBkC939+G6TCzSnXXtKEtQw1
lV7yRrENt7qn/QXdtpqqMIChE/Qnm+TTaJyDKlK0t/MLFPsCc8O4lku5Vm5WgY8hoMWlWA
beMFxocmJRAAAAgQDTM2ArOy4qzy6TR3suKYunhkTjB7GWZ0tWchMDD+yjAOUNnuKTmi5z
Q49cVYyOmWuycHwmcMSxhF+L17HcoNduv7+GohfZ3eaz5EdL9h/ZE1Hp6++ymC8JkQJgg/
hyXeGEKpcKZm81f87/ZSHPTxi/5aLCkivO7DUq8iYadwtn5wAAAIEAwjkJ175Y/wr1q31P
01aiHHnvpYMjxlIso9RW6ta1FAwJcHCGfOAg893MUFDmq1RbiLyA5jipjJd/I3DJALKeef
3Ot/HEC+wKrW0dk/+Lpy/0nApoig89ZqeYcKomOTAr2ZeHuiXbSxK75nGvZ6D/uqmBKvex
xsw2Wf9TQJLd1hEAAAAMaW5pdHJkLWRlYnVnAQIDBAUGBw==
-----END OPENSSH PRIVATE KEY-----

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Fri, Apr 19, 2019 at 09:14:48PM +0300, Leonid Krivoshein wrote:
> Всем привет!
> 
> 
> Раз так, то давайте подключим Алексея.
> 
> Мне тоже казалось, что nfsmount никогда толком не работал.

Я никогда не использовал nfsroot. Изначально он появился путём переноса
один в один функционала mkinitrd. Когда-то мне писали, что он работает в
том же объёме, что и в mkinitrd.

Я в последнее время двигаюсь в сторону отказа от утилит из klibc. Они не
развиваются с той скоростью с которой бы мне хотелось.

В новом релизе я постарался отказаться от ipconfig и некоторых других
утилит.

> А через mount.nfs монтировать удавалось. Просто немного приболел,
> поэтому до подготовленного железного стенда на работе пока не доехал. И
> сначала на виртуалках хочу собрать деплойный вариант подключения
> NFS-раздела.  Может, смогу в эти выходные.

Можно попробовать переписать nfsroot с nfsmount на что-то другое.

> Как я понял, dhcpv4 пытается авто-конфигурировать lo интерфейс и 
> отваливается по таймауту.
> 
> Скрипт /data/etc/rc.d/rc начиная с комментария "Now run the START 
> scripts" определяет логику интерактивного запуска служб из 
> /etc/rc.d/rc$LEVEL.d/S?? -- перед всеми (all) или перед указанными 
> выполняется запрос на подтверждение.
> 
> 
> 19.04.2019 19:33, Michael A. Kangin пишет:
> > On 04/19/2019 06:01 AM, Leonid Krivoshein wrote:
> >
> >> Не, до NFS ещё видимо никто не доходил! :) А тестировать можно с 
> >> опциями debug, rdshell или STOP=,шаг, -- про это есть в документации 
> >> и на ВиКи. 
> >
> > Не так давно rdshell была полностью сломана, теперь вроде починилась.. 
> > Ладно, уже хлеб

Мне не известны случаи, когда STOP не работал в принципе. Я знаю, что не
он, а чтение с терминала может не работать из-за plymouth.

> > А вот это вот - "- `stop=<comma-separated list>` specifies the list of 
> > stages to where it's necessary to open emergency console." - есть 
> > список актуальных stages? мне показалось что в новой версии он 
> > значительно изменился
> >
> >> Может, не попадает нужных модулей в такой initrd?
> >
> > Как минимум для сетевой карты попадает (виртуалка в kvm)
> >
> > Для nfs не знаю, что ему надо - модули nfs/lockd/sunrpc там есть.
> > Однако, этот nfsmount, который то ли из klibc, то ли kinit utils, 
> > будучи вручную запущенным, так же не работает с глубокомысленной 
> > диагностикой
> > ~:# nfsmount 192.168.222.1:/home/sisyphus /root/
> > connect: Connection refused
> > read: Connection refused
> > read: Connection refused
> >
> > Не знаю, правильно ли его так вызывать - документации не нашёл.
> > Впрочем, на моей памяти он кажется никогда не работал.
> >
> >
> > Если внутрь initrd положить человеческий mount.nfs с доп.модулями типа 
> > nfsv4, то ручками корень монтируется без проблем.
> > ~:# mount.nfs 192.168.222.1:/home/sisyphus /root/
> > ~:# ls /root/
> > bin         etc         lib64       media       proc        sbin 
> > sys         var
> > boot        home        libx32      mnt         root selinux     tmp
> > dev         lib         lost+found  opt         run srv         usr
> >
> >
> > Однако, дальше ничего не происходит - если покинуть теперь шелл, то 
> > инитрд продолжает висеть вечно и чего-то ждать, даже по таймауту не 
> > отваливается.
> >
> > Резюмируя:
> > - сеть кое_как работает,  её на данном этапе можно потестировать 
> > только вручную, можно проверить все заявленные режимы-параметры.
> > - nfsroot не работает ваааще.
> > - пытаться смигрировать CLB, основываясь на чтении исходников 
> > неработающей фичи, неразумно и преждевременно.
> > - пожалуй, сейчас стоит пообщать Алексея, чтобы не играть в догадки и 
> > не тратить время впустую.
> >
> > Я выложил дополнительные образы http://mak.complife.ru/MI2/
> > как минимум удобно пользовать debug.cpio, с ним можно пользоваться 
> > башем и запустить (пока ручками) dropbear (/etc/init.d/dropbear 
> > start). Вшитый ключик приаттачил.
> > Если будете грузить доп. образы с модулями, не забудьте первым делом 
> > сказать depmod -a, автоматику пока не развёл.
> >
> > Образец меню для iPXE:
> > :alt
> > set boot-path http://192.168.222.1/alt
> > kernel ${boot-path}/vmlinuz ip=dhcp4 root=/dev/nfs 
> > nfsroot=192.168.222.1:/home/sisyphus debug rdshell
> > initrd ${boot-path}/initrd.img
> > initrd ${boot-path}/debug.cpio
> > initrd ${boot-path}/nfs.cpio
> > # initrd ${boot-path}/common_boot.modules.5.0.6-un-def-alt1.cpio
> > initrd ${boot-path}/nfs.modules.5.0.6-un-def-alt1.cpio
> > boot
> >
> >
> > common_boot.modules не обязателен, но там расширенный набор модулей 
> > для разных сетевух и флешек/hdd/iso, может быть полезен.
> >
> >
> >
> >> Вот не думаю, что Dracut будет лучше для Альта, тем более, M-I вполне 
> >> интересное решение. В любом случае я просил legion@ смотреть и на 
> >> Dracut, и live-boot из Debian, хотя все они примерно ровесники. 
> >
> > Есть еще и RHEL.
> >
> >
> >
> 
> -- 
> Best regards,
> Leonid Krivoshein.
> 

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

Алексей, спасибо за комментарии.

On 04/19/2019 11:04 PM, Alexey Gladkov wrote:

> Я никогда не использовал nfsroot.

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

>> А через mount.nfs монтировать удавалось. Просто немного приболел,
>> поэтому до подготовленного железного стенда на работе пока не доехал. И
>> сначала на виртуалках хочу собрать деплойный вариант подключения
>> NFS-раздела.  Может, смогу в эти выходные.
> 
> Можно попробовать переписать nfsroot с nfsmount на что-то другое.

Да, было бы классно.

 >>> Если внутрь initrd положить человеческий mount.nfs с доп.модулями типа
 >>> nfsv4, то ручками корень монтируется без проблем.
 >>> Однако, дальше ничего не происходит - если покинуть теперь шелл, то
 >>> инитрд продолжает висеть вечно и чего-то ждать, даже по таймауту не
 >>> отваливается.

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

> Мне не известны случаи, когда STOP не работал в принципе. Я знаю, что не
> он, а чтение с терминала может не работать из-за plymouth.

Я смутно вспоминаю, что шелла в итоге я получить не смог - то ли пароль 
бесконечно спрашивали, то ли еще что-то. И никакие попытки параметров 
типа RDSHELL=shell не помогали.
В любом случае, сейчас шелл работает хорошо.



Еще большой вопрос - как написать фичу? Есть какая-то образцовая 
работающая фича? Или документация, с бест-практиками, примерами...

Мне надо утащить образы по сети, и смонтировать их на /root
(https://github.com/Prividen/make-initrd-colaboot)

Я думал попробовать взять за основу nfsroot, но, похоже, он вообще не 
"запускается". По крайней мере ни одного упоминания в /var/log нет, в 
dmesg только о загруженном модуле nfs.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Fri, Apr 19, 2019 at 11:31:51PM +0200, Michael A. Kangin wrote:
> Алексей, спасибо за комментарии.
> 
> On 04/19/2019 11:04 PM, Alexey Gladkov wrote:
> 
> > Я никогда не использовал nfsroot.
> 
> А есть еще какой-то "payload" для тестирования сетевой загрузки?

Не очень понял вопроса.

> >> А через mount.nfs монтировать удавалось. Просто немного приболел,
> >> поэтому до подготовленного железного стенда на работе пока не доехал. И
> >> сначала на виртуалках хочу собрать деплойный вариант подключения
> >> NFS-раздела.  Может, смогу в эти выходные.
> > 
> > Можно попробовать переписать nfsroot с nfsmount на что-то другое.
> 
> Да, было бы классно.

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

>  >>> Если внутрь initrd положить человеческий mount.nfs с доп.модулями типа
>  >>> nfsv4, то ручками корень монтируется без проблем.
>  >>> Однако, дальше ничего не происходит - если покинуть теперь шелл, то
>  >>> инитрд продолжает висеть вечно и чего-то ждать, даже по таймауту не
>  >>> отваливается.
> 
> А как такое вот залипание разруливать? Что нужно выполнить в initrd, 
> чтобы загрузка продолжилась?

Я вкладывал в это поведение немного другое. Думаю, нужно сделать поведение
шелла ближе к тому что вы ожидаете.

> > Мне не известны случаи, когда STOP не работал в принципе. Я знаю, что не
> > он, а чтение с терминала может не работать из-за plymouth.
> 
> Я смутно вспоминаю, что шелла в итоге я получить не смог - то ли пароль 
> бесконечно спрашивали, то ли еще что-то. И никакие попытки параметров 
> типа RDSHELL=shell не помогали.

Если он спрашивал пароль, то это значит вы при создании образа указали 
в /etc/initrd.mk параметр RDSHELL=login или указали защиту паролем.

> Еще большой вопрос - как написать фичу? Есть какая-то образцовая 
> работающая фича? Или документация, с бест-практиками, примерами...

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

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

Безотносительно работает nfsmount или нет эта фича хорошо показывает как
добавляются новые варианты загрузки.

-- 
Rgrds, legion

Re: [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/ скриптов?




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

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/21/2019 05:44 PM, Michael A. Kangin wrote:

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

Давайте попробую пока тут изложить.


В образ initrd не попадает модуль ipv6, поэтому эти конфигурации пока 
проверить не удалось, попробую завтра добавить этот модуль.
В логах (/var/log/ueventd.log):
[2019-04-21 13:28:21] uevent-handler: Running network handler ...
modprobe: FATAL: Module ipv6 not found in directory 
/lib/modules/5.0.6-un-def-alt1



Если не указывать интерфейс, то согласно документации,
ip={on|any|dhcp|dhcp4|dhcp6} get configuration from DHCP server for all 
interfaces.
Однако, под "all interfaces" понимается и lo тоже. И мы имеем 
16секундную задержку в инициализации сети, пока идёт попытка получить 
адрес на lo:

[2019-04-21 13:28:22] 030-network: lo: trying to obtain configuration 
from dhcp ...
[2019-04-21 13:28:22] 030-network: run: ip -6 link set dev lo up
[2019-04-21 13:28:22] 030-network: run: udhcpc -v -n -i lo -t 3 -T 5 -s 
/lib/network/udhcpc4.script -p /var/run/udcpc.lo.pid
[2019-04-21 13:28:22] 030-network: lo: waiting 16 seconds for 
configuration by dhcp ...
[2019-04-21 13:28:37] 030-network: lo: dhcp done
[2019-04-21 13:28:38] 030-network: eth0: trying to obtain configuration 
from dhcp ...
(обратите внимание на таймстампы)



Нотации
ip=<interface>:<autoconf>[:[<mtu>][:<macaddr>]]
ip=<ipaddr>:[<peer>]:<gw>:<netmask>:<hostname>:<interface>:<autoconf>[:[<mtu>][:<macaddr>]]
ip=<ipaddr>:[<peer>]:<gw>:<netmask>:<hostname>:<interface>:<autoconf>[:[<dns1>][:<dns2>]]
работают согласно документации, за некоторыми исключениями:

- фактически, это
ip=[<ipaddr>]:[<peer>]:[gw]:[<netmask>]:[<hostname>]:<interface>:<autoconf>

- фразой "Optionally set <macaddr> on the <interface>" на самом деле 
описывается поведение "переименование сетевого интерфейса, имеющего 
MAC-адрес <macaddr> в новое имя <interface>, (если оно свободно, иначе 
ошибка)".

- mtu на сам сетевой интерфейс не применяется. При этом в конфигурации 
есть такая запись:
/etc/network/ifaces/eth1:# cat iplink
mtu 9000



Не знаю, являются ли ошибкой следующие поведения:
- при конфигурации "ip=dhcp nameserver=8.8.8.8" в /etc/resolv.conf 
попадают сервера, как указанные вручную, так и добытые с помощью DHCP. Я 
могу представить ситуацию, когда хотелось бы избавиться от автоматически 
предлагаемых серверов вообще (кроме того, был бы нелишний параметр для 
search - для подстановки домена)

- конфигурация типа 
"ip=192.168.222.25::192.168.222.20:25:myhost:eth2:dhcp" какая-то 
валидно-бессмысленная, вся информация игнорируется и на eth2 просто 
получается dhcp.




В порядке фичреквеста, я бы кстати предложил поддерживать для статики 
еще одну нотацию, более логично-лаконичную:
ip=<interface>:<ipaddr>[/<netmask>][:<gw>[:<dns>[:[<mtu>]:[mac]]]]
уф, надеюсь не запутался скобочках

С примерами:
ip=eth0:10.255.255.1 #(подразумевается /32)
ip=eth0:123.45.67.89/24:123.45.67.1
ip=stor0:192.168.7.235/255.255.255.128:192.168.7.129:192.168.1.1:9000:fe:fe:de:ad:be:af


И поддержка вланов тоже была бы совершенно не лишней - в датацентрах 
dhcp & tftp может не нейтивом подаваться, а одним из вланов в транке на 
порту.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 01:08:57AM +0200, Michael A. Kangin wrote:
> On 04/21/2019 05:44 PM, Michael A. Kangin wrote:
> 
> > Замечания, появляющиеся в ходе тестирования сети, предпочтительней 
> > оформлять багами или для начала лучше писать сюда (для обсуждения и 
> > понимания, баг это или фича)?
> 
> Давайте попробую пока тут изложить.
> 
> 
> В образ initrd не попадает модуль ipv6, поэтому эти конфигурации пока 
> проверить не удалось, попробую завтра добавить этот модуль.
> В логах (/var/log/ueventd.log):
> [2019-04-21 13:28:21] uevent-handler: Running network handler ...
> modprobe: FATAL: Module ipv6 not found in directory 
> /lib/modules/5.0.6-un-def-alt1

Ой. Да, нужно лучше проверять его наличие.

> Если не указывать интерфейс, то согласно документации,
> ip={on|any|dhcp|dhcp4|dhcp6} get configuration from DHCP server for all 
> interfaces.
> Однако, под "all interfaces" понимается и lo тоже. И мы имеем 
> 16секундную задержку в инициализации сети, пока идёт попытка получить 
> адрес на lo:
> 
> [2019-04-21 13:28:22] 030-network: lo: trying to obtain configuration 
> from dhcp ...
> [2019-04-21 13:28:22] 030-network: run: ip -6 link set dev lo up
> [2019-04-21 13:28:22] 030-network: run: udhcpc -v -n -i lo -t 3 -T 5 -s 
> /lib/network/udhcpc4.script -p /var/run/udcpc.lo.pid
> [2019-04-21 13:28:22] 030-network: lo: waiting 16 seconds for 
> configuration by dhcp ...
> [2019-04-21 13:28:37] 030-network: lo: dhcp done
> [2019-04-21 13:28:38] 030-network: eth0: trying to obtain configuration 
> from dhcp ...
> (обратите внимание на таймстампы)

Эм. Вы правы и для loopback не нужно dhcp.

> Нотации
> ip=<interface>:<autoconf>[:[<mtu>][:<macaddr>]]
> ip=<ipaddr>:[<peer>]:<gw>:<netmask>:<hostname>:<interface>:<autoconf>[:[<mtu>][:<macaddr>]]
> ip=<ipaddr>:[<peer>]:<gw>:<netmask>:<hostname>:<interface>:<autoconf>[:[<dns1>][:<dns2>]]
> работают согласно документации, за некоторыми исключениями:
> 
> - фактически, это
> ip=[<ipaddr>]:[<peer>]:[gw]:[<netmask>]:[<hostname>]:<interface>:<autoconf>
> 
> - фразой "Optionally set <macaddr> on the <interface>" на самом деле 
> описывается поведение "переименование сетевого интерфейса, имеющего 
> MAC-адрес <macaddr> в новое имя <interface>, (если оно свободно, иначе 
> ошибка)".

Да, а вы ожидали другого ?

> - mtu на сам сетевой интерфейс не применяется. При этом в конфигурации 
> есть такая запись:
> /etc/network/ifaces/eth1:# cat iplink
> mtu 9000

Видимо баг.

> Не знаю, являются ли ошибкой следующие поведения:
> - при конфигурации "ip=dhcp nameserver=8.8.8.8" в /etc/resolv.conf 
> попадают сервера, как указанные вручную, так и добытые с помощью DHCP. Я 
> могу представить ситуацию, когда хотелось бы избавиться от автоматически 
> предлагаемых серверов вообще (кроме того, был бы нелишний параметр для 
> search - для подстановки домена)

Вы предполагаете, что параметры nameserver перетрут значения из DHCP ? Я
старался сделать как в RH в этом месте.

> - конфигурация типа 
> "ip=192.168.222.25::192.168.222.20:25:myhost:eth2:dhcp" какая-то 
> валидно-бессмысленная, вся информация игнорируется и на eth2 просто 
> получается dhcp.

Да, описание через эти параметры может быть однозначной. Я следовал за RH
в реализации [1]. Я не хотел бы плодить несовместимость несовместимости.

[1] https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_network

> В порядке фичреквеста, я бы кстати предложил поддерживать для статики 
> еще одну нотацию, более логично-лаконичную:
> ip=<interface>:<ipaddr>[/<netmask>][:<gw>[:<dns>[:[<mtu>]:[mac]]]]
> уф, надеюсь не запутался скобочках
> 
> С примерами:
> ip=eth0:10.255.255.1 #(подразумевается /32)
> ip=eth0:123.45.67.89/24:123.45.67.1
> ip=stor0:192.168.7.235/255.255.255.128:192.168.7.129:192.168.1.1:9000:fe:fe:de:ad:be:af

Нужно проверить не противоречит ли она остальным.

> И поддержка вланов тоже была бы совершенно не лишней - в датацентрах 
> dhcp & tftp может не нейтивом подаваться, а одним из вланов в транке на 
> порту.

ок. попробую.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 01:08:57AM +0200, Michael A. Kangin wrote:
> On 04/21/2019 05:44 PM, Michael A. Kangin wrote:
> 
> > Замечания, появляющиеся в ходе тестирования сети, предпочтительней 
> > оформлять багами или для начала лучше писать сюда (для обсуждения и 
> > понимания, баг это или фича)?
> 
> Давайте попробую пока тут изложить.
> 
> 
> В образ initrd не попадает модуль ipv6, поэтому эти конфигурации пока 
> проверить не удалось, попробую завтра добавить этот модуль.
> В логах (/var/log/ueventd.log):
> [2019-04-21 13:28:21] uevent-handler: Running network handler ...
> modprobe: FATAL: Module ipv6 not found in directory 
> /lib/modules/5.0.6-un-def-alt1

Да, тут проблема возникла проблема. ipv6 подгружается всегда. также нужен
af_packet. Без них не работает. Придётся выносить сеть в отдельную фичу.
 
-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 06:50:23PM +0300, Leonid Krivoshein wrote:
> >> В логах (/var/log/ueventd.log):
> >> [2019-04-21 13:28:21] uevent-handler: Running network handler ...
> >> modprobe: FATAL: Module ipv6 not found in directory
> >> /lib/modules/5.0.6-un-def-alt1
> > Да, тут проблема возникла проблема. ipv6 подгружается всегда. также нужен
> > af_packet. Без них не работает. Придётся выносить сеть в отдельную фичу.
> 
> Тут выяснилась ещё одна вещь. Оказывается у нас и в stage2 с этим не всё 
> порядке, поскольку etcnet не поддерживает нормально dual-стек. То есть, 
> если ipv4 можно по DHCP, то тогда ipv6 будет только статикой, но оба по 
> DHCP никак. shaba@ говорит, что это неправильно. Просто, когда это делал 
> Сергей Большаков, об этом никто не задумывался.

У меня можно.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Мне кажется, это баг:

[   12.892504] Parsing cmdline arguments: S30cmdline: PANIC: 0: invalid 
number
S30cmdline: PANIC: 0: invalid number

PANIC=0 приводит к такому сообщению и зависанию после стадии udevd.
При значении >0 сразу переходит к mountsrc. 0 вообще-то валидный номер.

И как побороть вот это?

Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y] S
This shell remains here for debug purposes. Press Ctrl-D to continue.
Shell access is not allowed.
Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y]

Пробовал разное, но доступа не даёт.
/bin/sh в образе не может отсутствовать.
Запускаю пока следующим образом:

qemu-kvm -no-user-config -nodefaults -cpu host -m 2048 -balloon virtio 
-vga none -display none -serial stdio -net user -device virtio-rng 
-kernel vmlinuz -initrd initrd.img -append "console=ttyS0,115200 noacpi 
noagp raid=noautodetect debug ip=dhcp4 panic=30 RDSHELL_MODE=shell 
STOP=,mountsrc,"

Ещё вопросик: если я пропускаю шаг mountsrc, какого события M-I будет 
ждать и как долго?


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 08:08:10PM +0300, Leonid Krivoshein wrote:
> Мне кажется, это баг:
> 
> [   12.892504] Parsing cmdline arguments: S30cmdline: PANIC: 0: invalid 
> number
> S30cmdline: PANIC: 0: invalid number
> 
> PANIC=0 приводит к такому сообщению и зависанию после стадии udevd.
> При значении >0 сразу переходит к mountsrc. 0 вообще-то валидный номер.

Эта проверка из libshell. Да, она слишком строгая. В мастере я ослабил
проверку.

> И как побороть вот это?
> 
> Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y] S
> This shell remains here for debug purposes. Press Ctrl-D to continue.
> Shell access is not allowed.
> Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y]

Это, видимо, следствие первой ошибки. В мастере должно работать.

> Пробовал разное, но доступа не даёт.
> /bin/sh в образе не может отсутствовать.

Это защита срабатывает. Он присутствует, но до него не даёт доступ.

> Запускаю пока следующим образом:
> 
> qemu-kvm -no-user-config -nodefaults -cpu host -m 2048 -balloon virtio 
> -vga none -display none -serial stdio -net user -device virtio-rng 
> -kernel vmlinuz -initrd initrd.img -append "console=ttyS0,115200 noacpi 
> noagp raid=noautodetect debug ip=dhcp4 panic=30 RDSHELL_MODE=shell 
> STOP=,mountsrc,"

RDSHELL_MODE в параметрах не имеет смысла.

> Ещё вопросик: если я пропускаю шаг mountsrc, какого события M-I будет 
> ждать и как долго?

Он будет ждать пока появится файл $INIT в /root в течении времени
ROOTDELAY (по умолчанию 180 секунд) и если PANIC=0, то перезагрузит машину
или же выдаст шелл.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 09:11 PM, Leonid Krivoshein wrote:

> OK, будем тестировать master. Кто соберёт тестовое задание? :-)
> Кстати, который из мастеров? На Гитхабе или на Гитальте?

Я залил RPMки http://mak.complife.ru/MI2/
(http://git.altlinux.org/people/legion/packages/make-initrd.git, tag 
2.3.0-alt1 - это master-testing)

Там же можно взять готовый initrd, уже с ipv6 - посмотрите, там шелл 
вроде нормально работает.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 10:11:13PM +0300, Leonid Krivoshein wrote:
> > Это, видимо, следствие первой ошибки. В мастере должно работать.
> >
> 
> OK, будем тестировать master. Кто соберёт тестовое задание? :-)

Обновлю.

> Кстати, который из мастеров? На Гитхабе или на Гитальте?

Без разницы. Я пушу в оба места.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Ещё один момент: при добавлении RDSHELL_FOREVER=1 получается так:

Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y] s
This shell remains here for debug purposes. Press Ctrl-D to continue.
Shell access is not allowed.
/etc/rc.d/rc: line 67:   561 Terminated RDSHELL_NOMESSAGE=1 rdshell
Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y] s
This shell remains here for debug purposes. Press Ctrl-D to continue.
Shell access is not allowed.
/etc/rc.d/rc: line 67:   685 Terminated RDSHELL_NOMESSAGE=1 rdshell
Start service mountsrc (Y)es/(N)o/(C)ontinue/(S)hell? [Y]

Вместо 1 м.б. любая непустая строка.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 01:08 AM, Michael A. Kangin wrote:

> В образ initrd не попадает модуль ipv6, поэтому эти конфигурации пока 
> проверить не удалось, попробую завтра добавить этот модуль.

Попробовал.
Статика - ок
RA-адреса - ок
DHCP - лиза получается, но адрес на интерфейс не применяется.
Лиза в конфиге:
~:# cat /.initrd/network/auto/ifaces/eth1/ipv6address
fd00:eeee:0012:0000:0000:0000:0000:0142 broadcast +

И есть еще некоторая особенность, если указать nameserver=[ipv6::addr], 
то он в resolv.conf тоже попадает со скобочками и не работает.
Без скобочек ок.
Единообразия форматов ради, наверное стоит тут поддержать вариант со 
скобочками.



Параметр route= не работает вообще, ни для v4, ни v6.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Tue, Apr 23, 2019 at 12:06:31AM +0200, Michael A. Kangin wrote:
> On 04/22/2019 01:08 AM, Michael A. Kangin wrote:
> 
> > В образ initrd не попадает модуль ipv6, поэтому эти конфигурации пока 
> > проверить не удалось, попробую завтра добавить этот модуль.
> 
> Попробовал.
> Статика - ок
> RA-адреса - ок
> DHCP - лиза получается, но адрес на интерфейс не применяется.

А в логах что-нибудь есть ?

> Лиза в конфиге:
> ~:# cat /.initrd/network/auto/ifaces/eth1/ipv6address
> fd00:eeee:0012:0000:0000:0000:0000:0142 broadcast +
> 
> И есть еще некоторая особенность, если указать nameserver=[ipv6::addr], 
> то он в resolv.conf тоже попадает со скобочками и не работает.
> Без скобочек ок.
> Единообразия форматов ради, наверное стоит тут поддержать вариант со 
> скобочками.

Да, нужно исправить.

> Параметр route= не работает вообще, ни для v4, ни v6.

В логе ничего нет ?

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/23/2019 08:52 AM, Alexey Gladkov wrote:

>> DHCP - лиза получается, но адрес на интерфейс не применяется.
> 
> А в логах что-нибудь есть ?

/var/log:# cat udhcpc6.eth1.log
udhcpc6: IPv6 fe80:0000:0000:0000:5054:00ff:fea7:2923
udhcpc6: started, v1.28.1
udhcpc6: executing /lib/network/udhcpc6.script deconfig
udhcpc6: entering listen mode: raw
udhcpc6: created raw socket
udhcpc6: IPv6 fe80:0000:0000:0000:5054:00ff:fea7:2923
udhcpc6: sending discover
udhcpc6: waiting 5 seconds
udhcpc6: received a packet
udhcpc6: IPv6 fe80:0000:0000:0000:5054:00ff:fea7:2923
udhcpc6: sending select
udhcpc6: waiting 5 seconds
udhcpc6: received a packet
udhcpc6: lease obtained, lease time 2147483
udhcpc6: executing /lib/network/udhcpc6.script bound
udhcpc6: entering listen mode: none

...
[2019-04-23 10:44:20] uevent-handler: Running network handler ...
[2019-04-23 10:44:20] 030-network: eth1: trying to obtain configuration 
from dhcp ...
[2019-04-23 10:44:20] 030-network: run: ip -6 link set dev eth1 up
[2019-04-23 10:44:20] 030-network: run: udhcpc6 -v -n -i eth1 -t 3 -T 5 
-s /lib/network/udhcpc6.script -p /var/run/udcpc
.eth1.pid
[2019-04-23 10:44:20] 030-network: eth1: waiting 16 seconds for 
configuration by dhcp ...
[2019-04-23 10:44:20] 030-network: eth1: dhcp done
....
[2019-04-23 10:44:22] addr: eth1: run: ip -6 address add dev eth1 
fd00:eeee:0012:0000:0000:0000:0000:0143 broadcast +
ip: broadcast can be set only for IPv4 addresses

Возможно, из-за этого. Полный лог прислать?


>> Параметр route= не работает вообще, ни для v4, ни v6.
> 
> В логе ничего нет ?

Я не нашёл. Если есть куда прицельней заглянуть, скажите.
Грепаются только распарсенные параметры:
/.initrd:# find -type f |xargs grep 'eeee:13'
./initenv:export CMDLINE="ip=eth1:dhcp6 
route=[fd00:eeee:13::/64]:[fd00:eeee:12::5]:eth1 debug rdshell"
./initenv:export ROUTE0="[fd00:eeee:13::/64]:[fd00:eeee:12::5]:eth1"
./initenv:export route="[fd00:eeee:13::/64]:[fd00:eeee:12::5]:eth1"
./kernenv:route=[fd00:eeee:13::/64]:[fd00:eeee:12::5]:eth1




Наверное, для следующего цикла тестирования стоит подождать исправленную 
версию. Вы тогда скажете, какой релиз собрать?

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Sun, Apr 21, 2019 at 05:44:14PM +0200, Michael A. Kangin wrote:
> On 04/21/2019 03:43 PM, Alexey Gladkov wrote:
> 
> >> А есть еще какой-то "payload" для тестирования сетевой загрузки?
> > 
> > Не очень понял вопроса.
> 
> Какая-нибудь фича, которая бы пользовалась сетью для обретения корневой 
> FS. Ну, чтобы система полностью могла загрузиться.
> 
> nfsroot не работает, CLB на новую версию не спортировано, netboot 
> (который выкачивал tgz и распаковывал в tmpfs) тоже не спортирован.
> А больше мне ничего на ум не приходит.

Никакие другие мне тоже не известны. Но раз вы подняли эту проблему, то,
возможно, мы сейчас сделаем такую фичу и починим nfsroot.

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

Интересная мысль. Она хорошо согласуется с необходимостью монтирования
cd-диска, который тоже является промежуточной стадией. По сути нет разницы
между разными промежуточными стадиями. Правда пока этот механизм я не
придумал.

> может оказаться заметно быстрее, чем чистый корень:
> 
> https://lists.altlinux.org/pipermail/ltsp-server/2012-August/002532.html

Интересно.

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

Конечно есть.

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

Дело в том, что для самого себя писать документацию сложно. А заставить
себя в такой ситуации ещё сложнее. Также вы же понимаете что когда один
разрабатываешь что-то, то многие вещи кажутся самоочевидными.

Я надеюсь, что благодаря вам и Леониду, вашим вопросам я смогу заполнить
пробелы.

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

Сейчас добавление дополнительной функциональности стало ещё проще. Весь
рантайм выглядит как обычная система с сервисами. Встроиться можно куда
угодно.

> Сейчас, с новой версией M-I, нет ни понимания, ни документации, ни 
> работающего референсного примера.

Для каждой фичи встраиваться нужно в разные места. Если вы хотите
обработать новый тип загрузки (тот же nfs), то нужно встраиваться нужно в
одно место. Если же вам нужно загрузить консольный шрифт и раскладку, то в
другое. Всё это сильно зависит.

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

udev-коллбэки это лишь часть эвентов. Они позволяют реагировать на
загрузку модулей. Сейчас через тот же механизм можно реагировать на этапы
конфигурации сети.

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

Ок )) Я постараюсь описать некоторые моменты.

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

Ни md_run, ни nfsroot ничего не пишут в процессе работы. Это неприятно.
Поэтому я двигаюсь в сторону отказа от них.

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

nfsroot работало. Возможно, какого-то модуля ядра не хватает.

> в частности после попытки применения рецепта с вики DISABLE_GUESS = root 
> (https://www.altlinux.org/Make-initrd#nfsroot)

Просто для справки, я стараюсь вынести документацию с этой вики на github.

> этот модуль попадать в образ initrd перестал, даже с явным указанием
> MODULES_ADD += nfs в /etc/initrd.mk.

Пожалуйста сделайте пример конфига, где это можно воспроизвести. Это очень
странно.

> Получается, сборка образа initrd не совсем воспроизводима, и от раза к 
> разу может давать разные результаты?

Сборка образа отталкивается от того как был сконфигурён корень. Тут всё
довольно просто.

> Может, есть где сказать нечто вроде "make clean"? Я впервые сталкиваюсь
> с таким поведением, и даже не знаю, куда посмотреть.

Одна попытка сборки с другой никак не связана и не пересекается.

> /etc/initrd/cmdline.d/nfsroot - тут, как я полагаю, нужно 
> зарегистрировать все-все boot parameters, которыми фича собирается 
> пользоваться.

Верно.

Выяснилось, что некоторые пользователи жалуются на ошибки, когда указывают
rootdelay=five.

Из этого вылилась система валидации параметров cmdline.

> Чем отличается register_parameter от register_array (и, судя по 
> исходникам, есть еще register_alias), в каких случаях пользоваться той 
> или иной функцией, какой синтаксис для _array - указывать несколько раз 
> один и тот же параметр, или внутри одного параметра что-то перечислить 
> через запятую? Разглядывание лаконичного кода этих функций в исходниках 
> просветления, увы, не принесло...

Вот как это как раз пример того, что мне казалось очевидным, а
оказывается, что это не так.

Семантика у этих функций такая:

register_parameter <type> <varname> [<default>]

Функция регистрирует параметр <varname> и типом <type>. Также можно
указать значение по умолчанию.

register_array <type> <varname>

Позволяет создать "массив" с определённым типом. По правилам /proc/cmdline
параметр с тем же именем, находящийся правее переписывает предыдущие. В
некоторых случаях хочется иметь возможность получить их все как массив
значений. Пример такого параметра IP. Каждое последующее его указание не
отменяет предыдущий, а конфигурирует другой интерфейс.

register_alias <varname> <another-name> [<another-name> ...]

Эта функция создана для указания более одного имени для одно и того же
параметра. Это полезно если возникает необходимость переименовать
параметр или сделать слой совместимости, например, с dracut по некоторым
параметрам.

type может быть  string, number, bool.

varname это не оригинальное имя, которое может быть указано в
/proc/cmdline, а имя после обработки. Дело в том, что в /proc/cmdline
параметры совсем не shell-like. Они могут содержать дефисы или точки.
Поэтому make-initrd приводит имена параметров к uppercase и заменяет
дефисы и точки на подчёркивания. В такой форме они и регистрируются.

> Как дальше пользоваться этими параметрами? делать в каждом скрипте 
> инклюд . /.initrd/initenv, и ссылаться на переменную параметра, как уже 
> существующую?

Сервис data/etc/rc.d/init.d/cmdline отвечает за разбор cmdline параметров.
Он же создаёт /.initrd/initenv. Это необходимо в том числе и из-за того,
что некоторые параметры используются более чем в одном месте и имеют
значения по умолчанию. Производить анализ cmdline каждый раз, где нужен
параметр очень неудобно по понятным причинам. Поэтому анализ производится
лишь один раз и результат записывается в /.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 нужно использовать, когда мы недовольны качеством предоставленных 
> параметров, еще чем-нибудь, и не хотим оказывать услугу?

Как вы уже правильно заметили этот скрипт выполняется udev'ом. Не нужно
завершаться с ненулевым кодом возврата, если не было ошибки. Если
написать:

[ -n "$NFSROOT" ] || exit

то exit без аргумента будет использовать код возврата от предыдущей
операции, а это 1 так как переменная NFSROOT пуста.

> event="$(make_event)"
> showenv -q > "$event"
> release_event nfsroot "$event"
> 
> Эти заклинания использовать, как_есть?

Заклинания не нужно выполнять никогда. Лучше знать, что происходит. Я
попробую коротко рассказать что это и почему оно так.

udev не может выполнять долгие задания. В udev(1) для RUN написано:

This can only be used for very short-running foreground tasks. Running an
event process for a long period of time may block all further events for
this or a dependent device.

И так было с самого начала. Поэтому обработка событий разделена на две
части и скрипты (filters) из udev ничего сами не делают. Они лишь
подготавливают условия для реальных обработчиков (handlers). Фильтры
выполняются udev'ом параллельно и формируют очередь, которая разбирается
демоном ueventd (User EVENT Daemon). ueventd делает это последовательно
так как порядок выполнения handlers важен.

Теперь зная это возвращаемся к этим трём строчкам. Эти функции описаны в 
data/bin/uevent-sh-functions. 

Функция make_event создаёт временный файл для эвента и печатает его имя.
Далее showenv печатает в этот файл текущие переменные окружения. Это
делается из-за того, что udev передаёт параметры устройства через
окружение. Таким образом handler получит то же самое окружение, что и
filter. Ну и наконец сформированный эвент передаётся на обработку ueventd
функцией release_event.

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

Они подготавливают окружение для разных handler'ов, да, они все разные.

> /lib/uevent/handlers/040-nfsroot - это уже похоже на скрипт, в котором 
> делается реальная работа.

Это handler.

> Всю логику необходимо помещать внутрь функции 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
> 
> т.е. они не подпадают под ожидаемые маски. Это нормально?

Это выполненные задания (см. uevent-sh-functions). Так как initrd
удаляется быстро, то нет смысла их удалять. Но для отладки они очень важны.

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

Всё также как и в обычной системе. Если вам нужна отдельная служба, то
нужно делать сервис, если нет, то не нужно.

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

В initrd используется lsb заголовки для сервисов. Сервисы могут
предоставлять как реальное имя так и виртуальное имя. Это очень старый
механизм и о нём я много рассказывать не буду. Подробнее здесь [1][2].

Ссылки создаются в процессе создания обарза утилитой sort-lsb.

> Если в рантайме нужно делать какие-то мелкие действия, обязательно ли 
> оформлять для этого init.d/сервис, или есть какой-то аналог rc.local? 

Не понял вопроса.

> Работают ли еще старые механизмы pre/ post/ скриптов?

Нет. Раньше были стадии перед которыми можно было вклиниться, но с v2
функционально их не стало и даже для обратной совместимости неоткуда их
вызвать.

Я очень долго просил откликнуться тех у кого есть фичи, чтобы помочь в
адаптации. Всем кто откликнулся я помог.

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

На релиз в сизифе баги стоит вешать в багзиллу. До релиза пишите в личку
или на github.

[1] https://github.com/legionus/make-initrd/blob/master/docs/InitramfsServices.md
[2] https://github.com/legionus/make-initrd/blob/master/docs/BootRuntime.md

P.S. Уф. У вас длинное письмо. Я постарался ответить на всё. Извините,
если получилось слишком много.

P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
обсуждаем, то вы мне очень поможете сделать всё понятнее.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

22.04.2019 03:04, Alexey Gladkov пишет:
> On Sun, Apr 21, 2019 at 05:44:14PM +0200, Michael A. Kangin wrote:
>> On 04/21/2019 03:43 PM, Alexey Gladkov wrote:
>>
>>>> А есть еще какой-то "payload" для тестирования сетевой загрузки?
>>> Не очень понял вопроса.
>> Какая-нибудь фича, которая бы пользовалась сетью для обретения корневой
>> FS. Ну, чтобы система полностью могла загрузиться.
>>
>> nfsroot не работает, CLB на новую версию не спортировано, netboot
>> (который выкачивал tgz и распаковывал в tmpfs) тоже не спортирован.
>> А больше мне ничего на ум не приходит.
> Никакие другие мне тоже не известны. Но раз вы подняли эту проблему, то,
> возможно, мы сейчас сделаем такую фичу и починим nfsroot.

Я использую NFS как BACKUP-носитель (read-only), с которого запускается 
скрипт и берутся образы для восстановления целевой системы. Но при 
помещении в initramfs своего кода, мне нужно либо ждать события 
появления целевого диска, либо положиться на функционал make-initrd.


>>> Попробую сделать это в ближайшее время. Буду признателен, если
>>> заинтересованные в таком варианте протестируют перед релизом.
>> Разумеется.
>> Думаю, было бы неплохо так же рассматривать NFS как транспорт для других
>> фич, по давним замерам производительности смонтировать squashfs по NFS
> Интересная мысль. Она хорошо согласуется с необходимостью монтирования
> cd-диска, который тоже является промежуточной стадией. По сути нет разницы
> между разными промежуточными стадиями. Правда пока этот механизм я не
> придумал.

На всякий случай добавлю: нынешний сервер сетевой загрузки через скрипт 
init-bottom поддерживает ещё один слой: сначала с NFS-сервера берётся 
ISO-образ, после его монтирования берётся squashfs, а над ним уже 
делаются слои R/W. То есть можно выстроить целую цепочку "транспортов".


> [...]
>> Поэтому буду рад любым советам и намёкам (варианты for dummies, in a
>> nutshell вообще бесценны для снижения порога вхождения и сглаживания
>> лёрнинг курвы :)
> Ок )) Я постараюсь описать некоторые моменты.
>
> [...]
> P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
> обсуждаем, то вы мне очень поможете сделать всё понятнее.
>

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



-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 06:46:02PM +0300, Leonid Krivoshein wrote:
> На всякий случай добавлю: нынешний сервер сетевой загрузки через скрипт 
> init-bottom поддерживает ещё один слой: сначала с NFS-сервера берётся 
> ISO-образ, после его монтирования берётся squashfs, а над ним уже 
> делаются слои R/W. То есть можно выстроить целую цепочку "транспортов".

Я как раз и делаю возможность создания цепочек. Я пока не придумал как это
лучше конфигурировать. Если компоненты корня можно понять по sysfs, то эти
цепочки чисто умозрительные. Необходима возможность как задавать их при
создании образа, так и в рантайме через cmdline. При этом всё это должно
быть совместимо с method=.
 
> > [...]
> > P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
> > обсуждаем, то вы мне очень поможете сделать всё понятнее.
> >
> 
> С удовольствием помогу. И вопросами помучаем все вместе, и документацию 
> по твоим ответам я на русском языке берусь сделать на тимовской ВиКи. С 
> синхронизацией тоже как-нибудь решим. Но с переводом на английский у 
> меня пока не очень всё хорошо, за это я точно не возьмусь.

Может можно Михаила Шигорина попросить адаптировать доки для github или он
перегружен сверх меры ?

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael Shigorin]

On Mon, Apr 22, 2019 at 06:06:08PM +0200, Alexey Gladkov wrote:
> > > P.P.S. Если вы найдёте время помочь мне с документацией
> > > того, что мы тут обсуждаем, то вы мне очень поможете
> > > сделать всё понятнее.
> > С удовольствием помогу. И вопросами помучаем все вместе,
> > и документацию по твоим ответам я на русском языке берусь
> > сделать на тимовской ВиКи. С синхронизацией тоже как-нибудь
> > решим. Но с переводом на английский у меня пока не очень всё
> > хорошо, за это я точно не возьмусь.
> Может можно Михаила Шигорина попросить адаптировать доки для
> github или он перегружен сверх меры ?

Эээ... я пока даже не понял, про какие доки речь %)

Переводить технические тексты на аглицкий обычно могу
и когда голова поутру ещё не включилась вообще.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

22.04.2019 19:16, Michael Shigorin пишет:
> On Mon, Apr 22, 2019 at 06:06:08PM +0200, Alexey Gladkov wrote:
>>>> P.P.S. Если вы найдёте время помочь мне с документацией
>>>> того, что мы тут обсуждаем, то вы мне очень поможете
>>>> сделать всё понятнее.
>>> С удовольствием помогу. И вопросами помучаем все вместе,
>>> и документацию по твоим ответам я на русском языке берусь
>>> сделать на тимовской ВиКи. С синхронизацией тоже как-нибудь
>>> решим. Но с переводом на английский у меня пока не очень всё
>>> хорошо, за это я точно не возьмусь.
>> Может можно Михаила Шигорина попросить адаптировать доки для
>> github или он перегружен сверх меры ?
> Эээ... я пока даже не понял, про какие доки речь %)

Речь о переводе на английский документации по make-initrd2.
Её сначала написать надо, я это готов сделать.

> Переводить технические тексты на аглицкий обычно могу
> и когда голова поутру ещё не включилась вообще.

Но сможешь ли ты выделить на это время?


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

22.04.2019 19:06, Alexey Gladkov пишет:
> On Mon, Apr 22, 2019 at 06:46:02PM +0300, Leonid Krivoshein wrote:
>> На всякий случай добавлю: нынешний сервер сетевой загрузки через скрипт
>> init-bottom поддерживает ещё один слой: сначала с NFS-сервера берётся
>> ISO-образ, после его монтирования берётся squashfs, а над ним уже
>> делаются слои R/W. То есть можно выстроить целую цепочку "транспортов".
> Я как раз и делаю возможность создания цепочек. Я пока не придумал как это
> лучше конфигурировать. Если компоненты корня можно понять по sysfs, то эти
> цепочки чисто умозрительные. Необходима возможность как задавать их при
> создании образа, так и в рантайме через cmdline. При этом всё это должно
> быть совместимо с method=.

Отличненько!


>   
>>> [...]
>>> P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
>>> обсуждаем, то вы мне очень поможете сделать всё понятнее.
>>>
>> С удовольствием помогу. И вопросами помучаем все вместе, и документацию
>> по твоим ответам я на русском языке берусь сделать на тимовской ВиКи. С
>> синхронизацией тоже как-нибудь решим. Но с переводом на английский у
>> меня пока не очень всё хорошо, за это я точно не возьмусь.
> Может можно Михаила Шигорина попросить адаптировать доки для github или он
> перегружен сверх меры ?

Миша загружен, да. Но с переводами тоже чего-нибудь придумаем. По-русски 
бы для начала нормально всё сформулировать.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael Shigorin]

On Mon, Apr 22, 2019 at 06:06:08PM +0200, Alexey Gladkov wrote:
> On Mon, Apr 22, 2019 at 06:46:02PM +0300, Leonid Krivoshein wrote:
> > На всякий случай добавлю: нынешний сервер сетевой загрузки через скрипт 
> > init-bottom поддерживает ещё один слой: сначала с NFS-сервера берётся 
> > ISO-образ, после его монтирования берётся squashfs, а над ним уже 
> > делаются слои R/W. То есть можно выстроить целую цепочку "транспортов".
> Я как раз и делаю возможность создания цепочек. Я пока не придумал как это
> лучше конфигурировать. Если компоненты корня можно понять по sysfs, то эти
> цепочки чисто умозрительные. Необходима возможность как задавать их при
> создании образа, так и в рантайме через cmdline. При этом всё это должно
> быть совместимо с method=.

Предлагаю обсуждение перенести в make-initrd@:
https://lists.altlinux.org/mailman/listinfo/make-initrd

Туда же могу bounce'нуть оригиналы писем из этой переписки,
начиная с этого, если все их авторы не возражают -- мне кажется,
это будет уже довольно ценный архив. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

23.04.2019 14:57, Michael Shigorin пишет:
> On Mon, Apr 22, 2019 at 06:06:08PM +0200, Alexey Gladkov wrote:
>> On Mon, Apr 22, 2019 at 06:46:02PM +0300, Leonid Krivoshein wrote:
>>> На всякий случай добавлю: нынешний сервер сетевой загрузки через скрипт
>>> init-bottom поддерживает ещё один слой: сначала с NFS-сервера берётся
>>> ISO-образ, после его монтирования берётся squashfs, а над ним уже
>>> делаются слои R/W. То есть можно выстроить целую цепочку "транспортов".
>> Я как раз и делаю возможность создания цепочек. Я пока не придумал как это
>> лучше конфигурировать. Если компоненты корня можно понять по sysfs, то эти
>> цепочки чисто умозрительные. Необходима возможность как задавать их при
>> создании образа, так и в рантайме через cmdline. При этом всё это должно
>> быть совместимо с method=.
> Предлагаю обсуждение перенести в make-initrd@:
> https://lists.altlinux.org/mailman/listinfo/make-initrd
>
> Туда же могу bounce'нуть оригиналы писем из этой переписки,
> начиная с этого, если все их авторы не возражают -- мне кажется,
> это будет уже довольно ценный архив. :)

Я только ЗА! Тогда все, кому надо, подпишутся сами.


-- 
Best regards,
Leonid Krivoshein.

[make-initrd] Move to make-initrd@ maillist (was: Re: [devel] syslinux)

[Alexey Gladkov]

On Tue, Apr 23, 2019 at 03:03:28PM +0300, Leonid Krivoshein wrote:
> > Туда же могу bounce'нуть оригиналы писем из этой переписки,
> > начиная с этого, если все их авторы не возражают -- мне кажется,
> > это будет уже довольно ценный архив. :)
> 
> Я только ЗА! Тогда все, кому надо, подпишутся сами.

Да! И, господа, давайте разобьём тред на несколько. Я уже начал теряться.
Поэтому прошу заранее извинить меня, если я пропустил ваш вопрос.

-- 
Rgrds, legion

Re: [make-initrd] Move to make-initrd@ maillist (was: Re: [devel] syslinux)

[Michael Shigorin]

On Tue, Apr 23, 2019 at 02:27:31PM +0200, Alexey Gladkov wrote:
> > Я только ЗА! Тогда все, кому надо, подпишутся сами.
> Да!

Так подписывайтесь, пока там только два Миши :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] Move to make-initrd@ maillist

[Michael A. Kangin]

On 04/23/2019 02:28 PM, Michael Shigorin wrote:

> Так подписывайтесь, пока там только два Миши :)

Первый подписавшийся садится по центру и загадывает желание

а как туда грамотно всё забоунсить? форвардами? треды разорвутся, боюсь..

Re: [make-initrd] Move to make-initrd@ maillist

[Michael Shigorin]

On Tue, Apr 23, 2019 at 02:33:23PM +0200, Michael A. Kangin wrote:
> > Так подписывайтесь, пока там только два Миши :)

Так, остались Лёня и Антон :)

> а как туда грамотно всё забоунсить? форвардами? треды разорвутся, боюсь..

Вот mutt и умеет оригиналы пересылать (bounce, а не forward).
У меня, правда, начала переписки нету -- если кому не лень
выкопировать у себя нужное (или всё подряд) в отдельный mbox
и прислать его мне, то и хорошо, дальше сделаю.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 02:04 AM, Alexey Gladkov wrote:

> Дело в том, что для самого себя писать документацию сложно. А заставить
> себя в такой ситуации ещё сложнее. Также вы же понимаете что когда один
> разрабатываешь что-то, то многие вещи кажутся самоочевидными.

Полностью понимаю и разделяю, сам такой.

Пожалуй, тут потребуется некоторое время на осознание новой информации.
Спасибо!



> Пожалуйста сделайте пример конфига, где это можно воспроизвести. Это очень
> странно.

Знаете, а сегодня он вдруг стал добавляться... С тем же конфигом...
я уж совсем было подумал, что кукушечкой поехал, но всё же удалось найти 
и формализовать это интересное поведение:

[root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
Packed modules: 8139cp 8390 9pnet 9pnet_virtio af_packet ahci

[root@Sisyphus 1]# touch 8139cp 8390 9pnet 9pnet_virtio af_packet ahci

[root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
Packed modules: 8390 9pnet 9pnet_virtio ata_generic ata_piix autofs4


[root@Sisyphus 1]# rpm -V make-initrd
S.5....T.  c /etc/initrd.mk
[root@Sisyphus 1]# rpm -q make-initrd
make-initrd-2.3.0-alt1.x86_64
[root@Sisyphus 1]#

А у меня там директория вчера была, nfs называлась...

конфиг наверное уже не интересен, но он был вот такой например:
[root@Sisyphus 1]# cat /etc/initrd.mk
# trying to detect modules and features to access to root volume
AUTODETECT = all
MODULES_PRELOAD += autofs4
FEATURES += nfsroot
DISABLE_GUESS += ucode



>> Если в рантайме нужно делать какие-то мелкие действия, обязательно ли
>> оформлять для этого init.d/сервис, или есть какой-то аналог rc.local?
> 
> Не понял вопроса.

Проблема в основном связана с загрузкой дополнительных initramfs.

Если я гружу дополнительный дебаг-образ с башем, то мне хочется сразу 
менять шелл для рута на bash.
(кстати, попробуйте: http://mak.complife.ru/MI2/debug.cpio - с башем, 
мышью, dropbear&scp, и прочие lspci)

Если я гружу какие-то дополнительные модули, мне нужно будет выполнить 
"depmod -a" перед запуском сервиса modules.

Сейчас я на каждое такое действие делаю init-файл и заботливо руками 
раскладываю ссылки по rcN.d, но мне кажется, это немного overhead.

С systemd вопросов бы не возникнуло, там это очень хорошо делается через 
name.type.d/some.conf - и pre, и post к любому юниту-таргету.

> Я очень долго просил откликнуться тех у кого есть фичи, чтобы помочь в
> адаптации. Всем кто откликнулся я помог.

Пардон, как-то мимо пролетело, не заметил..

> P.S. Уф. У вас длинное письмо. Я постарался ответить на всё. Извините,
> если получилось слишком много.

MOAAARR! :)


> P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
> обсуждаем, то вы мне очень поможете сделать всё понятнее.

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


>> - фразой "Optionally set <macaddr> on the <interface>" на самом деле 
>> описывается поведение "переименование сетевого интерфейса, имеющего 
>> MAC-адрес <macaddr> в новое имя <interface>, (если оно свободно, иначе 
>> ошибка)".
> 
> Да, а вы ожидали другого ?

Само поведение норм, но прочёв эту фразу, я подумал об "ip link set eth0 
address 02:01:02:03:04:08"


>> Не знаю, являются ли ошибкой следующие поведения:
>> - при конфигурации "ip=dhcp nameserver=8.8.8.8" в /etc/resolv.conf 
>> попадают сервера, как указанные вручную, так и добытые с помощью DHCP. Я 
>> могу представить ситуацию, когда хотелось бы избавиться от автоматически 
>> предлагаемых серверов вообще (кроме того, был бы нелишний параметр для 
>> search - для подстановки домена)
> 
> Вы предполагаете, что параметры nameserver перетрут значения из DHCP ? Я
> старался сделать как в RH в этом месте.

Тут я не очень уверен. Возможно, стоит опросить общественность.
Иногда можно напороться на кривой DNS, настроенный на каком-нибудь 
Длинке, и бывают ситуации, когда по DHCP хочется взять только адрес, но 
ничего более.
Не думаю, что это будет применимо к сценариям сетевой загрузки хостов.

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

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 08:00:34PM +0200, Michael A. Kangin wrote:
> > Пожалуйста сделайте пример конфига, где это можно воспроизвести. Это очень
> > странно.
> 
> Знаете, а сегодня он вдруг стал добавляться... С тем же конфигом...
> я уж совсем было подумал, что кукушечкой поехал, но всё же удалось найти 
> и формализовать это интересное поведение:
> 
> [root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
> Packed modules: 8139cp 8390 9pnet 9pnet_virtio af_packet ahci
> 
> [root@Sisyphus 1]# touch 8139cp 8390 9pnet 9pnet_virtio af_packet ahci
> 
> [root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
> Packed modules: 8390 9pnet 9pnet_virtio ata_generic ata_piix autofs4

Бага. Очень здорово, что вы её нашли!

> Проблема в основном связана с загрузкой дополнительных initramfs.
> 
> Если я гружу дополнительный дебаг-образ с башем, то мне хочется сразу 
> менять шелл для рута на bash.

Я для себя генерирую просто ещё один образ с башем и утилитами.

> (кстати, попробуйте: http://mak.complife.ru/MI2/debug.cpio - с башем, 
> мышью, dropbear&scp, и прочие lspci)
> 
> Если я гружу какие-то дополнительные модули, мне нужно будет выполнить 
> "depmod -a" перед запуском сервиса modules.
> 
> Сейчас я на каждое такое действие делаю init-файл и заботливо руками 
> раскладываю ссылки по rcN.d, но мне кажется, это немного overhead.
> 
> С systemd вопросов бы не возникнуло, там это очень хорошо делается через 
> name.type.d/some.conf - и pre, и post к любому юниту-таргету.

При запаковке образа легче lsb-хэдер написать и ссылки будут созданы сами.
Не думал, что кто-то будет делать их руками.

> > P.P.S. Если вы найдёте время помочь мне с документацией того, что мы тут
> > обсуждаем, то вы мне очень поможете сделать всё понятнее.
> 
> Присоединюсь к ребятам по мере возможностей. Наверное, с таким 
> коллективным творчеством лучше будет на вики пару технических страничек 
> завести.

Спасибо вам всем! Вы уже нашли несколько досадных багов, которые я не
заметил.

> >> - фразой "Optionally set <macaddr> on the <interface>" на самом деле 
> >> описывается поведение "переименование сетевого интерфейса, имеющего 
> >> MAC-адрес <macaddr> в новое имя <interface>, (если оно свободно, иначе 
> >> ошибка)".
> > 
> > Да, а вы ожидали другого ?
> 
> Само поведение норм, но прочёв эту фразу, я подумал об "ip link set eth0 
> address 02:01:02:03:04:08"

Можно попробовать.

> >> Не знаю, являются ли ошибкой следующие поведения:
> >> - при конфигурации "ip=dhcp nameserver=8.8.8.8" в /etc/resolv.conf 
> >> попадают сервера, как указанные вручную, так и добытые с помощью DHCP. Я 
> >> могу представить ситуацию, когда хотелось бы избавиться от автоматически 
> >> предлагаемых серверов вообще (кроме того, был бы нелишний параметр для 
> >> search - для подстановки домена)
> > 
> > Вы предполагаете, что параметры nameserver перетрут значения из DHCP ? Я
> > старался сделать как в RH в этом месте.
> 
> Тут я не очень уверен. Возможно, стоит опросить общественность.
> Иногда можно напороться на кривой DNS, настроенный на каком-нибудь 
> Длинке, и бывают ситуации, когда по DHCP хочется взять только адрес, но 
> ничего более.
> Не думаю, что это будет применимо к сценариям сетевой загрузки хостов.
> 
> В любом случае, кажется указанные руками сервера прописываются первыми, 
> и, значит, будут иметь приоритет.
 
Я попробую что-нибудь тут сделать.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael Shigorin]

On Mon, Apr 22, 2019 at 09:14:35PM +0200, Alexey Gladkov wrote:
> > > P.P.S. Если вы найдёте время помочь мне с документацией
> > > того, что мы тут обсуждаем, то вы мне очень поможете
> > > сделать всё понятнее.
> > Присоединюсь к ребятам по мере возможностей. Наверное, с
> > таким коллективным творчеством лучше будет на вики пару
> > технических страничек завести.
> Спасибо вам всем! Вы уже нашли несколько досадных багов,
> которые я не заметил.

Может, идёмте в какую make-initrd@lists.altlinux.org?
(заодно и предыдущее обсуждение можно туда bounce'нуть)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

22.04.2019 22:19, Michael Shigorin пишет:
> On Mon, Apr 22, 2019 at 09:14:35PM +0200, Alexey Gladkov wrote:
>>>> P.P.S. Если вы найдёте время помочь мне с документацией
>>>> того, что мы тут обсуждаем, то вы мне очень поможете
>>>> сделать всё понятнее.
>>> Присоединюсь к ребятам по мере возможностей. Наверное, с
>>> таким коллективным творчеством лучше будет на вики пару
>>> технических страничек завести.
>> Спасибо вам всем! Вы уже нашли несколько досадных багов,
>> которые я не заметил.
> Может, идёмте в какую make-initrd@lists.altlinux.org?
> (заодно и предыдущее обсуждение можно туда bounce'нуть)

О, а где она? Я чего-то не нашёл! :-)


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael Shigorin]

On Mon, Apr 22, 2019 at 10:25:19PM +0300, Leonid Krivoshein wrote:
> > Может, идёмте в какую make-initrd@lists.altlinux.org?
> О, а где она? Я чего-то не нашёл! :-)

"какую" == "сперва создать руками ldv@" :)

Если legion@ скажет "давай", то и сделаем.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 11:01:29PM +0300, Michael Shigorin wrote:
> On Mon, Apr 22, 2019 at 10:25:19PM +0300, Leonid Krivoshein wrote:
> > > Может, идёмте в какую make-initrd@lists.altlinux.org?
> > О, а где она? Я чего-то не нашёл! :-)
> 
> "какую" == "сперва создать руками ldv@" :)
> 
> Если legion@ скажет "давай", то и сделаем.

Давай. Раз появилось больше одного заинтересованного, то рассылка уместна.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 09:14 PM, Alexey Gladkov wrote:

> Я для себя генерирую просто ещё один образ с башем и утилитами.

Да, раньше тоже так делал. А сейчас готовый debug.img сильно экономит 
время, его теперь можно прицепить к любому initrd (если по либам проблем 
не будет. Сначала я воспользовался старой версией такого образа, еще из 
p8. Ничего, к сизифному инитрд прицепился-заработал без проблем).

Сейчас же, с сетевой загрузкой, еще вопросы деплоя каждого сделанного 
initrd встанут...

>> Если я гружу какие-то дополнительные модули, мне нужно будет выполнить
>> "depmod -a" перед запуском сервиса modules.

Кстати, а вызов depmod можно в самом M-I сделать, с бут-параметром 
допустим? Это позволит хотя бы образы с модулями подключать сбоку: 
расширять функциональность, сокращать размеры, пробовать некий образ 
initrd с разными ядрами.


>> Само поведение норм, но прочёв эту фразу, я подумал об "ip link set eth0
>> address 02:01:02:03:04:08"
> 
> Можно попробовать.

Лучше документацию уточнить :)
Текущее поведение востребовано: если несколько сетевух, непредсказуемо 
как какая обзовётся. И, если мы знаем мак-адрес нужной, то просто пишем
ip=bootcard:dhcp::fe:fe:de:ad:be:af
и нужный нам интерфейс обзывается bootcard, на него ловится адрес и всё 
там грузится.

ии, внимание вопрос! а что будет с таким переименованным в initrd 
интерфейсом после переключения в основную систему?

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 09:14 PM, Alexey Gladkov wrote:

> Я для себя генерирую просто ещё один образ с башем и утилитами.

Кстати, а как бы вы в такой образ клали dropbear-scp? Он конфликтует по 
имени с opensshшным, в системе его всё время держать не получится...

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/23/2019 12:12 AM, Michael A. Kangin wrote:

>> Я для себя генерирую просто ещё один образ с башем и утилитами.
> 
> Кстати, а как бы вы в такой образ клали dropbear-scp? Он конфликтует по 
> имени с opensshшным, в системе его всё время держать не получится...

Кстати о dropbear, ему нужен /dev/pts, иначе к нему подключиться не удаётся:
[4752] Apr 22 22:22:09 pty_allocate: openpty: No such file or directory
[4752] Apr 22 22:22:09 No pty was allocated, couldn't execute
[4752] Apr 22 22:22:09 Exit (root): Exited normally

В initrd оно само не монтируется - в fstab при генерации не попадает, но 
если смонтировать вручную, то можно подключаться нормально.


Кстати, он с dropbear вообще оказывается в образ не собирается, даже 
если добавить syslog дополнительно, да и klogd кудато делся...

[root@Sisyphus 1]# cat /etc/initrd.mk
# trying to detect modules and features to access to root volume
AUTODETECT = all
MODULES_PRELOAD += autofs4
FEATURES += nfsroot dropbear syslog
DISABLE_GUESS += ucode
MODULES_ADD += ipv6


[root@Sisyphus 1]# make-initrd
Config file: /etc/initrd.mk
Generating module dependencies on host ...
Creating initrd image ...
Adding NFS root support ...
Adding syslog support ...
initrd-cp: error: /sbin/klogd: No such file or directory
Adding dropbear server ...
Adding modules ...
Adding modules (preload) ...
Adding rescue modules ...
Adding module dependencies ...
Adding modules to run inside qemu ...
Generating module dependencies in image ...
Adding initrd shell support (shell mode) ...
Packed modules: 8139cp 8390 9pnet 9pnet_virtio af_packet ahci 
ata_generic ata_piix autofs4 caif_virtio cdrom crc-ccitt crc16 
crc32c-intel crc32c_generic crypto_engine drm drm_kms_helper e100 e1000 
evdev ext4 failover fscache fscrypto grace hid hid-generic i2c-core 
input-leds ipv6 jbd2 libahci libata lockd mbcache mii ne2k-pci 
net_failover nfs pata_acpi pcnet32 rng-core rpmsg_core scsi_mod 
serio_raw sr_mod sunrpc ttm virtio virtio-gpu virtio-rng virtio_balloon 
virtio_blk virtio_console virtio_crypto virtio_input virtio_mmio 
virtio_net virtio_pci virtio_ring virtio_rpmsg_bus virtio_scsi 
vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common vringh vsock
Sorting sysvinit services ...
sort-lsb: Error: Unable to find dependency for 'uevent' on K0: $syslog
sort-lsb: Error: Unmet found at runlevel K0 in services: dropbear klogd 
mountsrc syslogd udev uevent
make: *** [/usr/share/make-initrd/mk/rules.mk:59: sort-services] Error 1
make: *** [/usr/share/make-initrd/mk/make-initrd.mk:29: all] Error 1

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

Я могу собрать тестовое задание на основе этого:
http://git.altlinux.org/people/legion/packages/make-initrd.git ?

Это решит проблемы с шеллом?
А то завтра хотел продолжить на железе...


23.04.2019 01:38, Michael A. Kangin пишет:
> On 04/23/2019 12:12 AM, Michael A. Kangin wrote:
>
>>> Я для себя генерирую просто ещё один образ с башем и утилитами.
>>
>> Кстати, а как бы вы в такой образ клали dropbear-scp? Он конфликтует 
>> по имени с opensshшным, в системе его всё время держать не получится...
>
> Кстати о dropbear, ему нужен /dev/pts, иначе к нему подключиться не 
> удаётся:
> [4752] Apr 22 22:22:09 pty_allocate: openpty: No such file or directory
> [4752] Apr 22 22:22:09 No pty was allocated, couldn't execute
> [4752] Apr 22 22:22:09 Exit (root): Exited normally
>
> В initrd оно само не монтируется - в fstab при генерации не попадает, 
> но если смонтировать вручную, то можно подключаться нормально.
>
>
> Кстати, он с dropbear вообще оказывается в образ не собирается, даже 
> если добавить syslog дополнительно, да и klogd кудато делся...
>
> [root@Sisyphus 1]# cat /etc/initrd.mk
> # trying to detect modules and features to access to root volume
> AUTODETECT = all
> MODULES_PRELOAD += autofs4
> FEATURES += nfsroot dropbear syslog
> DISABLE_GUESS += ucode
> MODULES_ADD += ipv6
>
>
> [root@Sisyphus 1]# make-initrd
> Config file: /etc/initrd.mk
> Generating module dependencies on host ...
> Creating initrd image ...
> Adding NFS root support ...
> Adding syslog support ...
> initrd-cp: error: /sbin/klogd: No such file or directory
> Adding dropbear server ...
> Adding modules ...
> Adding modules (preload) ...
> Adding rescue modules ...
> Adding module dependencies ...
> Adding modules to run inside qemu ...
> Generating module dependencies in image ...
> Adding initrd shell support (shell mode) ...
> Packed modules: 8139cp 8390 9pnet 9pnet_virtio af_packet ahci 
> ata_generic ata_piix autofs4 caif_virtio cdrom crc-ccitt crc16 
> crc32c-intel crc32c_generic crypto_engine drm drm_kms_helper e100 
> e1000 evdev ext4 failover fscache fscrypto grace hid hid-generic 
> i2c-core input-leds ipv6 jbd2 libahci libata lockd mbcache mii 
> ne2k-pci net_failover nfs pata_acpi pcnet32 rng-core rpmsg_core 
> scsi_mod serio_raw sr_mod sunrpc ttm virtio virtio-gpu virtio-rng 
> virtio_balloon virtio_blk virtio_console virtio_crypto virtio_input 
> virtio_mmio virtio_net virtio_pci virtio_ring virtio_rpmsg_bus 
> virtio_scsi vmw_vsock_virtio_transport 
> vmw_vsock_virtio_transport_common vringh vsock
> Sorting sysvinit services ...
> sort-lsb: Error: Unable to find dependency for 'uevent' on K0: $syslog
> sort-lsb: Error: Unmet found at runlevel K0 in services: dropbear 
> klogd mountsrc syslogd udev uevent
> make: *** [/usr/share/make-initrd/mk/rules.mk:59: sort-services] Error 1
> make: *** [/usr/share/make-initrd/mk/make-initrd.mk:29: all] Error 1
>

-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

23.04.2019 01:48, Leonid Krivoshein пишет:
> Я могу собрать тестовое задание на основе этого:
> http://git.altlinux.org/people/legion/packages/make-initrd.git ?
>
> Это решит проблемы с шеллом?
> А то завтра хотел продолжить на железе...
>

Собрал #227990, shell наконец получил, но сеть не взлетела совсем... это 
после переноса в отдельную фичу. Завтра тогда продолжу.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

23.04.2019 03:49, Leonid Krivoshein пишет:
> [...]
> Собрал #227990, shell наконец получил, но сеть не взлетела совсем... 
> это после переноса в отдельную фичу. Завтра тогда продолжу.

Вчера она не взлетела по моей вине, на самом деле сеть работает!


У меня теперь другой вопрос: это нормально, что когда выбираю только 
ip=dhcp4, поднимается ещё и ipv6, причём, как-то так?

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
qlen 1000
     link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
     inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
        valid_lft forever preferred_lft forever
     inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic
        valid_lft 86014sec preferred_lft 14014sec
     inet6 fe80::5054:ff:fe12:3456/64 scope link
        valid_lft forever preferred_lft forever

(initramfs)$ cat /var/log/udhcpc4.lo.log
udhcpc: started, v1.28.1
udhcpc: executing /lib/network/udhcpc4.script deconfig
udhcpc: entering listen mode: raw
udhcpc: created raw socket
udhcpc: sending discover
udhcpc: waiting 5 seconds
udhcpc: unrelated/bogus packet, ignoring
udhcpc: waiting 5 seconds
udhcpc: sending discover
udhcpc: waiting 5 seconds
udhcpc: unrelated/bogus packet, ignoring
udhcpc: waiting 5 seconds
udhcpc: sending discover
udhcpc: waiting 5 seconds
udhcpc: unrelated/bogus packet, ignoring
udhcpc: waiting 5 seconds
udhcpc: executing /lib/network/udhcpc4.script leasefail
udhcpc: no lease, failing

Хотя, последнее может быть ограничением qemu user-mode.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

И ещё...

# Чудесно всё работает:
nfsmount -o ro,nolock,soft 10.4.0.3:/space/office/klark /mnt/nfs

# А так -- нет (ip=dhcp4):
nfsmount -o ro,nolock,soft alt:/space/office/klark /mnt/nfs
nfsmount: can't parse IP address 'alt'

# Может, дело в этом?
resolve alt
sh: resolve: command not found

cat /etc/resolv.conf

# eth0: DHCP4 start
nameserver 10.0.2.3
# eth0: DHCP4 end


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

23.04.2019 14:42, Leonid Krivoshein пишет:
>
> # А так -- нет (ip=dhcp4):
> nfsmount -o ro,nolock,soft alt:/space/office/klark /mnt/nfs
> nfsmount: can't parse IP address 'alt'
>

При этом:

(initramfs)$ wget ya.ru
Connecting to ya.ru (87.250.250.242:80)
Connecting to ya.ru (87.250.250.242:443)
index.html           100% |*******************************| 13585 
0:00:00 ETA


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/23/2019 01:42 PM, Leonid Krivoshein wrote:

> # Чудесно всё работает:
> nfsmount -o ro,nolock,soft 10.4.0.3:/space/office/klark /mnt/nfs

У меня нет:
~:# nfsmount -o ro,nolock,soft 192.168.222.1:/home/sisyphus /home/
connect: Connection refused
read: Connection refused
read: Connection refused

Но хоть пакеты по сети забегали, прогресс
а с какими опциями шарите шару? покажите пожалуйста exportfs -s

> nfsmount: can't parse IP address 'alt'

Это alt - оно по ДНСу так должно отдаваться или в hosts сидит?
Просто пропинговать можно? дигом резолвится? пингуется?

> # Может, дело в этом?
> resolve alt
> sh: resolve: command not found

добавьте сбоку ;)

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/23/2019 01:33 PM, Leonid Krivoshein wrote:

> У меня теперь другой вопрос: это нормально, что когда выбираю только 
> ip=dhcp4, поднимается ещё и ipv6, причём, как-то так?

ipv6 поднимается потому что там модуль грузится. Алексей вроде уже хотел 
подумать над этим поведением.



>      inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic
>         valid_lft 86014sec preferred_lft 14014sec

Это Router Advertisement address, назначается прям ядром. Эти адреса 
состоят из сетевой части, выделяемые сетевыми железками, или radvd, и 
MAC-адреса клиента 
(https://en.wikipedia.org/wiki/IPv6_address#Modified_EUI-64)


>      inet6 fe80::5054:ff:fe12:3456/64 scope link
>         valid_lft forever preferred_lft forever

Это link-local address, конструируется из префикса fe80:: и MAC

Назначается не помню сейчас кем, по по идее должен быть на каждом 
интерфейсе.

> (initramfs)$ cat /var/log/udhcpc4.lo.log

Обратите внимание, это лог для lo

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

23.04.2019 15:02, Michael A. Kangin пишет:
> On 04/23/2019 01:33 PM, Leonid Krivoshein wrote:
>
>> (initramfs)$ cat /var/log/udhcpc4.lo.log
>
> Обратите внимание, это лог для lo
>

Что и странно, поскольку это единственный лог, для других интерфейсов 
такого нет.


-- 
Best regards,
Leonid Krivoshein.

Re: [Make-initrd] [devel] syslinux

[Alexey Gladkov]

On Tue, Apr 23, 2019 at 02:02:09PM +0200, Michael A. Kangin wrote:
> On 04/23/2019 01:33 PM, Leonid Krivoshein wrote:
> 
> > У меня теперь другой вопрос: это нормально, что когда выбираю только 
> > ip=dhcp4, поднимается ещё и ipv6, причём, как-то так?
> 
> ipv6 поднимается потому что там модуль грузится. Алексей вроде уже хотел 
> подумать над этим поведением.

Да, нужно делать disable_ipv6, если явно не настраивается.
 
> > (initramfs)$ cat /var/log/udhcpc4.lo.log
> 
> Обратите внимание, это лог для lo

Я запушил исправление и теперь dhcp и ip-route игнорирует loopback девайсы.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Tue, Apr 23, 2019 at 02:02:09PM +0200, Michael A. Kangin wrote:
> On 04/23/2019 01:33 PM, Leonid Krivoshein wrote:
> 
> > У меня теперь другой вопрос: это нормально, что когда выбираю только 
> > ip=dhcp4, поднимается ещё и ipv6, причём, как-то так?
> 
> ipv6 поднимается потому что там модуль грузится. Алексей вроде уже хотел 
> подумать над этим поведением.

Да, нужно делать disable_ipv6, если явно не настраивается.
 
> > (initramfs)$ cat /var/log/udhcpc4.lo.log
> 
> Обратите внимание, это лог для lo

Я запушил исправление и теперь dhcp и ip-route игнорирует loopback девайсы.

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Mon, Apr 22, 2019 at 08:00:34PM +0200, Michael A. Kangin wrote:
> Знаете, а сегодня он вдруг стал добавляться... С тем же конфигом...
> я уж совсем было подумал, что кукушечкой поехал, но всё же удалось найти 
> и формализовать это интересное поведение:
> 
> [root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
> Packed modules: 8139cp 8390 9pnet 9pnet_virtio af_packet ahci
> 
> [root@Sisyphus 1]# touch 8139cp 8390 9pnet 9pnet_virtio af_packet ahci
> 
> [root@Sisyphus 1]# make-initrd |grep ^Packed |cut -f-8 -d' '
> Packed modules: 8390 9pnet 9pnet_virtio ata_generic ata_piix autofs4
> 
> 
> [root@Sisyphus 1]# rpm -V make-initrd
> S.5....T.  c /etc/initrd.mk
> [root@Sisyphus 1]# rpm -q make-initrd
> make-initrd-2.3.0-alt1.x86_64
> [root@Sisyphus 1]#
> 
> А у меня там директория вчера была, nfs называлась...

Оказалось, что libkmod несколько туповата. Она может выдать за модуль
просто файл и довольно долго притворяться, что это модуль.

Исправил в master.

> Сейчас я на каждое такое действие делаю init-файл и заботливо руками 
> раскладываю ссылки по rcN.d, но мне кажется, это немного overhead.
> 
> С systemd вопросов бы не возникнуло, там это очень хорошо делается через 
> name.type.d/some.conf - и pre, и post к любому юниту-таргету.

У меня уже было такое. В master вернул возможность запустить скрипт до и
после сервиса. Скрипты /lib/initrd/pre/$svc и /lib/initrd/post/$svc.

-- 
Rgrds, legion

[make-initrd] handlers

[Michael A. Kangin]

On 04/22/2019 02:04 AM, Alexey Gladkov wrote:

> Это handler.
>> Всю логику необходимо помещать внутрь функции handler() как я понимаю.
> 
> Да. Но нужно помнить, что пока этот скрипт не завершит работу следующий не
> будет запущен.

Как поступать, если нужно выполнять много всего и долго?
Засовывать всё в этот хандлер, или вызывать оттуда еще скрипты?

Как их там удобнее всего дебажить? Как можно из произвольного места 
выпасть в диагностический шелл?

Какой функцией лучше всего держать в курсе скучающего пользователя, 
message? Можно ли импортнуть полный набор красивых разноцветностей из 
/etc/rc.d/init.d/functions?

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

Заметил, что часть хандлеров всегда выходит с нулевым кодом, а часть - 
exit $rс

Чем пользоваться, с чем возвращаться? Что будет, если не 0?

Re: [make-initrd] handlers

[Michael A. Kangin]

On 04/29/2019 11:54 PM, Michael A. Kangin wrote:

>> Это handler.

И можно ли из него подгружать еще модули ядра?

Re: [make-initrd] handlers

[Alexey Gladkov]

On Tue, Apr 30, 2019 at 12:04:39AM +0200, Michael A. Kangin wrote:
> On 04/29/2019 11:54 PM, Michael A. Kangin wrote:
> 
> >> Это handler.
> 
> И можно ли из него подгружать еще модули ядра?

Да.

-- 
Rgrds, legion

Re: [make-initrd] handlers

[Alexey Gladkov]

On Mon, Apr 29, 2019 at 11:54:22PM +0200, Michael A. Kangin wrote:
> On 04/22/2019 02:04 AM, Alexey Gladkov wrote:
> 
> > Это handler.
> >> Всю логику необходимо помещать внутрь функции handler() как я понимаю.
> > 
> > Да. Но нужно помнить, что пока этот скрипт не завершит работу следующий не
> > будет запущен.
> 
> Как поступать, если нужно выполнять много всего и долго?

Нужно запускать отдельный процесс, который что-то делает. Пока handler
выполняется никакой другой handler не будет запущен.

> Засовывать всё в этот хандлер, или вызывать оттуда еще скрипты?

В нём ты можешь делать что угодно.

> Как их там удобнее всего дебажить? Как можно из произвольного места 
> выпасть в диагностический шелл?

. rhshell-sh-functions

console_open "Emergency shell" withlock

> Какой функцией лучше всего держать в курсе скучающего пользователя, 
> message?

handler не выводит ничего на консоль. Только в лог. Консоль доступна, но
на ней может кто-то быть. Вы можете подраться.

> Можно ли импортнуть полный набор красивых разноцветностей из 
> /etc/rc.d/init.d/functions?

Можно.

> Заметил, что часть хандлеров всегда выходит с нулевым кодом, а часть - 
> exit $rс
> 
> Чем пользоваться, с чем возвращаться?

Ненулевой код возврата значит, что в хэндлере произошла ошибка.

>Что будет, если не 0?

Ничего. Будет в логе запись.

-- 
Rgrds, legion

Re: [make-initrd] handlers

[Michael A. Kangin]

On 04/30/2019 01:40 PM, Alexey Gladkov wrote:

>> Какой функцией лучше всего держать в курсе скучающего пользователя,
>> message?
> 
> handler не выводит ничего на консоль. Только в лог. Консоль доступна, но
> на ней может кто-то быть. Вы можете подраться.


Косметика косметикой, но это может быть некоторым неудобством.
С сетью, в зависимости от скорости линка и размера образа, выкачивание 
этого образа может занять несколько минут (то же касается медленных 
CDROM'ов).
И было бы классно уметь что-то писать на экран - чтоделаем, прогресс, 
ошибка чтобы сразу была видна, если что-то не загрузилось / не 
отрезолвилось.

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

Re: [make-initrd] handlers

[Alexey Gladkov]

On Tue, Apr 30, 2019 at 01:51:18PM +0200, Michael A. Kangin wrote:
> On 04/30/2019 01:40 PM, Alexey Gladkov wrote:
> 
> >> Какой функцией лучше всего держать в курсе скучающего пользователя,
> >> message?
> > 
> > handler не выводит ничего на консоль. Только в лог. Консоль доступна, но
> > на ней может кто-то быть. Вы можете подраться.
> 
> 
> Косметика косметикой, но это может быть некоторым неудобством.

Есть как минимум три случая, когда там может кто-то оказаться:

* Когда наступил таймаут (rootdelay) пользователю будет выдан шелл;
* Когда в cmdline был указан параметр rdshell=1;
* Когда пользователь перешёл в режим интерактивной загрузки.

Во всех этих случаях /dev/console будет занята шеллом и, возможно, там
будет работать пользователь. Прогресс в этом случае будет сильно ему
мешать. Можно пытаться учитывать занята ли консоль или нет (для этого есть
функции).

> Может, тогда из хандлера запускать демона, который сделает всю работу в 
> вербальном режиме?

Ты себе представляешь двух демонов дерущихся за консоль ?

> Или наоборот, запускать демона, который сделает всё и создаст какие-то 
> условия для работы хандлера...

-- 
Rgrds, legion

Re: [make-initrd] handlers

[Michael A. Kangin]

On 04/30/2019 06:07 PM, Alexey Gladkov wrote:

 > * Когда наступил таймаут (rootdelay) пользователю будет выдан шелл;

К этому моменту, по идее, все статусы и ошибки должны уже отобразиться.
Кстати, а что будет, если не успеть загрузить образ rootfs за rootdelay?

 > * Когда в cmdline был указан параметр rdshell=1;
 > * Когда пользователь перешёл в режим интерактивной загрузки.

Он знал на что шёл!!
Кстати, с этим и сейчас бывают проблемы. Если загрузка вербозная, то 
ядро любит какой-нибудь rnd инициализировать с радостными воплями после 
первых нажатий на клавиши (свежую энтропию подвезли, чо)



> Во всех этих случаях /dev/console будет занята шеллом и, возможно, там
> будет работать пользователь. Прогресс в этом случае будет сильно ему
> мешать. Можно пытаться учитывать занята ли консоль или нет (для этого есть
> функции).

Ага, например (а какие?)
или проверять перед каждым выводом, не появился ли процесс консоли?


Еще есть смутная мысль, что можно попробовать сделать какую-то status 
line для текущих статусных сообщений от handler'ов (они же поочерёдно 
выполняются, и драться друг с другом не будут) и фатальных ошибок.


например screen'ом:
https://www.systutorials.com/241379/how-to-add-a-status-bar-to-screen-on-linux/

Или более низкоуровнево, tput / ESC-seq

Или гонять шелл на других консолях, а первую оставить только для статусов?

И еще же plymouth может быть..


> 
>> Может, тогда из хандлера запускать демона, который сделает всю работу в
>> вербальном режиме?
> 
> Ты себе представляешь двух демонов дерущихся за консоль ?

Да я еще мож и поучаствовал бы!!!11

Re: [make-initrd] handlers

[Leonid Krivoshein]

30.04.2019 19:39, Michael A. Kangin пишет:
> On 04/30/2019 06:07 PM, Alexey Gladkov wrote:
>
> > * Когда наступил таймаут (rootdelay) пользователю будет выдан шелл;
>
> К этому моменту, по идее, все статусы и ошибки должны уже отобразиться.
> Кстати, а что будет, если не успеть загрузить образ rootfs за rootdelay?

Уже было: в зависимости от panic и др. будет rescue shell, reboot или 
kernel panic.


>
> > * Когда в cmdline был указан параметр rdshell=1;
> > * Когда пользователь перешёл в режим интерактивной загрузки.
>
> Он знал на что шёл!!
> Кстати, с этим и сейчас бывают проблемы. Если загрузка вербозная, то 
> ядро любит какой-нибудь rnd инициализировать с радостными воплями 
> после первых нажатий на клавиши (свежую энтропию подвезли, чо)
>

Ядрёный вывод можно подавлять параметром quiet


> [...]
>
>>
>>> Может, тогда из хандлера запускать демона, который сделает всю работу в
>>> вербальном режиме?
>>
>> Ты себе представляешь двух демонов дерущихся за консоль ?
>
> Да я еще мож и поучаствовал бы!!!11
>

В качестве разнимающего? :-)


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] handlers

[Michael A. Kangin]

On 04/30/2019 06:49 PM, Leonid Krivoshein wrote:

>> Кстати, а что будет, если не успеть загрузить образ rootfs за rootdelay?
> 
> Уже было: в зависимости от panic и др. будет rescue shell, reboot или 
> kernel panic.

При отсутствии специального panic, оно вываливается в консоль с надписью 
"the waiting time expired".

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

Надо с этим что-нибудь сделать, выкачивание образов может занять 
неопределённое (но всёже конечное) время.


>>> Ты себе представляешь двух демонов дерущихся за консоль ?
>> Да я еще мож и поучаствовал бы!!!11
> В качестве разнимающего? :-)

Улюлюкающего и болеющего ;)

Re: [make-initrd] [devel] syslinux

[Alexey Gladkov]

On Sun, Apr 21, 2019 at 11:30:40PM +0300, Leonid Krivoshein wrote:
> Алексей,
> 
> 
> Присоединяюсь ко многим вопросам Михаила по документированию, тоже 
> пытаюсь разобраться с make-initrd2. Он уже давно не новинка, а на 
> тимовской ВиКи документация явно не под эту версию.

С тимовской вики есть одна проблема: она обновляется не синхронно. Я
стараюсь взять за правило документировать фичи в *.md файлах синхронно с
изменениями. Это удобнее поддерживать и есть история. Плюс из некоторых md
можно сделать man.

> В понедельник, наверное, получится протестировать NFS без NFSROOT, тогда 
> отпишусь...

Спасибо!

-- 
Rgrds, legion

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

21.04.2019 18:44, Michael A. Kangin пишет:
> On 04/21/2019 03:43 PM, Alexey Gladkov wrote:
>
>>> А есть еще какой-то "payload" для тестирования сетевой загрузки?
>>
>> Не очень понял вопроса.
>
> Какая-нибудь фича, которая бы пользовалась сетью для обретения 
> корневой FS. Ну, чтобы система полностью могла загрузиться.
>
> nfsroot не работает

Михаил, а пробовали с таким конфигом:

AUTODETECT = all
FEATURES = nfsroot
DISABLE_GUESS = root


добавлять в stage2:/etc/fstab строку:

/dev/nfs / nfs <опции> 0 0


?


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/22/2019 08:43 PM, Leonid Krivoshein wrote:

> Михаил, а пробовали с таким конфигом:
> 
> DISABLE_GUESS = root

Этот рецепт с вики я пробовал. fstab внутри initrd не меняется.
если под stage2 понимается лежащий на NFS-шаре корень, до до этого 
просто не доходит - по сети ни одного NFS-пакета не пробегает.

> 
> 
> добавлять в stage2:/etc/fstab строку:
> 
> /dev/nfs / nfs <опции> 0 0
> 
> 
> ?
> 
> 

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

22.04.2019 21:49, Michael A. Kangin пишет:
> On 04/22/2019 08:43 PM, Leonid Krivoshein wrote:
>
>> Михаил, а пробовали с таким конфигом:
>>
>> DISABLE_GUESS = root
>
> Этот рецепт с вики я пробовал. fstab внутри initrd не меняется.

Странно, что не меняется...


> если под stage2 понимается лежащий на NFS-шаре корень, до до этого 
> просто не доходит - по сети ни одного NFS-пакета не пробегает.

Понимается stage2 системы, в которой запускается команда make-initrd.



-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

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

> Если он спрашивал пароль, то это значит вы при создании образа указали
> в /etc/initrd.mk параметр RDSHELL=login или указали защиту паролем.

кстати, определённости ради, правильно ли я понимаю, что если в 
README.md некой фичи упомянуты "Parameters", то их надо в initrd.mk 
применять, а если "Boot parameters" - то в командной строке?

Для меня было неочевидным, куда именно RDSHELL=shell писать (но я 
попробовал всюду)

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

17.04.2019 17:27, Michael A. Kangin пишет:
> Есть ли документация, как правильно фичи писать?
>

Вот вся документация:
https://github.com/legionus/make-initrd/tree/master/docs

Поэтому проще ориентироваться на исходники и уже готовые фичи...


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Michael A. Kangin]

On 04/17/2019 05:26 PM, Leonid Krivoshein wrote:

> Вот вся документация:
> https://github.com/legionus/make-initrd/tree/master/docs

Да, это я уже всё пролазил. В общем, можно считать, что документации 
практически нету.


> Поэтому проще ориентироваться на исходники и уже готовые фичи...

Я уже попробовал так сделать в первый раз. Оно заработало, но получилось 
так себе. И, как теперь выясняется, надо всё переделывать под новую версию.

И вот сейчас я лениво размышляю - то ли под новый M-I ("ориентируясь на 
исходники и уже готовые фичи"), или уж сразу под Dracut. Второе, пожалуй 
что, получится менее времяёмко и более перспективно.

Re: [make-initrd] [devel] syslinux

[Антон Мидюков]

Я собираюсь заняться профилями. Но у меня вопрос: без поддержки cdrom в 
make-initrd собранные ISO не загрузятся в виртуалке? А с флэшки загрузятся?

Также вопрос, каким образом собрать initrd с максимумом модулей?

17.04.2019 22:36, Michael A. Kangin пишет:
> On 04/17/2019 05:26 PM, Leonid Krivoshein wrote:
>
>> Вот вся документация:
>> https://github.com/legionus/make-initrd/tree/master/docs
>
> Да, это я уже всё пролазил. В общем, можно считать, что документации 
> практически нету.
>
>
>> Поэтому проще ориентироваться на исходники и уже готовые фичи...
>
> Я уже попробовал так сделать в первый раз. Оно заработало, но 
> получилось так себе. И, как теперь выясняется, надо всё переделывать 
> под новую версию.
>
> И вот сейчас я лениво размышляю - то ли под новый M-I ("ориентируясь 
> на исходники и уже готовые фичи"), или уж сразу под Dracut. Второе, 
> пожалуй что, получится менее времяёмко и более перспективно.
>
-- 
С уважением, Антон Мидюков <antohami@basealt.ru>

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

17.04.2019 19:16, Антон Мидюков пишет:
> Я собираюсь заняться профилями. Но у меня вопрос: без поддержки cdrom 
> в make-initrd собранные ISO не загрузятся в виртуалке?

Когда legion@ реализует замену пропагаторному методу "cdrom", и, в 
зависимости от того, как он это реализует, тогда и будет смысл 
задумываться о выкидывании пропагатора из профилей. По идее, там должны 
быть минимальные изменения, поскольку необходимый функционал пропагатора 
должен будет переехать в make-initrd. Если выкинуть пропагатор сейчас, с 
созданного гибридного ISO-шника загрузиться по стандарту El-Torito и по 
спецификации UEFI будет нельзя, поскольку сейчас make-initrd сам не 
умеет влезать в squashfs и делать R/W-слои над ним.


> А с флэшки загрузятся?
>

Да. Также, как и по сети с NFS. Для этого уже сейчас можно взять любой 
ранее созданный ISO-шник, взять из его корня stagename-файл (squashfs) и 
его распаковать (как вариант -- тупо скопировать dd'ой) на отдельный 
раздел в случае флэшки или распаковать в отдельный каталог на сервере 
NFS. Это будет read-only rootfs. Далее надо смотреть, что из скрипта 
make-initrd-propagarot.git@init-bootom надо перетащить ещё в initramfs, 
чтобы заработало R/W-монтирование корня через overlayfs. Тут какой-то 
опыт уже есть у Михаила Кангина.

При этом придётся учитывать, что версия ядра, модулей в rootfs и в 
initramfs должны быть одинаковыми. На флэшку придётся ставить какой-то 
загрузчик, тот же syslinux. Скрипт init-bootom мы хотели в любом случае 
сохранить для совместимости, надо будет его перекладывать в тот же 
make-initrd. А проще всего сейчас проверять новый make-initrd, 
подсовывая нужные параметры QEMU (kernel=, initrd=, append=), тогда 
вообще на тему загрузки в тестовых целях можно пока не париться.


> Также вопрос, каким образом собрать initrd с максимумом модулей?
>

Вот об этом было моё предыдущее письмо, про всеядный initrd.img -- в 
него попадут все модули и прошивки, вообще все, что есть в stage2. Но 
для полноты стоит заказать фичи типа lvm, mdadm и всего остального, что 
умеет работать с носителями. Если же ориентироваться на нашу 
дистрибутивную логику, то в пакете propagator есть mkmodpack, к нему 
есть ответная часть в профилях m-p и в скриптах mkimage 
(tools/mki-build-propagator). Вместе они создают наборы модулей и 
фирмвари для всех наши универсальных установочных дисков live, rescue и 
install.

Только там всегда чего-нибудь не хватает, потому что мы пытаемся 
построить замыкание по какому-то принципу. У меня "все" заняли 1.1Гб без 
всяких фич -- это огромный объём, для экспериментов на хорошем железе 
сойдёт, чтобы не заморачиваться. Но для продакшена такой вариант не 
годится. Ведь "все" и не нужны -- к примеру, зачем в initramfs все 
модули ТВ-тюннеров или звуковых карт? А строить замыкание тоже можно 
по-разному...

Сейчас список модулей определяется именно в m-p -- как раз твоя часть. 
Беда в том, что за этим списком наши ядерщики не "ухаживают", я эту 
проблему озвучивал ldv@, mike@ и boyarsh@. С этой позиции лучше 
исключать заведомо ненужное, пусть лучше в initramfs лишнее попадёт. 
Кое-что для включения предпринял legion@, какой-то опыт подборки нужного 
есть у Михаила Кангина. Вот здесь давно пора объединять усилия, 
оглядываясь на dracut и live-boot.


> 17.04.2019 22:36, Michael A. Kangin пишет:
>> On 04/17/2019 05:26 PM, Leonid Krivoshein wrote:
>>
>>> Вот вся документация:
>>> https://github.com/legionus/make-initrd/tree/master/docs
>>
>> Да, это я уже всё пролазил. В общем, можно считать, что документации 
>> практически нету.
>>
>>
>>> Поэтому проще ориентироваться на исходники и уже готовые фичи...
>>
>> Я уже попробовал так сделать в первый раз. Оно заработало, но 
>> получилось так себе. И, как теперь выясняется, надо всё переделывать 
>> под новую версию.
>>


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] [devel] syslinux

[Leonid Krivoshein]

17.04.2019 18:36, Michael A. Kangin пишет:
> On 04/17/2019 05:26 PM, Leonid Krivoshein wrote:
>
>> Вот вся документация:
>> https://github.com/legionus/make-initrd/tree/master/docs
>
> Да, это я уже всё пролазил. В общем, можно считать, что документации 
> практически нету.
>

Да, на русском потом обновим информацию на ВиКи. Сначала самим бы 
разобраться...


>
>> Поэтому проще ориентироваться на исходники и уже готовые фичи...
>
> Я уже попробовал так сделать в первый раз. Оно заработало, но 
> получилось так себе. И, как теперь выясняется, надо всё переделывать 
> под новую версию.
>

Сходу со второй версией M-I у меня тоже не вышло разобраться. Но, слава 
богу, legion@ его активно развивает и поддерживает.


> И вот сейчас я лениво размышляю - то ли под новый M-I ("ориентируясь 
> на исходники и уже готовые фичи"), или уж сразу под Dracut. Второе, 
> пожалуй что, получится менее времяёмко и более перспективно.
>

Вот не думаю, что Dracut будет лучше для Альта, тем более, M-I вполне 
интересное решение. В любом случае я просил legion@ смотреть и на 
Dracut, и live-boot из Debian, хотя все они примерно ровесники.


-- 
Best regards,
Leonid Krivoshein.