* [make-initrd] udhcpc script в фиче network @ 2021-09-17 20:48 Leonid Krivoshein 2021-09-17 22:08 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-17 20:48 UTC (permalink / raw) To: make-initrd Алексей, привет! Как ты смотришь на то, чтобы немного расширить список сохраняемых DHCP-опций? Предлагаю наряду с rootpath сохранять siaddr (bootp next server) и wins (list of WINS servers), что позволит задавать на DHCP-сервере опции для сетевой загрузки по протоколам NFS и CIFS. Часть из них уже используется для сетевой загрузки в propagator и alterator-netinst наряду с rootpath. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-17 20:48 [make-initrd] udhcpc script в фиче network Leonid Krivoshein @ 2021-09-17 22:08 ` Alexey Gladkov 2021-09-19 21:50 ` Leonid Krivoshein 2024-03-07 19:18 ` Leonid Krivoshein 0 siblings, 2 replies; 33+ messages in thread From: Alexey Gladkov @ 2021-09-17 22:08 UTC (permalink / raw) To: make-initrd On Fri, Sep 17, 2021 at 11:48:50PM +0300, Leonid Krivoshein wrote: > Алексей, привет! > > > Как ты смотришь на то, чтобы немного расширить список сохраняемых > DHCP-опций? Предлагаю наряду с rootpath сохранять siaddr (bootp next server) > и wins (list of WINS servers), что позволит задавать на DHCP-сервере опции > для сетевой загрузки по протоколам NFS и CIFS. Часть из них уже используется > для сетевой загрузки в propagator и alterator-netinst наряду с rootpath. Я совершенно не против. Я не добавлял ничего другого поскольку не нашёл им применения. Если кому-то нужно больше, то давай добавим больше. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-17 22:08 ` Alexey Gladkov @ 2021-09-19 21:50 ` Leonid Krivoshein 2021-09-21 22:51 ` Leonid Krivoshein 2021-09-22 10:09 ` Alexey Gladkov 2024-03-07 19:18 ` Leonid Krivoshein 1 sibling, 2 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-19 21:50 UTC (permalink / raw) To: make-initrd Привет! 18.09.2021 1:08, Alexey Gladkov пишет: > On Fri, Sep 17, 2021 at 11:48:50PM +0300, Leonid Krivoshein wrote: >> Алексей, привет! >> >> >> Как ты смотришь на то, чтобы немного расширить список сохраняемых >> DHCP-опций? Предлагаю наряду с rootpath сохранять siaddr (bootp next server) >> и wins (list of WINS servers), что позволит задавать на DHCP-сервере опции >> для сетевой загрузки по протоколам NFS и CIFS. Часть из них уже используется >> для сетевой загрузки в propagator и alterator-netinst наряду с rootpath. > Я совершенно не против. Я не добавлял ничего другого поскольку не нашёл им > применения. Если кому-то нужно больше, то давай добавим больше. В тестируемой версии 0.1.5 добавил фичу bootchain-waitnet, в том числе, для исправления ранее найденных проблем, и в ней на ощупь поддержку этих двух полей в надежде, что их же запилим в make-initrd-network: http://git.altlinux.org/people/klark/packages/?p=make-initrd-bootchain.git;a=blob;f=bootchain-waitnet/data/bin/altboot-net-functions;h=16713f3259ec6a816b68c37a19090cf517db7e7a;hb=d9df430030f705d091989e61eaf5d1051cd96e70#l72 -- siaddr и wins. Примеры использования можно увидеть, например, здесь: http://git.altlinux.org/people/klark/packages/?p=make-initrd-bootchain.git;a=blob;f=bootchain-nfs/data/lib/bootchain/nfs;h=e6f4488a4db2a476bb564e1a307aa5e0f9046f44;hb=d9df430030f705d091989e61eaf5d1051cd96e70#l205 http://git.altlinux.org/people/klark/packages/?p=make-initrd-bootchain.git;a=blob;f=bootchain-cifs/data/lib/bootchain/cifs;h=76dd4a4f701444668606f865c4f120d36abeb7a7;hb=d9df430030f705d091989e61eaf5d1051cd96e70#l220 Готовится версия 0.1.6 как артподготовка к netstart, в ней приоритет выбора сервера будет немного другой. Саму фичу netstart надеюсь реализовать в версии 0.1.7. Т.е. это будет мульти-загрузка из stage1 с размещаемых на FTP/HTTP целых ISO-образов. С одной стороны, штука новая по отношению к тому, что умел propagator, с другой -- весьма актуальная для масштабного тестирования на железе сетевой загрузки. А потенциально это ещё и возможность ухода от контейнера ISO в сторону rootfs и отказа от традиционного инсталлятора в пользу развёртывания уже настроенной системы. У netstart не будет своего stage2, но для загружаемых систем он может оверлеить слой с модулями и фирмварью от текущего ядра. bootchain-waitnet -- компромиссная связка фичи make-initrd-network с altboot. Сеть конфигурируется в make-initrd через /proc/cmdline, диалогов конфигурирования сети пока нет, есть только диалоги вывода ошибок. Сделать диалоги конфигурирования сети, наверное, можно. Вопрос в том, как заставить снова запуститься network-up и как отлаживать это хозяйство в rdshell, учитывая, что с ним сеть не конфигурируется. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-19 21:50 ` Leonid Krivoshein @ 2021-09-21 22:51 ` Leonid Krivoshein 2021-09-22 0:16 ` Leonid Krivoshein 2021-09-22 10:01 ` Alexey Gladkov 2021-09-22 10:09 ` Alexey Gladkov 1 sibling, 2 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-21 22:51 UTC (permalink / raw) To: make-initrd Алексей, привет! 20.09.2021 0:50, Leonid Krivoshein пишет: > Вопрос в том, как заставить снова запуститься network-up Никак без тебя этот вопрос не решается! Что я делаю не так? Если вижу, что все четыре переменные равны нулю (IP, NAMESERVER, IFNAME, ROUTE), делаю примерно следующее: ( echo 'export IP="1"' echo 'export ROUTE="0"' echo 'export IFNAME="0"' echo 'export NAMESERVER="0"' echo 'export IP0="dhcp4"' ) >> /.initrd/initenv ( run /lib/initrd/cmdline.d/network run /etc/rc.d/init.d/network-up start ) >/dev/tty1 & а далее идёт код, который ждёт появления IP на любом интерфейсе, кроме lo, и это уже проверенный, рабочий фрагмент. То есть, я хочу повторно запустить конфигурирование и поднятие сети через фичу network, если никакие параметры в /proc/cmdline не были определены. В логе на tty3 вижу следующее: waitnet: [0] RUN: /lib/initrd/cmdline.d/network waitnet: [0] RUN: /etc/rc.d/init.d/network-up start waitnet: connection timeout (последнее сообщение спустя 30 секунд). При этом на tty1 последние строки выглядят так: Network up (lo): [DONE] Starting bootchained service: [DONE] Generating network configuration: [DONE] Network up (lo): [DONE] Больше ничего про сеть нет, в отличии от ситуации, когда я её конфигурирую руками через /proc/cmdline. > и как отлаживать это хозяйство в rdshell, учитывая, что с ним сеть не > конфигурируется. Пробовал выставлять RDSHELL= и комментировать фрагмент его проверки, но тогда network-up просто виснет (видимо на взаимной блокировке /dev/console). -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-21 22:51 ` Leonid Krivoshein @ 2021-09-22 0:16 ` Leonid Krivoshein 2021-09-22 10:01 ` Alexey Gladkov 1 sibling, 0 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-22 0:16 UTC (permalink / raw) To: make-initrd 22.09.2021 1:51, Leonid Krivoshein пишет: > Алексей, привет! > > > 20.09.2021 0:50, Leonid Krivoshein пишет: >> Вопрос в том, как заставить снова запуститься network-up > > Никак без тебя этот вопрос не решается! Что я делаю не так? > > Если вижу, что все четыре переменные равны нулю (IP, NAMESERVER, > IFNAME, ROUTE), делаю примерно следующее: > > ( echo 'export IP="1"' > echo 'export ROUTE="0"' > echo 'export IFNAME="0"' > echo 'export NAMESERVER="0"' > echo 'export IP0="dhcp4"' > ) >> /.initrd/initenv > Добавил в этом месте: run udevadm trigger --type=devices --action=add >/dev/null и загрузка стала "проскакивать со свистом" :-) Вот только я не уверен в правильности такого решения. Рейсы неизбежны в этот момент, так как самое начало загрузки. Как я понимаю, загвоздка в том, что ранее не отрабатывал /lib/uevent/handlers/network/400-network, а есть ли способ заставить эти скрипты отрабатывать "на холодную" по уже появившимся в sysfs интерейсам? > ( run /lib/initrd/cmdline.d/network > run /etc/rc.d/init.d/network-up start > ) >/dev/tty1 & > > а далее идёт код, который ждёт появления IP на любом интерфейсе, кроме > lo, и это уже проверенный, рабочий фрагмент. То есть, я хочу повторно > запустить конфигурирование и поднятие сети через фичу network, если > никакие параметры в /proc/cmdline не были определены. В логе на tty3 > вижу следующее: > > waitnet: [0] RUN: /lib/initrd/cmdline.d/network > waitnet: [0] RUN: /etc/rc.d/init.d/network-up start > waitnet: connection timeout > > (последнее сообщение спустя 30 секунд). При этом на tty1 последние > строки выглядят так: > > Network up (lo): [DONE] > Starting bootchained service: [DONE] > Generating network configuration: [DONE] > Network up (lo): [DONE] > > Больше ничего про сеть нет, в отличии от ситуации, когда я её > конфигурирую руками через /proc/cmdline. > > >> и как отлаживать это хозяйство в rdshell, учитывая, что с ним сеть не >> конфигурируется. > > Пробовал выставлять RDSHELL= и комментировать фрагмент его проверки, > но тогда network-up просто виснет (видимо на взаимной блокировке > /dev/console). > -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-21 22:51 ` Leonid Krivoshein 2021-09-22 0:16 ` Leonid Krivoshein @ 2021-09-22 10:01 ` Alexey Gladkov 1 sibling, 0 replies; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 10:01 UTC (permalink / raw) To: make-initrd On Wed, Sep 22, 2021 at 01:51:20AM +0300, Leonid Krivoshein wrote: > Алексей, привет! > > > 20.09.2021 0:50, Leonid Krivoshein пишет: > > Вопрос в том, как заставить снова запуститься network-up > > Никак без тебя этот вопрос не решается! Что я делаю не так? > > Если вижу, что все четыре переменные равны нулю (IP, NAMESERVER, IFNAME, > ROUTE), делаю примерно следующее: > > ( echo 'export IP="1"' > echo 'export ROUTE="0"' > echo 'export IFNAME="0"' > echo 'export NAMESERVER="0"' > echo 'export IP0="dhcp4"' > ) >> /.initrd/initenv > > ( run /lib/initrd/cmdline.d/network > run /etc/rc.d/init.d/network-up start > ) >/dev/tty1 & Что за ужас ты делаешь ? Речь в начале была про добавление дополнительных переменных в udhcpc, а это уже ну совсем не про это. > а далее идёт код, который ждёт появления IP на любом интерфейсе, кроме lo, и > это уже проверенный, рабочий фрагмент. То есть, я хочу повторно запустить > конфигурирование и поднятие сети через фичу network, если никакие параметры > в /proc/cmdline не были определены. В логе на tty3 вижу следующее: > > waitnet: [0] RUN: /lib/initrd/cmdline.d/network > waitnet: [0] RUN: /etc/rc.d/init.d/network-up start > waitnet: connection timeout > > (последнее сообщение спустя 30 секунд). При этом на tty1 последние строки > выглядят так: > > Network up (lo): [DONE] > Starting bootchained service: [DONE] > Generating network configuration: [DONE] > Network up (lo): [DONE] > > Больше ничего про сеть нет, в отличии от ситуации, когда я её конфигурирую > руками через /proc/cmdline. > > > > и как отлаживать это хозяйство в rdshell, учитывая, что с ним сеть не > > конфигурируется. > > Пробовал выставлять RDSHELL= и комментировать фрагмент его проверки, но > тогда network-up просто виснет (видимо на взаимной блокировке /dev/console). > > > -- > Best regards, > Leonid Krivoshein. > > _______________________________________________ > Make-initrd mailing list > Make-initrd@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/make-initrd -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-19 21:50 ` Leonid Krivoshein 2021-09-21 22:51 ` Leonid Krivoshein @ 2021-09-22 10:09 ` Alexey Gladkov 2021-09-22 10:56 ` Leonid Krivoshein 1 sibling, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 10:09 UTC (permalink / raw) To: make-initrd On Mon, Sep 20, 2021 at 12:50:33AM +0300, Leonid Krivoshein wrote: > Вопрос в том, как заставить > снова запуститься network-up и как отлаживать это хозяйство в rdshell, > учитывая, что с ним сеть не конфигурируется. Зачем его перезапускать ? network-up в цикле проверяет все ли /sys/class/net/*, которые имеют конфигурацию, перешли в состояние online. Если в процессе ожидания появится новая конфигурация, то она также подхватится. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 10:09 ` Alexey Gladkov @ 2021-09-22 10:56 ` Leonid Krivoshein 2021-09-22 11:41 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-22 10:56 UTC (permalink / raw) To: make-initrd 22.09.2021 13:09, Alexey Gladkov пишет: > On Mon, Sep 20, 2021 at 12:50:33AM +0300, Leonid Krivoshein wrote: >> Вопрос в том, как заставить >> снова запуститься network-up и как отлаживать это хозяйство в rdshell, >> учитывая, что с ним сеть не конфигурируется. > Зачем его перезапускать ? > > network-up в цикле проверяет все ли /sys/class/net/*, которые имеют > конфигурацию, перешли в состояние online. > > Если в процессе ожидания появится новая конфигурация, то она также > подхватится. Тогда как сделать так, чтобы появилась новая конфигурация? Вот ничего из 4х переменных пользователь не передал через /proc/cmdline. Допустим, я сделал диалог, в котором он настраивает сеть руками. Как новые настройки должны попасть в фичу network, чтобы она их применила? -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 10:56 ` Leonid Krivoshein @ 2021-09-22 11:41 ` Alexey Gladkov 2021-09-22 12:06 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 11:41 UTC (permalink / raw) To: make-initrd On Wed, Sep 22, 2021 at 01:56:11PM +0300, Leonid Krivoshein wrote: > > > 22.09.2021 13:09, Alexey Gladkov пишет: > > On Mon, Sep 20, 2021 at 12:50:33AM +0300, Leonid Krivoshein wrote: > > > Вопрос в том, как заставить > > > снова запуститься network-up и как отлаживать это хозяйство в rdshell, > > > учитывая, что с ним сеть не конфигурируется. > > Зачем его перезапускать ? > > > > network-up в цикле проверяет все ли /sys/class/net/*, которые имеют > > конфигурацию, перешли в состояние online. > > > > Если в процессе ожидания появится новая конфигурация, то она также > > подхватится. > > Тогда как сделать так, чтобы появилась новая конфигурация? > > Вот ничего из 4х переменных пользователь не передал через /proc/cmdline. > Допустим, я сделал диалог, в котором он настраивает сеть руками. Как новые > настройки должны попасть в фичу network, чтобы она их применила? Без параметра в /proc/cmdline мне кажется всё-таки не обойтись до тех пор пока не открыли телепатию. Можно добавить параметр network=ask и при его присутствии можно спрашивать о конфигурации у пользователя. Код для конфигурации интерфейса есть тут: features/network/data/lib/initrd/cmdline.d/network -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 11:41 ` Alexey Gladkov @ 2021-09-22 12:06 ` Leonid Krivoshein 2021-09-22 13:08 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-22 12:06 UTC (permalink / raw) To: make-initrd 22.09.2021 14:41, Alexey Gladkov пишет: > On Wed, Sep 22, 2021 at 01:56:11PM +0300, Leonid Krivoshein wrote: >> 22.09.2021 13:09, Alexey Gladkov пишет: >>> On Mon, Sep 20, 2021 at 12:50:33AM +0300, Leonid Krivoshein wrote: >>>> Вопрос в том, как заставить >>>> снова запуститься network-up и как отлаживать это хозяйство в rdshell, >>>> учитывая, что с ним сеть не конфигурируется. >>> Зачем его перезапускать ? >>> >>> network-up в цикле проверяет все ли /sys/class/net/*, которые имеют >>> конфигурацию, перешли в состояние online. >>> >>> Если в процессе ожидания появится новая конфигурация, то она также >>> подхватится. >> Тогда как сделать так, чтобы появилась новая конфигурация? >> >> Вот ничего из 4х переменных пользователь не передал через /proc/cmdline. >> Допустим, я сделал диалог, в котором он настраивает сеть руками. Как новые >> настройки должны попасть в фичу network, чтобы она их применила? > Без параметра в /proc/cmdline мне кажется всё-таки не обойтись до тех пор > пока не открыли телепатию. > > Можно добавить параметр network=ask и при его присутствии можно спрашивать > о конфигурации у пользователя. > > Код для конфигурации интерфейса есть тут: > > features/network/data/lib/initrd/cmdline.d/network У меня вчера всё же получилось добиться желаемого, вот фрагмент: # No network settings if [ "${IP:-0}" = 0 ] && [ "${ROUTE:-0}" = 0 ] && [ "${IFNAME:-0}" = 0 ] && [ "${NAMESERVER:-0}" = 0 ] then msg="network settings not defined in /proc/cmdline" if [ -n "${RDSHELL-}" ]; then [ -z "$NOASKUSER" ] || fatal "$msg, dialogs are disabled" message "$msg" msg="N${msg:1}. Try with the option 'ip=dhcp4' after reboot." IM_errmsg "$msg $BC_RBMSG" bc_reboot fi message "$msg" ( echo 'export IP="1"' echo 'export ROUTE="0"' echo 'export IFNAME="0"' echo 'export NAMESERVER="0"' echo 'export IP0="dhcp4"' ) >> /.initrd/initenv ( # shellcheck disable=SC2012 for netdev in $(ls /sys/class/net/) lo; do [ "$netdev" != lo ] || continue [ -r "/sys/class/net/$netdev/flags" ] || continue ACTION="add" INTERFACE="$netdev" /lib/uevent/filters/network done /lib/initrd/cmdline.d/network ) >/dev/null 2>&1 & fi Это упрощённый вариант без диалогов. Если не указать ничего в /proc/cmdline, пытаемся найти интерфейсы и сконфигурировать их по DHCPv4. Код работает нормально, но есть один сторонний эффект. Не могу объяснить причину. При загрузке больших ISO-шников с mirror.yandex.ru по http всё ОК. При загрузке их же по ftp, первое обращение с получением размера файла проходит успешно, а на втором обращении (непосредственно скачивание образа) curl возвращает 7. Если тут же запустить скачивание повторно (нажать в форме ENTER, не меняя адресов), скачивание со второй попытки проходит успешно. Этого стороннего эффекта не возникает, если в /proc/cmdline добавить ip=dhcp4, я это воспроизводил многократно. Т.е. мой код, хоть и работает, не совсем правильно, ошибка точно связана с этим фрагментом. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 12:06 ` Leonid Krivoshein @ 2021-09-22 13:08 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 13:08 UTC (permalink / raw) To: make-initrd On Wed, Sep 22, 2021 at 03:06:37PM +0300, Leonid Krivoshein wrote: > > Без параметра в /proc/cmdline мне кажется всё-таки не обойтись до тех пор > > пока не открыли телепатию. > > > > Можно добавить параметр network=ask и при его присутствии можно спрашивать > > о конфигурации у пользователя. > > > > Код для конфигурации интерфейса есть тут: > > > > features/network/data/lib/initrd/cmdline.d/network > > У меня вчера всё же получилось добиться желаемого, вот фрагмент: Этот код вызывает у меня массу вопросов )) > # No network settings > if [ "${IP:-0}" = 0 ] && > [ "${ROUTE:-0}" = 0 ] && > [ "${IFNAME:-0}" = 0 ] && > [ "${NAMESERVER:-0}" = 0 ] > then > msg="network settings not defined in /proc/cmdline" > > if [ -n "${RDSHELL-}" ]; then > [ -z "$NOASKUSER" ] || > fatal "$msg, dialogs are disabled" > message "$msg" > msg="N${msg:1}. Try with the option 'ip=dhcp4' after > reboot." > IM_errmsg "$msg $BC_RBMSG" > bc_reboot > fi > > message "$msg" > > ( echo 'export IP="1"' > echo 'export ROUTE="0"' > echo 'export IFNAME="0"' > echo 'export NAMESERVER="0"' > echo 'export IP0="dhcp4"' > ) >> /.initrd/initenv Это довольно смелое предположение что когда тебя не просят конфигурировать сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4. subshell тут совершенно не нужен. Он только замедляет код. > ( # shellcheck disable=SC2012 > for netdev in $(ls /sys/class/net/) lo; do > [ "$netdev" != lo ] || > continue > [ -r "/sys/class/net/$netdev/flags" ] || > continue > ACTION="add" INTERFACE="$netdev" /lib/uevent/filters/network > done > > /lib/initrd/cmdline.d/network > ) >/dev/null 2>&1 & А вот тут почему-то всё сделано в обратном порядке. Ты сначала триггеришь эвент по интерфейсу, а потом генерируешь конфигурацию для интерфейса. Да ещё и фоне это происходит. /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего это этого subshell. Он генерирует конфигурацию для всех интерфейсов. Перед этим стоит остановить udev поскольку cmdline.d/network дописывает /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там всё правильно. Скорее всего нужно переделывать работу с 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network несколько раз. Также перед запуском cmdline.d/network нужно удалить старую конфигурацию! После его выполнения можно выполнить /lib/uevent/filters/network, но не таким образом как сделано тут. echo add > /sys/class/net/$netdev/uevent > fi > > Это упрощённый вариант без диалогов. Если не указать ничего в /proc/cmdline, > пытаемся найти интерфейсы и сконфигурировать их по DHCPv4. Код работает > нормально, но есть один сторонний эффект. Не могу объяснить причину. При > загрузке больших ISO-шников с mirror.yandex.ru по http всё ОК. При загрузке > их же по ftp, первое обращение с получением размера файла проходит успешно, > а на втором обращении (непосредственно скачивание образа) curl возвращает 7. > Если тут же запустить скачивание повторно (нажать в форме ENTER, не меняя > адресов), скачивание со второй попытки проходит успешно. Этого стороннего > эффекта не возникает, если в /proc/cmdline добавить ip=dhcp4, я это > воспроизводил многократно. Т.е. мой код, хоть и работает, не совсем > правильно, ошибка точно связана с этим фрагментом. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <bbbe18f3-2ce6-ed0c-d7b4-61090c6ba955@gmail.com>]
* Re: [make-initrd] udhcpc script в фиче network @ 2021-09-22 14:46 ` Alexey Gladkov 2021-09-22 16:12 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 14:46 UTC (permalink / raw) To: make-initrd On Wed, Sep 22, 2021 at 04:50:57PM +0300, Leonid Krivoshein wrote: > > 22.09.2021 16:08, Alexey Gladkov пишет: > > On Wed, Sep 22, 2021 at 03:06:37PM +0300, Leonid Krivoshein wrote: > > > > Без параметра в /proc/cmdline мне кажется всё-таки не обойтись до тех пор > > > > пока не открыли телепатию. > > > > > > > > Можно добавить параметр network=ask и при его присутствии можно спрашивать > > > > о конфигурации у пользователя. > > > > > > > > Код для конфигурации интерфейса есть тут: > > > > > > > > features/network/data/lib/initrd/cmdline.d/network > > > У меня вчера всё же получилось добиться желаемого, вот фрагмент: > > Этот код вызывает у меня массу вопросов )) > > > > > # No network settings > > > if [ "${IP:-0}" = 0 ] && > > > [ "${ROUTE:-0}" = 0 ] && > > > [ "${IFNAME:-0}" = 0 ] && > > > [ "${NAMESERVER:-0}" = 0 ] > > > then > > > msg="network settings not defined in /proc/cmdline" > > > > > > if [ -n "${RDSHELL-}" ]; then > > > [ -z "$NOASKUSER" ] || > > > fatal "$msg, dialogs are disabled" > > > message "$msg" > > > msg="N${msg:1}. Try with the option 'ip=dhcp4' after > > > reboot." > > > IM_errmsg "$msg $BC_RBMSG" > > > bc_reboot > > > fi > > > > > > message "$msg" > > > > > > ( echo 'export IP="1"' > > > echo 'export ROUTE="0"' > > > echo 'export IFNAME="0"' > > > echo 'export NAMESERVER="0"' > > > echo 'export IP0="dhcp4"' > > > ) >> /.initrd/initenv > > Это довольно смелое предположение что когда тебя не просят конфигурировать > > сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4. > > Прилагаю скриншот, по которому станет понятно происходящее. Тут пользователь > явно намерен загрузить конкретный образ по FTP и указывает ip=dhcp4 в > /proc/cmdline. Но он мог забыть указать ip=..., а мог вообще не лезть в > /proc/cmdline или выбрать метод в меню "на лету". Главная подоплёка в том, > что если сетевых настроек нет, хорошо бы их спрашивать. Ну, потому что без > сети с выбранным методом иначе не загрузиться. Сейчас код более простой. > Возможно, тут стоит выводить диалоги. Но вопрос в последующем применении > новых настроек. Весь вот этот автоугадав и домысливание должно происходить после сервиса cmdline. Или же даже проще - до сервиса udev. В этом случае вся конфигурация будет готова и не будет никаких гонок. Вообще почти все диалоги с уточнением конфигурации должны быть тут т.е. до udevd и pipelined. > Для altboot пока что не имеет значения, что make-initrd умеет работать с > IPv6. В нём просто нет пока его поддержки, как и в пропагаторе. Если > указывать ip=dhcp, сеть поднимается дольше. Поддержку IPv6 можно будет > добавить позже... Я считаю, что в 2021 уже не нужно говорить о поддержке IPv6 в новом коде. Нужно просто считать, что он есть. Для того чтобы в пустую не ждать есть функции ipv4_enabled/ipv6_enabled. Кстати, IPv4 в современном мире может быть выключен и это стоит учитывать. > > subshell тут совершенно не нужен. Он только замедляет код. > > Просто хотелось бы перенаправлять вывод в этом месте. { echo; echo; } > /path/to/file > > /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего > > это этого subshell. Он генерирует конфигурацию для всех интерфейсов. > > Но он уже один раз выполнился до входа в bootchain-waitnet, при этом был > сконфигурирован только "lo". lo всегда есть. Он даже не конфигурируется: features/network/data/etc/network/ifaces/lo/ipv4address Зоркий глаз может заметить, что формат конфигов очень похож на etcnet ;) > > Перед этим стоит остановить udev поскольку cmdline.d/network дописывает > > /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там > > всё правильно. Скорее всего нужно переделывать работу с > > 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network > > несколько раз. > > Про это и близкое по теме, надеюсь, Антон скоро ещё напишет. Со своей > стороны добавлю, что: > > 1) IFNAME -- ужасно полезная фича, особенно для сетевых стендов с iPXE, т.к. > при зоопарке интерфейсов позволяет средствами самого загрузчика указать, с > какого интерфейса мы загрузились. > 2) IFNAME -- должен отрабатывать один раз, конечно, поэтому мне жалко > удалять всю конфигурацию. :-) Поэтому я её и добавил )) > > Также перед запуском cmdline.d/network нужно удалить старую конфигурацию! > > А как это правильно сделать? rm -rf -- "$net_autoconfdir" "$net_statedir" ? cmdline.d/network кладёт всё сюда: "$net_confdir/ifaces/$interface" "$net_confdir/default" net_autoconfdir -- это место, куда кладут конфигурацию dhcp. Они отделены от системной конфигурации, чтобы они не смешивались. В некоторых случаях это нужно. Для каждого интерфейса параметры могут приехать из: net_autoconfdir/ifaces/$NET_IF/* net_confdir/ifaces/$NET_IF/* net_confdir/default/* net_statedir -- это результат объединения всех. Это стейт. Наверно, стоит написать отдельную функцию, чтобы "забыть" конфигурацию интерфейса. > Есть и другой вопрос и даже аналогия. При создании форка pipeline/waitdev > было понятно, что альтернативой ожидания устройств по uevent при ручном > выборе с диалогами может быть только методика сканирования уже найденных > устройств. Шаг localdev может схватить то, что ранее было найдено шагом > слева waitdev. Но если там нет устройства, он выполняет сканирование, он > использует таймауты, итд. С сетью в этом месте, мне кажется, всё должно быть > так же, Если всю конфигурацию делать до pipelined, то waitnet сведётся к функционалу сервиса network-up. Ну или же к ожиданию /.initrd/online/$NET_IF если мы знаем какой интерфейс должен использоваться. > но я не рискнул писать развесистую логику, а решил использовать > готовую фичу. При этом возникает риск гонок: самое начало загрузки, модуль > сетевой карты мог ещё не подгрузиться, сеть заранее никто не > сконфигурировал, а тут я пытаюсь что-то перезапускать... Гонки с загрузкой модулей неприятные, да. Тут может быть такая эвристика: мы догадались, что нужна сеть, ни одного интерфейса нет (кроме lo)? значит ждём появления сетевого интерфейса. Будет другая проблема если интерфейсы будут появляться сильно не сразу, но это уже следующая проблема. > Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у > нас снимется много вопросов о том, как интегрировать bootchain/interactive с > уже имеющимися фичами make-initrd. Будет хороший пример, как это можно > сделать. То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я не против). -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 14:46 ` Alexey Gladkov @ 2021-09-22 16:12 ` Leonid Krivoshein 2021-09-22 19:03 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-22 16:12 UTC (permalink / raw) To: make-initrd 22.09.2021 17:46, Alexey Gladkov пишет: > On Wed, Sep 22, 2021 at 04:50:57PM +0300, Leonid Krivoshein wrote: >> 22.09.2021 16:08, Alexey Gladkov пишет: >>> [...] >>> Это довольно смелое предположение что когда тебя не просят конфигурировать >>> сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4. >> [...] Главная подоплёка в том, >> что если сетевых настроек нет, хорошо бы их спрашивать. Ну, потому что без >> сети с выбранным методом иначе не загрузиться. Сейчас код более простой. >> Возможно, тут стоит выводить диалоги. Но вопрос в последующем применении >> новых настроек. > Весь вот этот автоугадав и домысливание должно происходить после сервиса > cmdline. Или же даже проще - до сервиса udev. В этом случае вся > конфигурация будет готова и не будет никаких гонок. > > Вообще почти все диалоги с уточнением конфигурации должны быть тут т.е. до > udevd и pipelined. Сначала ужаснулся от мысли о необходимости разделения bootchain на две части -- диалоговую для выяснения конфигурации и ту, что работает сейчас после udev. Конечно, нет ничего невозможного, так работают многие инсталляторы, сначала задавая вопросы, а потом выполняют действия по уже подготовленным ответам. Но... не получится! Так как есть диалоги, которые предлагают выбор определённого оборудования, а для его определения нужен udev. И ещё мы можем всегда вернутся в самое начало. Плюс те диалоги, когда в процессе выполнения что-то пошло не так, тут тоже могут быть варианты. Немыслимо организовать связку между этими двумя частями, когда посредине будет запуск udev. Поэтому я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах после запуска udev то, что не было сконфигурировано в командой строке, на худой конец, прибегать к технике повторного сканирования, реализованной в пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev. >> Для altboot пока что не имеет значения, что make-initrd умеет работать с >> IPv6. В нём просто нет пока его поддержки, как и в пропагаторе. Если >> указывать ip=dhcp, сеть поднимается дольше. Поддержку IPv6 можно будет >> добавить позже... > Я считаю, что в 2021 уже не нужно говорить о поддержке IPv6 в новом коде. > Нужно просто считать, что он есть. > > Для того чтобы в пустую не ждать есть функции ipv4_enabled/ipv6_enabled. > Кстати, IPv4 в современном мире может быть выключен и это стоит учитывать. Это очень правильное замечание, я даже и не сомневался, что это так. Мало того, я уверен, что добавить поддержку IPv6 в altboot до безобразия просто. Но лично я мало что понимаю в IPv6, так что если кто-то поможет заменить вызовы resolve на resolve6 и ss в паре мест, буду признателен. Так, конечно, основная поддержка сети IPv6 уже есть в самом make-initrd и грех её не использовать. И основное тут даже не код, а тестирование -- я это не смогу проверить как следует. > [...] >>> /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего >>> это этого subshell. Он генерирует конфигурацию для всех интерфейсов. >> Но он уже один раз выполнился до входа в bootchain-waitnet, при этом был >> сконфигурирован только "lo". > lo всегда есть. Он даже не конфигурируется: > > features/network/data/etc/network/ifaces/lo/ipv4address > > Зоркий глаз может заметить, что формат конфигов очень похож на etcnet ;) Да, я заметил, как и разницу. Мне показалось странным, зачем при авто-конфигурировании сохранять не полученные значения, а некие строки типа "nameserver <value1> <value2>" или "defult via <value>", ведь их же потом неудобно будет парсить. Но видимо так задумано, чтобы читать потом всю конфигурацию в едином формате. Если сравнивать фичу network с etcnet из stage2, то у меня возникает два недоумения... )) 1. Зачем такой навороченный network в stage1? Ведь для сетевой загрузки нужен только один интерфейс. 2. С другой стороны, etcnet умеет vlan'ы, bond'ы и много чего, а network сейчас непригоден для загрузки через такое, а значит придётся менять конфигурацию на свичах или использовать отдельную сеть только для сетевой загрузки. >>> Перед этим стоит остановить udev А как это правильнее сделать? И не лучше ли тогда, не останавливая udev, заставить его перечитать правила? >>> поскольку cmdline.d/network дописывает >>> /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там >>> всё правильно. Скорее всего нужно переделывать работу с >>> 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network >>> несколько раз. Насчёт этого я думаю, что можно вообще не беспокоиться, т.к. если IFNAME был синтаксически правильно определён в /proc/cmdline и udev-правило уже отработало один раз, то интерфейс с нужным именем уже появился и повторная обработка IFNAME не требуется, диалогов для этого не предполагается. >> [...] >> 2) IFNAME -- должен отрабатывать один раз, конечно, поэтому мне жалко >> удалять всю конфигурацию. :-) ...а значит и удаление всей конфигурации не должно отрицательно сказаться на повторном конфигурировании, которое не предусматривает диалогового аналога IFNAME=..., либо я чего-то не учитываю? >>> Также перед запуском cmdline.d/network нужно удалить старую конфигурацию! >> А как это правильно сделать? rm -rf -- "$net_autoconfdir" "$net_statedir" ? > cmdline.d/network кладёт всё сюда: > > "$net_confdir/ifaces/$interface" > "$net_confdir/default" > > net_autoconfdir -- это место, куда кладут конфигурацию dhcp. Они отделены > от системной конфигурации, чтобы они не смешивались. В некоторых случаях > это нужно. > > Для каждого интерфейса параметры могут приехать из: > > net_autoconfdir/ifaces/$NET_IF/* > net_confdir/ifaces/$NET_IF/* > net_confdir/default/* > > net_statedir -- это результат объединения всех. Это стейт. > > Наверно, стоит написать отдельную функцию, чтобы "забыть" конфигурацию > интерфейса. Тогда уж лучше научить cmdline.d/network повторно конфигурировать все интерфейсы, чтобы он сам удалял то, что было раньше. :-) > [...] >> но я не рискнул писать развесистую логику, а решил использовать >> готовую фичу. При этом возникает риск гонок: самое начало загрузки, модуль >> сетевой карты мог ещё не подгрузиться, сеть заранее никто не >> сконфигурировал, а тут я пытаюсь что-то перезапускать... > Гонки с загрузкой модулей неприятные, да. Тут может быть такая эвристика: > мы догадались, что нужна сеть, ни одного интерфейса нет (кроме lo)? значит > ждём появления сетевого интерфейса. > > Будет другая проблема если интерфейсы будут появляться сильно не сразу, но > это уже следующая проблема. Потому я и пытаюсь пристроиться к имеющейся фиче network очень аккуратно. Следом за приведённым фрагментом идёт код, который просто ждёт появления хоть какого-то реального интерфейса. В финальном же варианте идеал мне видится таким: конфигурирование сети через диалоги, если определённая конфигурация не даёт полного представления о единственном сетевом интерфейсе. В ранних исталляторах (не альтовых) я видел, что до диалогов настройки сети предпринимаются попытки сконфигурировать сеть по DHCP. Не уверен, что это плохая идея, потому что лишние диалоги на этапе загрузки -- зло, а когда ещё не работает мышь/клавиатура -- даже вредительство. :-) >> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >> сделать. > То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я > не против). Нет, наоборот, диалоги же как раз по моей части: https://lists.altlinux.org/pipermail/devel/2018-April/204192.html :-) -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 16:12 ` Leonid Krivoshein @ 2021-09-22 19:03 ` Alexey Gladkov 2021-09-22 22:06 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-22 19:03 UTC (permalink / raw) To: make-initrd On Wed, Sep 22, 2021 at 07:12:06PM +0300, Leonid Krivoshein wrote: > > 22.09.2021 17:46, Alexey Gladkov пишет: > > On Wed, Sep 22, 2021 at 04:50:57PM +0300, Leonid Krivoshein wrote: > > > 22.09.2021 16:08, Alexey Gladkov пишет: > > > > [...] > > > > Это довольно смелое предположение что когда тебя не просят конфигурировать > > > > сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4. > > > [...] Главная подоплёка в том, > > > что если сетевых настроек нет, хорошо бы их спрашивать. Ну, потому что без > > > сети с выбранным методом иначе не загрузиться. Сейчас код более простой. > > > Возможно, тут стоит выводить диалоги. Но вопрос в последующем применении > > > новых настроек. > > Весь вот этот автоугадав и домысливание должно происходить после сервиса > > cmdline. Или же даже проще - до сервиса udev. В этом случае вся > > конфигурация будет готова и не будет никаких гонок. > > > > Вообще почти все диалоги с уточнением конфигурации должны быть тут т.е. до > > udevd и pipelined. > > Сначала ужаснулся от мысли о необходимости разделения bootchain на две части > -- диалоговую для выяснения конфигурации и ту, что работает сейчас после > udev. Конечно, нет ничего невозможного, так работают многие инсталляторы, > сначала задавая вопросы, а потом выполняют действия по уже подготовленным > ответам. Но... не получится! Так как есть диалоги, которые предлагают выбор > определённого оборудования, а для его определения нужен udev. И ещё мы можем > всегда вернутся в самое начало. Плюс те диалоги, когда в процессе выполнения > что-то пошло не так, тут тоже могут быть варианты. Немыслимо организовать > связку между этими двумя частями, когда посредине будет запуск udev. Поэтому > я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах > после запуска udev то, что не было сконфигурировано в командой строке, на > худой конец, прибегать к технике повторного сканирования, реализованной в > пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev. А то что хочешь делать ты не ложится в текущую архитектуру. Во многих местах код рассчитывает, что конфигурация уже задана. Настройка сети одно из таких мест. Эвенты от интерфейса будут проигнорированы если нет конфигурации. То есть придётся понимать такую ситуацию и ставить очередь network на паузу в ueventd. Это решит одну проблему, но все. Если ты хочешь вернуться в начало, то нужно будет уметь откатываться на исходное состояние и начинать с начала. К этому некоторый код вообще не готов. Начало происходить то чего я опасался. Ты где-то отдельно пишешь код вместо того чтобы обсуждать и порциями добавлять. В итоге ты уверенно движешься к форку уже самого make-initrd (именно это ты и делаешь, поверь). Ты уже спроектировал и реализовал свою систему так с чем я не могу согласиться. И я до сих пор не видел ни одного патча. Поэтому для меня каждая твоя проблема является большим сюрпризом. > > > > /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего > > > > это этого subshell. Он генерирует конфигурацию для всех интерфейсов. > > > Но он уже один раз выполнился до входа в bootchain-waitnet, при этом был > > > сконфигурирован только "lo". > > lo всегда есть. Он даже не конфигурируется: > > > > features/network/data/etc/network/ifaces/lo/ipv4address > > > > Зоркий глаз может заметить, что формат конфигов очень похож на etcnet ;) > > Да, я заметил, как и разницу. Мне показалось странным, зачем при > авто-конфигурировании сохранять не полученные значения, а некие строки типа > "nameserver <value1> <value2>" или "defult via <value>", ведь их же потом > неудобно будет парсить. Но видимо так задумано, чтобы читать потом всю > конфигурацию в едином формате. Потому что это не формат, а опции ip. > Если сравнивать фичу network с etcnet из stage2, то у меня возникает два > недоумения... )) > > 1. Зачем такой навороченный network в stage1? Ведь для сетевой загрузки > нужен только один интерфейс. Это малая доля того что реализовано в redhat [1]. Я реализовал, что сходу смог. Не могу сказать, что она навороченная. Большинство рецептов в интернете про redhat (без обид, altlinux) и хорошо бы если бы они работали и в альте. [1] https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_network > 2. С другой стороны, etcnet умеет vlan'ы, bond'ы и много чего, а network > сейчас непригоден для загрузки через такое, а значит придётся менять > конфигурацию на свичах или использовать отдельную сеть только для сетевой > загрузки. etcnet не очень готов работать с busybox. Плюс он работает как чёрный ящик то есть его интерфейс ifup/ifdown. Насчёт vlan и bond: я думал их добавить, но не стал потому что мне сложно это тестировать. Если network не нравится, то можно хоть NetworkManager в образ поместить. Я так пробовал делать если что. > > > > Перед этим стоит остановить udev > > А как это правильнее сделать? И не лучше ли тогда, не останавливая udev, > заставить его перечитать правила? Если переделать работу с 60-persistent-net.rules, то возможно останавливать и не нужно будет. udev перечитывает правила, если они меняются. > > > > поскольку cmdline.d/network дописывает > > > > /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там > > > > всё правильно. Скорее всего нужно переделывать работу с > > > > 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network > > > > несколько раз. > > Насчёт этого я думаю, что можно вообще не беспокоиться, т.к. если IFNAME был > синтаксически правильно определён в /proc/cmdline и udev-правило уже > отработало один раз, то интерфейс с нужным именем уже появился и повторная > обработка IFNAME не требуется, диалогов для этого не предполагается. С каждым перезапуском cmdline.d/network в 60-persistent-net.rules будет всё больше и больше дублирующихся правил. > > > [...] > > > 2) IFNAME -- должен отрабатывать один раз, конечно, поэтому мне жалко > > > удалять всю конфигурацию. :-) > > ...а значит и удаление всей конфигурации не должно отрицательно сказаться на > повторном конфигурировании, которое не предусматривает диалогового аналога > IFNAME=..., либо я чего-то не учитываю? Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp нужно аккуратно остановить. > > > > Также перед запуском cmdline.d/network нужно удалить старую конфигурацию! > > > А как это правильно сделать? rm -rf -- "$net_autoconfdir" "$net_statedir" ? > > cmdline.d/network кладёт всё сюда: > > > > "$net_confdir/ifaces/$interface" > > "$net_confdir/default" > > > > net_autoconfdir -- это место, куда кладут конфигурацию dhcp. Они отделены > > от системной конфигурации, чтобы они не смешивались. В некоторых случаях > > это нужно. > > > > Для каждого интерфейса параметры могут приехать из: > > > > net_autoconfdir/ifaces/$NET_IF/* > > net_confdir/ifaces/$NET_IF/* > > net_confdir/default/* > > > > net_statedir -- это результат объединения всех. Это стейт. > > > > Наверно, стоит написать отдельную функцию, чтобы "забыть" конфигурацию > > интерфейса. > > Тогда уж лучше научить cmdline.d/network повторно конфигурировать все > интерфейсы, чтобы он сам удалял то, что было раньше. :-) Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть путём эмуляции указания /proc/cmdline. > > > [...] > > > но я не рискнул писать развесистую логику, а решил использовать > > > готовую фичу. При этом возникает риск гонок: самое начало загрузки, модуль > > > сетевой карты мог ещё не подгрузиться, сеть заранее никто не > > > сконфигурировал, а тут я пытаюсь что-то перезапускать... > > Гонки с загрузкой модулей неприятные, да. Тут может быть такая эвристика: > > мы догадались, что нужна сеть, ни одного интерфейса нет (кроме lo)? значит > > ждём появления сетевого интерфейса. > > > > Будет другая проблема если интерфейсы будут появляться сильно не сразу, но > > это уже следующая проблема. > > Потому я и пытаюсь пристроиться к имеющейся фиче network очень аккуратно. > Следом за приведённым фрагментом идёт код, который просто ждёт появления > хоть какого-то реального интерфейса. > > В финальном же варианте идеал мне видится таким: конфигурирование сети через > диалоги, если определённая конфигурация не даёт полного представления о > единственном сетевом интерфейсе. В ранних исталляторах (не альтовых) я > видел, что до диалогов настройки сети предпринимаются попытки > сконфигурировать сеть по DHCP. Не уверен, что это плохая идея, потому что > лишние диалоги на этапе загрузки -- зло, а когда ещё не работает > мышь/клавиатура -- даже вредительство. :-) Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны на системном уровне, чтобы весь код был готов к изменению параметров, но почему-то меня не услышали. > > > Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у > > > нас снимется много вопросов о том, как интегрировать bootchain/interactive с > > > уже имеющимися фичами make-initrd. Будет хороший пример, как это можно > > > сделать. > > То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я > > не против). > > Нет, наоборот, диалоги же как раз по моей части: > https://lists.altlinux.org/pipermail/devel/2018-April/204192.html :-) -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 19:03 ` Alexey Gladkov @ 2021-09-22 22:06 ` Leonid Krivoshein 2021-09-23 0:45 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-22 22:06 UTC (permalink / raw) To: make-initrd 22.09.2021 22:03, Alexey Gladkov пишет: > On Wed, Sep 22, 2021 at 07:12:06PM +0300, Leonid Krivoshein wrote: >> [...] Поэтому >> я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах >> после запуска udev то, что не было сконфигурировано в командой строке, на >> худой конец, прибегать к технике повторного сканирования, реализованной в >> пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev. > А то что хочешь делать ты не ложится в текущую архитектуру. Во многих > местах код рассчитывает, что конфигурация уже задана. Настройка сети одно > из таких мест. Эвенты от интерфейса будут проигнорированы если нет > конфигурации. В сегодняшней версии 0.1.5-alt3 эту проблему устранили, благодаря тебе, конечно лучше глянуть код. Уже проверил и скоро выгружу. Теперь сеть идеально взлетает без диалогов и без форка фичи network. Без диалогов -- временная мера, просто сделан задел на будущее. Если сравнивать altboot с propagator, то один из минусов первого -- отсутствие диалогов конфигурирования сети. Но благодаря фиче network в самом make-initrd это можно пережить, хотя лучше, чтобы эти диалоги тоже были. Другой минус, я надеюсь, мы тоже почти преодолели -- он в теме. Теперь все те же опции мы можем брать по протоколу DHCP. А других минусов нет, остаются только плюсы, их становится всё больше. > То есть придётся понимать такую ситуацию и ставить очередь network на > паузу в ueventd. Это решит одну проблему, но все. Как раз я представлял себе работу всего pipeline/bootchain с диалогами, в целом, как полноценную программу, работающую в обычной среде. Мы же не останавливаем в stage2 работающий udev каждый раз, когда нам что-то нужно. Propagator работает параллельно с udev, такое же поведение у altboot. Главное, как мне кажется, это две вещи: make-initrd при root=pipeline/bootchain ни при каких обстоятельствах не должен найти корень раньше, чем ему об этом скажет pipeline/bootchain, какие бы эвенты ему не пришлось параллельно обрабатывать. И второе: код самих pipeline/bootchain/altboot должен быть готовым работать в ситуации готовности к начальной загрузке, чтобы сканировать, ждать, если устройств ещё нет, при этом не создавать рейсов. Тогда эта концепция будет работать. Про диалоги и опции конфигурирования отдельно скажу. > Если ты хочешь вернуться в начало, то нужно будет уметь откатываться на > исходное состояние и начинать с начала. К этому некоторый код вообще не > готов. К этому всегда должен быть готов код в altboot. Сейчас он пишется с таким расчётом. Сеть там просто единожды опрашивается, поднятый интерфейс запоминается. При перезапуске altboot используется ранее созданная конфигурация. Пока так... > Начало происходить то чего я опасался. Не начало и не начнёт. Напротив, ждём не дождёмся, когда это закончится! Вот и Антон Мидюков вчера настаивал, чтобы я приступил к процессу апстрима, т.к. почти все его замечания были устранены, а он проверяет на всех мыслимых кейсах и регулярках, на разных архитектурах. Не начнёт, потому что мне эту ношу не потянуть, я лишь помогу в той части, что обещал, но не более. > Ты где-то отдельно пишешь код Код отправляю пока в Сизиф и в локальную гитовницу: git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > вместо того чтобы обсуждать и порциями добавлять. Если бы работы по обсуждённому ранее плану были завершены, мне бы только и оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам настаивал, чтобы продукт был тщательно проверен до того, как он поедет в апстрим. Находятся замечания, предложения, приходится их устранять и учитывать. А из-за этого у меня откладывается работа по автоматизации тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать очередные регулярки с разными опциями и методами загрузки. Лично мне кажется, что ни один пакет у нас так пристально не проверялся, попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и моя задача учесть совместимость с уже сделанным в Альте за многие годы. > В итоге ты уверенно > движешься к форку уже самого make-initrd (именно это ты и делаешь, > поверь). Поверь, этому не бывать! ;-) > Ты уже спроектировал и реализовал свою систему так с чем я не > могу согласиться. Предлагаю не делать поспешных выводов. Фичи pipeline и network ты спроектировал. propagtor проектировал не я, но мне приходится во многом повторять его и его поведение, при этом я стараюсь не делать форк фич там, где это возможно, мы решаем задачу по избавлению от propagator и запихиванию его функционала в make-initrd. Всё это проделано зря, если вместо propagator предложить в чистом виде pipeline или иную новую концепцию загрузки, которая будет идеальной с точки зрения make-initrd, но непригодной для реального применения без переделки всего остального. Как раз я старался учесть возможность перехода в будущем на более правильные концепции. Но сейчас и тебе надо принять, как данность, что пусть "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был внутри make-initrd и работал как 1/80 часть его рантайма, а не наоборот, чтобы настоящий propagator полностью выкидывал и заменял собой все 100% рантайма make-initrd. Можно и нужно обсуждать, как лучше сделать это, не ломая совместимости, и учитывая потребности перехода на что-то более правильное в перспективе. > И я до сих пор не видел ни одного патча. Поэтому для > меня каждая твоя проблема является большим сюрпризом. Кажется, несколько попыток я уже делал, в частности, отдельно предлагал bootchain-interactive. Но, как я понял, ты хочешь принять всё одним разом, и только после тщательной проверки всей связки. Так мы этой проверкой сейчас занимаемся. После этого мне ещё README для каждой фичи писать и только потом делать коммиты в апстрим -- таков был план. > [...] > Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у > тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp > нужно аккуратно остановить. В текущей простой ситуации, которую нельзя назвать финальным/идеальным вариантом, у пользователя нет шансов что-либо захотеть. :-) http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=5a1a8d2acd09c06d8091b921803850ea313de2ed;hb=9305bcd041b50b018d7fa4c11cebac4123514b26#l24 Т.е. в версии 0.1.5-alt2 тут вообще диалог о том, что "перезагрузись и сконфигурируй сеть через /proc/cmdline". В версии 0.1.5-alt3 этот же диалог и перезагрузка будет только в случае, если недоступен протокол IPv4. > [...] > Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network > не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть > путём эмуляции указания /proc/cmdline. /proc/cmdline удобен тем, что можно что-то подлатать на лету, обойти проблемы, но это не лучшее место для хранения конфигурации. Даже ядерщики дожили до bootconfig. Я понимаю, что когда ты писал код фич, ты не рассчитывал на их повторный запуск. Но как мне быть, если нужно не сконфигурированную фичу сконфигурировать и перезапустить? Не делать же очередной форк! Твоя фича рассчитывает на параметры из /proc/cmdline. А полная совместимость с пропагатором требует другого синтаксиса, который я мог бы расширить. В общем, я прикладываю усилия, чтобы использовать твою готовую фичу. И кажется, это удалось! Я же как раз не хочу делать форк всей или даже части фичи network, хотя и она "часть замены пропагатора", напротив, есть желание пристроится к уже готовому. > [...] > Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны > на системном уровне, чтобы весь код был готов к изменению параметров, но > почему-то меня не услышали. Тебе видней, как это реализовать на системном уровне, разве кто-то будет возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал перетащить на верхний уровень bootchain-interactive. Кстати, только сегодня думал, что может как раз не стоит перетаскивать, а лучше оставить в составе пошаговой загрузки на отдельном терминале. Потому что разные фичи (запущенные демоны) должны выстраиваться в очередь, диалоги не должны мешаться, они не всегда бывают диалогами ввода. Про перевод всех параметров /proc/cmdline в форму диалогов я правда слышу в первый раз. Мне кажется сомнительной такая возможность. Но пристраивание диалогов к имеющимся фичам мы тоже хотели с тобой обсудить и возможно нам сегодня удалось это реализовать, ниже-то речь как раз об этом: >>>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >>>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >>>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >>>> сделать. P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её апстримить. Вот прямо сегодня! :-) А там уже будем обсуждать изменения, необходимые сразу и после апстрима. Я уверен, что хуже от этого никому не станет. Даже если что-то там ещё окажется не идеальным, наличие altboot внутри make-initrd не помешает никому собирать образы с проверенным пропагатором. И никто не заставляет ставить фичи типа make-initrd-bootchain в свою систему. К тому же эта версия последняя, исправляющая замечания, две следующие планировались по "хотелкам", которые можно отложить на полгода. Самое жёсткое пересечение -- это форк фичи pipeline в bootchain, только оно может затронуть нынешних пользователей pipeline, коих не так много. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-22 22:06 ` Leonid Krivoshein @ 2021-09-23 0:45 ` Alexey Gladkov 2021-09-23 2:31 ` Антон Мидюков 2021-09-23 2:40 ` Leonid Krivoshein 0 siblings, 2 replies; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 0:45 UTC (permalink / raw) To: make-initrd On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: > > Ты где-то отдельно пишешь код > > Код отправляю пока в Сизиф и в локальную гитовницу: > > git.altlinux.org/people/klark/packages/make-initrd-bootchain.git Это отдельный репозиторий, делать ревью коммитов непонятно как. git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и патчи в рассылке лучше. Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но проблема в том, что я не представляю как это мерджить поскольку это даже как subtree сделать. Моё предыдущее предложение сделать патчсет уже не актуально в данной ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а остальное мы доработали бы в рабочем порядке. В этом случае все изменения бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. Но ты выбрал иную стратегию. Ты разрабатываешь вещь в себе в отдельном репозитории. Это просто некое отдельное решение на основе make-initrd. Этот репозитории повторяет стратегию make-initrd-propagator, который как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в себе. Новый, правда, интегрирован с основным кодом лучше. > > вместо того чтобы обсуждать и порциями добавлять. > > Если бы работы по обсуждённому ранее плану были завершены, мне бы только и > оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам > настаивал, чтобы продукт был тщательно проверен до того, как он поедет в > апстрим. Находятся замечания, предложения, приходится их устранять и > учитывать. А из-за этого у меня откладывается работа по автоматизации > тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно > работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать > очередные регулярки с разными опциями и методами загрузки. > > Лично мне кажется, что ни один пакет у нас так пристально не проверялся, > попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и > моя задача учесть совместимость с уже сделанным в Альте за многие годы. Я начинаю думать, что уже лучше оставить всё как есть сейчас. Пусть make-initrd-bootchain остаётся отдельным репозиторием и пакетом. Когда в make-initrd будут появляться новые интерфейсы или фичи, то они будут начинать использоваться в make-initrd-bootchain. В том числе, когда какой-то функционал будет переползать в апстрим. Иначе я просто не представляю как всё уже написанное поддерживать. > > Ты уже спроектировал и реализовал свою систему так с чем я не > > могу согласиться. > мы решаем задачу по избавлению от propagator и запихиванию > его функционала в make-initrd. Всё это проделано зря, если вместо propagator > предложить в чистом виде pipeline или иную новую концепцию загрузки, которая > будет идеальной с точки зрения make-initrd Так. Очень интересно, но об этом чуть ниже. > Как раз я старался учесть возможность перехода в будущем на более правильные > концепции. Но сейчас и тебе надо принять, как данность, что пусть > "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был > внутри make-initrd Вот тут ты ошибаешься. Мне не нужно и тебе не советую принимать как данность, что нужно повторять поведение, которое написано в 2004. Это поведение чуть-чуть устарело. Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем его переизобретать. > и работал как 1/80 часть его рантайма, а не наоборот, > чтобы настоящий propagator полностью выкидывал и заменял собой все 100% > рантайма make-initrd. Признаюсь тебе: мне нет дела до propagator. Это древний кусок гов^W кода. Раньше он замечательно работал без make-initrd. Он делает всё сам и своими методами. Считаю ли я, что _функционал_ propagator может быть реализован на make-initrd ? Да. Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. Я считаю, что должна быть сохранена совместимость до определённой степени. Я не считаю, что нужна полная копия поведения. Для последнего у вас есть сам propagator. > Можно и нужно обсуждать, как лучше сделать это, не > ломая совместимости, и учитывая потребности перехода на что-то более > правильное в перспективе. Ты сам себе противоречишь. Я должен принять, как данность функционал пропагатора и не ломая совместимости с кодом 17 летней (на самом деле большей) давности переходить на что-то более правильное. И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить с и переписывать эту "данность" с учётом совместимости буду я ? Отличная перспектива. А давайте сначала вы осознаете, что вам не нужен клон propagator и будете апстримить уже стазу более правильное ? Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на поддержку. > > И я до сих пор не видел ни одного патча. Поэтому для > > меня каждая твоя проблема является большим сюрпризом. > > Кажется, несколько попыток я уже делал, в частности, отдельно предлагал > bootchain-interactive. Патчей или PR так и не было. А каталог bootchain-interactive в упомянутом выше репозитории ничем в make-initrd не используется. Все сообщения make-initrd идут мимо. Кроме того, мы уже обсуждали использование других vt. Я не очень понимаю, что делать с этой фичей в make-initrd-bootchain.git > Но, как я понял, ты хочешь принять всё одним разом, и > только после тщательной проверки всей связки. Так мы этой проверкой сейчас > занимаемся. Я хотел совсем не этого. См. выше. > После этого мне ещё README для каждой фичи писать и только потом > делать коммиты в апстрим -- таков был план. Не. Этот поезд уже ушёл. Превращать репозиторий с историей изменений в некий патчет просто не имеет смысла. > > Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у > > тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp > > нужно аккуратно остановить. > > В текущей простой ситуации, которую нельзя назвать финальным/идеальным > вариантом, у пользователя нет шансов что-либо захотеть. :-) Так это неправильно. Пользователь может такое хотеть. Да и дело не только в dhcp -> static. Нужно уметь расконфигурировать интерфейс. > http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=5a1a8d2acd09c06d8091b921803850ea313de2ed;hb=9305bcd041b50b018d7fa4c11cebac4123514b26#l24 > if [ ! -s /bin/network-sh-functions ]; then В 2.22.0-13-g78001064a я специально реализовал проверку фич о которой мы говорили. > > Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network > > не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть > > путём эмуляции указания /proc/cmdline. > > /proc/cmdline удобен тем, что можно что-то подлатать на лету, подхакать на лету. > Даже ядерщики дожили до bootconfig. Мне кажется ты совсем не понял, зачем они это сделали. > Я понимаю, что когда ты писал код фич, ты не > рассчитывал на их повторный запуск. Но как мне быть, если нужно не > сконфигурированную фичу сконфигурировать и перезапустить? Не делать же > очередной форк! Не нужно форкать. Нужно сформировать конфиги, которые используются кодом. Если код не готов, то нужно предложить патч, который это поправит. > Твоя фича рассчитывает на параметры из /proc/cmdline. Ты не понял мой код. Фича network не рассчитывает на параметры из /proc/cmdline. У неё есть генератор, который преобразует общепринятые параметры [1] в формат своих конфигов. Она вообще может обойтись без этого генератора, если конфигурпцию положить в образ при генерации. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/nfs/nfsroot.rst#n88 > А полная совместимость с пропагатором требует другого синтаксиса А зачем эта совместимость ? Ты пишешь про это как про аксиому. Я не хочу отвлекаться на кулстори, но когда мы с inger@ писали инсталлер, то как-то пережили отсутствие совместимости с mandrake. А тут внезапно появилось желание иметь совместимость с его частью. > > [...] > > Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны > > на системном уровне, чтобы весь код был готов к изменению параметров, но > > почему-то меня не услышали. > > Тебе видней, как это реализовать на системном уровне, разве кто-то будет > возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал > перетащить на верхний уровень bootchain-interactive Я не понял как ты предлагал это перетакивать. Скопировать код в другой репозиторий ? > Кстати, только сегодня > думал, что может как раз не стоит перетаскивать, а лучше оставить в составе > пошаговой загрузки на отдельном терминале. Потому что разные фичи > (запущенные демоны) должны выстраиваться в очередь, диалоги не должны > мешаться, они не всегда бывают диалогами ввода. Я уже выше писал, что начал тоже так думать. Пусть всё это пока живёт в make-initrd-bootchain. > Про перевод всех параметров > /proc/cmdline в форму диалогов я правда слышу в первый раз. Мне кажется > сомнительной такая возможность. Я говорил не про другие параметры /proc/cmdline, а про дополнительную информацию и интерактивщину. Последняя уже есть в fsck и luks. > > > > > Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у > > > > > нас снимется много вопросов о том, как интегрировать bootchain/interactive с > > > > > уже имеющимися фичами make-initrd. Будет хороший пример, как это можно > > > > > сделать. > > P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её > апстримить. Вот прямо сегодня! :-) Я уже высказался про это выше. > Самое жёсткое пересечение -- это форк фичи pipeline в bootchain, только оно > может затронуть нынешних пользователей pipeline, коих не так много. Это нужно обсуждать. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 0:45 ` Alexey Gladkov @ 2021-09-23 2:31 ` Антон Мидюков 2021-09-23 8:59 ` Alexey Gladkov 2021-09-23 2:40 ` Leonid Krivoshein 1 sibling, 1 reply; 33+ messages in thread From: Антон Мидюков @ 2021-09-23 2:31 UTC (permalink / raw) To: make-initrd 23.09.2021 07:45, Alexey Gladkov пишет: > On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: >>> Ты где-то отдельно пишешь код >> >> Код отправляю пока в Сизиф и в локальную гитовницу: >> >> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > > Это отдельный репозиторий, делать ревью коммитов непонятно как. > git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и > патчи в рассылке лучше. > > Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. > > Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю > изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но > проблема в том, что я не представляю как это мерджить поскольку это даже > как subtree сделать. > > Моё предыдущее предложение сделать патчсет уже не актуально в данной > ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а > остальное мы доработали бы в рабочем порядке. В этом случае все изменения > бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. Давайте попытаемся съесть этого слона по частям. Как ни крути, а Леониду нужно было понимание, что должно получиться. Необходимо было проверять, подойдёт или нет то или иное решение. Сейчас появилась работающая реализация, которую можно маленькими кусочками начать перетаскивать в make-initrd. Выглядеть это может как-то так: Готовим патч для make-initrd, остальной код altboot адаптируем к этому патчу. Патч принят, готовим следующий патч, снова адаптируем оставшийся код к новому патчу. Не принят, исправляем патч, адаптируем остальной код к изменившемуся патчу. И тогда через n-ное количество итераций в репозитории alt-bootchain не останется кода, и всё будет реализовано уже в make-initrd правильно. Сложно, но возможно. Первое, что нужно сделать, это преодолеть форк pipeline. Сможем сделать это, тогда и остальное осилим. -- С уважением, Антон Мидюков <antohami@basealt.ru> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 2:31 ` Антон Мидюков @ 2021-09-23 8:59 ` Alexey Gladkov 2021-09-23 20:40 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 8:59 UTC (permalink / raw) To: make-initrd On Thu, Sep 23, 2021 at 09:31:08AM +0700, Антон Мидюков wrote: > 23.09.2021 07:45, Alexey Gladkov пишет: > > On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: > >>> Ты где-то отдельно пишешь код > >> > >> Код отправляю пока в Сизиф и в локальную гитовницу: > >> > >> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > > > > Это отдельный репозиторий, делать ревью коммитов непонятно как. > > git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и > > патчи в рассылке лучше. > > > > Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. > > > > Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю > > изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но > > проблема в том, что я не представляю как это мерджить поскольку это даже > > как subtree сделать. > > > > Моё предыдущее предложение сделать патчсет уже не актуально в данной > > ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а > > остальное мы доработали бы в рабочем порядке. В этом случае все изменения > > бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. > > Давайте попытаемся съесть этого слона по частям. > Как ни крути, а Леониду нужно было понимание, что должно получиться. > Необходимо было проверять, подойдёт или нет то или иное решение. > Сейчас появилась работающая реализация, которую можно маленькими кусочками > начать перетаскивать в make-initrd. > Выглядеть это может как-то так: > Готовим патч для make-initrd, остальной код altboot адаптируем к этому патчу. > Патч принят, готовим следующий патч, снова адаптируем оставшийся код к новому патчу. > Не принят, исправляем патч, адаптируем остальной код к изменившемуся патчу. > И тогда через n-ное количество итераций в репозитории alt-bootchain не останется > кода, и всё будет реализовано уже в make-initrd правильно. > Сложно, но возможно. Я про такую стратегию и писал в прошлом письме. Да, осталась только она. > Первое, что нужно сделать, это преодолеть форк pipeline. Сможем сделать это, > тогда и остальное осилим. Опять же кода я не видел, но судя по разговорам с Леонидом форк имеет обратную совместимость с pipeline. Если это действительно так, то больших проблем быть не должно. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 8:59 ` Alexey Gladkov @ 2021-09-23 20:40 ` Leonid Krivoshein 2021-09-23 21:15 ` Alexey Gladkov 0 siblings, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-23 20:40 UTC (permalink / raw) To: make-initrd 23.09.2021 11:59, Alexey Gladkov пишет: > On Thu, Sep 23, 2021 at 09:31:08AM +0700, Антон Мидюков wrote: >> 23.09.2021 07:45, Alexey Gladkov пишет: >>> On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: >>>>> Ты где-то отдельно пишешь код >>>> Код отправляю пока в Сизиф и в локальную гитовницу: >>>> >>>> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git >>> Это отдельный репозиторий, делать ревью коммитов непонятно как. >>> git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и >>> патчи в рассылке лучше. >>> >>> Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. >>> >>> Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю >>> изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но >>> проблема в том, что я не представляю как это мерджить поскольку это даже >>> как subtree сделать. >>> >>> Моё предыдущее предложение сделать патчсет уже не актуально в данной >>> ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а >>> остальное мы доработали бы в рабочем порядке. В этом случае все изменения >>> бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. >> Давайте попытаемся съесть этого слона по частям. >> Как ни крути, а Леониду нужно было понимание, что должно получиться. >> Необходимо было проверять, подойдёт или нет то или иное решение. >> Сейчас появилась работающая реализация, которую можно маленькими кусочками >> начать перетаскивать в make-initrd. >> Выглядеть это может как-то так: >> Готовим патч для make-initrd, остальной код altboot адаптируем к этому патчу. >> Патч принят, готовим следующий патч, снова адаптируем оставшийся код к новому патчу. >> Не принят, исправляем патч, адаптируем остальной код к изменившемуся патчу. >> И тогда через n-ное количество итераций в репозитории alt-bootchain не останется >> кода, и всё будет реализовано уже в make-initrd правильно. >> Сложно, но возможно. > Я про такую стратегию и писал в прошлом письме. Да, осталась только она. > >> Первое, что нужно сделать, это преодолеть форк pipeline. Сможем сделать это, >> тогда и остальное осилим. > Опять же кода я не видел, но судя по разговорам с Леонидом форк имеет > обратную совместимость с pipeline. Если это действительно так, то больших > проблем быть не должно. Чтобы чётко отследить историю изменений, этот фарш (bootchain-core/etc) мне придётся провернуть несколько раз через твою приёмку, я это понимаю. Изменения уже в пути! Даже не думал, что это окажется столь заковыристо, но я сам себе злобный буратино, так как избрал не самый простой путь для форка. Давай я позже отвечу на остальное, там по существу... Если бы сразу сказал, как и какие присылать патчи, я бы давно уже так делал. Тебе удобнее тарболом или текстовыми файлами? Лучше в рассылку или в личку? -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 20:40 ` Leonid Krivoshein @ 2021-09-23 21:15 ` Alexey Gladkov 2021-09-23 21:55 ` Arseny Maslennikov 2021-09-23 22:56 ` Leonid Krivoshein 0 siblings, 2 replies; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 21:15 UTC (permalink / raw) To: make-initrd On Thu, Sep 23, 2021 at 11:40:41PM +0300, Leonid Krivoshein wrote: > > Опять же кода я не видел, но судя по разговорам с Леонидом форк имеет > > обратную совместимость с pipeline. Если это действительно так, то больших > > проблем быть не должно. > > Чтобы чётко отследить историю изменений, этот фарш (bootchain-core/etc) мне > придётся провернуть несколько раз через твою приёмку, я это понимаю. > Изменения уже в пути! Даже не думал, что это окажется столь заковыристо, но > я сам себе злобный буратино, так как избрал не самый простой путь для форка. > > Давай я позже отвечу на остальное, там по существу... > > Если бы сразу сказал, как и какие присылать патчи, я бы давно уже так делал. Я постоянно говорил, чтобы ты присылал патчи. Я не ожидал, что это будет как-то неправильно понято. Антон Мидюков постоянно шлёт мне патчи в mkimage и мы их обсуждаем. Он их очень хорошо оформляет. > Тебе удобнее тарболом или текстовыми файлами? Лучше в рассылку или в личку? Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать совета. Я всегда советую всем использовать: $ git format-patch -v 1 --cover-letter --thread master.. и git сам сделает патчи по указанному диапазону и добавит хэдеры, чтобы письма объединились в тред. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 21:15 ` Alexey Gladkov @ 2021-09-23 21:55 ` Arseny Maslennikov 2021-09-23 22:41 ` Alexey Gladkov 2021-09-23 22:56 ` Leonid Krivoshein 1 sibling, 1 reply; 33+ messages in thread From: Arseny Maslennikov @ 2021-09-23 21:55 UTC (permalink / raw) To: make-initrd [-- Attachment #1: Type: text/plain, Size: 2637 bytes --] On Thu, Sep 23, 2021 at 11:15:37PM +0200, Alexey Gladkov wrote: > On Thu, Sep 23, 2021 at 11:40:41PM +0300, Leonid Krivoshein wrote: > > > Опять же кода я не видел, но судя по разговорам с Леонидом форк имеет > > > обратную совместимость с pipeline. Если это действительно так, то больших > > > проблем быть не должно. > > > > Чтобы чётко отследить историю изменений, этот фарш (bootchain-core/etc) мне > > придётся провернуть несколько раз через твою приёмку, я это понимаю. > > Изменения уже в пути! Даже не думал, что это окажется столь заковыристо, но > > я сам себе злобный буратино, так как избрал не самый простой путь для форка. > > > > Давай я позже отвечу на остальное, там по существу... > > > > Если бы сразу сказал, как и какие присылать патчи, я бы давно уже так делал. > > Я постоянно говорил, чтобы ты присылал патчи. Я не ожидал, что это будет > как-то неправильно понято. > > Антон Мидюков постоянно шлёт мне патчи в mkimage и мы их обсуждаем. Он их > очень хорошо оформляет. > > > Тебе удобнее тарболом или текстовыми файлами? Лучше в рассылку или в личку? > > Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать > совета. > > Я всегда советую всем использовать: > > $ git format-patch -v 1 --cover-letter --thread master.. > > и git сам сделает патчи по указанному диапазону и добавит хэдеры, чтобы > письма объединились в тред. Позволю себе вдобавок прорекламировать гайд, как научиться хорошо слать патчи: https://git-send-email.io/#step-2 Step 1 у них — это инструкция, как поставить необходимые пакеты, которой для альта нет. Достаточно поставить git-email. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 21:55 ` Arseny Maslennikov @ 2021-09-23 22:41 ` Alexey Gladkov 2021-09-23 22:51 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 22:41 UTC (permalink / raw) To: make-initrd On Fri, Sep 24, 2021 at 12:55:00AM +0300, Arseny Maslennikov wrote: > > Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать > > совета. > > > > Я всегда советую всем использовать: > > > > $ git format-patch -v 1 --cover-letter --thread master.. > > > > и git сам сделает патчи по указанному диапазону и добавит хэдеры, чтобы > > письма объединились в тред. > > Позволю себе вдобавок прорекламировать гайд, как научиться хорошо слать > патчи: https://git-send-email.io/#step-2 > Step 1 у них — это инструкция, как поставить необходимые пакеты, которой > для альта нет. Достаточно поставить git-email. Да! Я сначала хотел написать про git-send-email, но подумал, что будет выглядеть будто я вздумал учить как письма отправлять ))) git-send-email это отличная утилита! Я очень её люблю. Я на основе git-send-email и git-format-patch сделал себе обвязку [1], которой постоянно пользуюсь на работе. Простите, за саморекламу. Инструкция, кстати, зачётная. [1] https://github.com/legionus/git-patchset -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 22:41 ` Alexey Gladkov @ 2021-09-23 22:51 ` Leonid Krivoshein 0 siblings, 0 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-23 22:51 UTC (permalink / raw) To: make-initrd 24.09.2021 1:41, Alexey Gladkov пишет: > On Fri, Sep 24, 2021 at 12:55:00AM +0300, Arseny Maslennikov wrote: >>> Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать >>> совета. >>> >>> Я всегда советую всем использовать: >>> >>> $ git format-patch -v 1 --cover-letter --thread master.. >>> >>> и git сам сделает патчи по указанному диапазону и добавит хэдеры, чтобы >>> письма объединились в тред. >> Позволю себе вдобавок прорекламировать гайд, как научиться хорошо слать >> патчи: https://git-send-email.io/#step-2 >> Step 1 у них — это инструкция, как поставить необходимые пакеты, которой >> для альта нет. Достаточно поставить git-email. > Да! Я сначала хотел написать про git-send-email, но подумал, что будет > выглядеть будто я вздумал учить как письма отправлять ))) > > git-send-email это отличная утилита! Я очень её люблю. Я на основе > git-send-email и git-format-patch сделал себе обвязку [1], которой > постоянно пользуюсь на работе. Простите, за саморекламу. > > Инструкция, кстати, зачётная. > > [1] https://github.com/legionus/git-patchset Ух, камрады, спасибо! Хоть на старости начну чему-то учиться, мне это полезно... -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 21:15 ` Alexey Gladkov 2021-09-23 21:55 ` Arseny Maslennikov @ 2021-09-23 22:56 ` Leonid Krivoshein 2021-09-23 23:31 ` Alexey Gladkov 1 sibling, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-23 22:56 UTC (permalink / raw) To: make-initrd 24.09.2021 0:15, Alexey Gladkov пишет: >> Тебе удобнее тарболом или текстовыми файлами? Лучше в рассылку или в личку? > Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать > совета. А лучше в одно письмо вложить или разделить на отдельные письма? Их получится довольно много, потому и спрашиваю. Заранее прошу простить за очередность патчей, но для первой итерации я решил оставить самые сложные и спорные изменения напоследок. Когда всё основное согласуем, можно будет и очерёдность поменять. Пока я дошёл до самого интересного... )) -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 22:56 ` Leonid Krivoshein @ 2021-09-23 23:31 ` Alexey Gladkov 0 siblings, 0 replies; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 23:31 UTC (permalink / raw) To: make-initrd On Fri, Sep 24, 2021 at 01:56:55AM +0300, Leonid Krivoshein wrote: > > 24.09.2021 0:15, Alexey Gladkov пишет: > > > Тебе удобнее тарболом или текстовыми файлами? Лучше в рассылку или в личку? > > Лучше патчами и лучше в рассылку. Тут больше людей и проще спрашивать > > совета. > > А лучше в одно письмо вложить или разделить на отдельные письма? По одному письму на коммит. Собственно git-format-patch как раз и делает готовые письма. > Их получится довольно много, потому и спрашиваю. Меня это не пугает. > Заранее прошу простить за очередность патчей, но для первой итерации я решил > оставить самые сложные и спорные изменения напоследок. Когда всё основное > согласуем, можно будет и очерёдность поменять. Пока я дошёл до самого > интересного... )) -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 0:45 ` Alexey Gladkov 2021-09-23 2:31 ` Антон Мидюков @ 2021-09-23 2:40 ` Leonid Krivoshein 2021-09-23 11:38 ` Alexey Gladkov 1 sibling, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-23 2:40 UTC (permalink / raw) To: make-initrd 23.09.2021 3:45, Alexey Gladkov пишет: > On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote: >>> Ты где-то отдельно пишешь код >> Код отправляю пока в Сизиф и в локальную гитовницу: >> >> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > Это отдельный репозиторий, делать ревью коммитов непонятно как. > git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и > патчи в рассылке лучше. > > Ты несколько раз говорил про него, но я просто не знаю, что с ним делать. > > Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю > изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но > проблема в том, что я не представляю как это мерджить поскольку это даже > как subtree сделать. Это WiP, история и патчи там черновые, даже с опечатками. Нет смысла держаться за такое. Всё делалось исходя из намеченного плана. > Моё предыдущее предложение сделать патчсет уже не актуально в данной > ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а > остальное мы доработали бы в рабочем порядке. В этом случае все изменения > бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно. Скажу честно, с момента написания черновика документации, все коммиты в m-i-b кода не сильно прибавили, изменения коснулись, в основном, исправления найденных ошибок и недочётов. Т.е. размер на момент публикации в Сизифе примерно таким и был. Для обсуждения предлагалась самая первая минимальная реализация без диалогов. Ты её сильно раскритиковал и тогда я сделал вторую, уже с диалогами, в виде монолитной фичи. А это третья реализация, модульная, она такой практически и была изначально. Я не предлагаю перетаскивать doc -- это совершено не готовая часть для разработчиков и тестировщиков, туда как раз ушла часть кода от исходно опубликованной версии, ещё из дерева удалена вторая реализация. Так что я как раз готовил проект к апстриму. > Но ты выбрал иную стратегию. Ты разрабатываешь вещь в себе в отдельном > репозитории. Это просто некое отдельное решение на основе make-initrd. Ну, подожди, мы же обсуждали эту стратегию: публикация в Сизифе для более широкомасштабного тестирования на регулярках и по готовности апстрим. Она не в себе, а уже делалась с учётом множества твоих замечаний. И сейчас не разрабатывается, а скорее дорабатывается и исправляется. > Этот репозитории повторяет стратегию make-initrd-propagator, который > как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в > себе. Новый, правда, интегрирован с основным кодом лучше. Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с нынешним stage2. Если что-то не так приделываю, можно же это предметно обсуждать. Да, я сначала думал делать полный или частичный форк фичи network, потому что были большие сомнения, что удастся с ней интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше похожим на propagator (по возможностям) и удалось обойтись без форка, в отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 -- работает просто идеально. >>> вместо того чтобы обсуждать и порциями добавлять. >> Если бы работы по обсуждённому ранее плану были завершены, мне бы только и >> оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам >> настаивал, чтобы продукт был тщательно проверен до того, как он поедет в >> апстрим. Находятся замечания, предложения, приходится их устранять и >> учитывать. А из-за этого у меня откладывается работа по автоматизации >> тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно >> работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать >> очередные регулярки с разными опциями и методами загрузки. >> >> Лично мне кажется, что ни один пакет у нас так пристально не проверялся, >> попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и >> моя задача учесть совместимость с уже сделанным в Альте за многие годы. > Я начинаю думать, что уже лучше оставить всё как есть сейчас. Пусть > make-initrd-bootchain остаётся отдельным репозиторием и пакетом. > > Когда в make-initrd будут появляться новые интерфейсы или фичи, то они > будут начинать использоваться в make-initrd-bootchain. В том числе, когда > какой-то функционал будет переползать в апстрим. > > Иначе я просто не представляю как всё уже написанное поддерживать. Код bootchain-core + bootchain-getimage + bootchain-waitdev сопоставим с нынешним pipeline. Предлагаю поступить так: эти три я сделаю одним патчсетом. Главное, чтобы твои автотесты не забраковали, т.к. совместимость с pipeline там соблюдена. Остальное можно сделать как хочешь -- каждую фичу одним патчем, всё в пределах одного выпуска. Я соберу тестовое задание, мы его протестируем, а как поддерживать -- уже вопрос наживной. При локализации проблем в области bootchian/altboot просто добавлять меня в cc: багов. Благо bc_debug позволяет собрать нужную диагностику. > [...] >> Как раз я старался учесть возможность перехода в будущем на более правильные >> концепции. Но сейчас и тебе надо принять, как данность, что пусть >> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был >> внутри make-initrd > Вот тут ты ошибаешься. Мне не нужно и тебе не советую принимать как > данность, что нужно повторять поведение, которое написано в 2004. Это > поведение чуть-чуть устарело. > > Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем > его переизобретать. Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы готовимся избавиться от isolinux для legacy/x86, но сколько это будет тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в загрузку и на это приходится ориентироваться, так как если не работает, сразу баг. >> и работал как 1/80 часть его рантайма, а не наоборот, >> чтобы настоящий propagator полностью выкидывал и заменял собой все 100% >> рантайма make-initrd. > Признаюсь тебе: мне нет дела до propagator. Это древний кусок гов^W кода. > Раньше он замечательно работал без make-initrd. Он делает всё сам и своими > методами. > > Считаю ли я, что _функционал_ propagator может быть реализован на > make-initrd ? Да. Именно это и делает altboot. > Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. В каком смысле? Я не копировал его повеление в точности. Но методы -- нужны, совместимость со stage2 -- нужна. Многое сделано лучше и модульно, это нельзя назвать 100% копией поведения. И всё делалось в пределах исходной концепции pipeline, код декомпозирован. > Я считаю, что должна быть сохранена совместимость до определённой степени. > Я не считаю, что нужна полная копия поведения. Для последнего у вас есть > сам propagator. Его уже начали капитально переделывать под новые реалии. Но без меня. >> Можно и нужно обсуждать, как лучше сделать это, не >> ломая совместимости, и учитывая потребности перехода на что-то более >> правильное в перспективе. > Ты сам себе противоречишь. Я должен принять, как данность функционал > пропагатора и не ломая совместимости с кодом 17 летней (на самом деле > большей) давности переходить на что-то более правильное. Коду инсталлятора уже 17 лет? Пропагатор был его первой частью. У ОС Альт есть два варианта при выкидывании пропагатора -- жить без инсталлятора или найти новый. К обеим вариантам пока не готовы. Перелопачивать старый -- тоже пока нет ресурсов. Так что замена в make-initrd должна быть адекватной. Но кроме инсталлятора есть ещё загрузчики, сетевая установка (alterator-netinst), да ещё куча всего, плюс документация. Это всё нужно переделывать. Сейчас это нереально. > И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить > с и переписывать эту "данность" с учётом совместимости буду я ? Отличная > перспектива. Вот тут я не понял, что ты предлагаешь. Изначально весь код делался как часть make-initrd, это же твой проект. Не, ну давай будем поддерживать всем миром. )) Мне кажется, что моя помощь в написании кода, документации, методики тестирования и инструментов для автоматизации тестирования с лихвой покроет даже моё неучастие в дальнейшей судьбе. Но я могу помогать с поддержкой, по возможности, хотя слабо представляю, как это возможно, когда это войдёт в состав make-initrd. > А давайте сначала вы осознаете, что вам не нужен клон propagator и будете > апстримить уже стазу более правильное ? Мы осознавали, что нам без этого не обойтись с самого начала, это обсуждалось ещё после первой же пробной версии. Иначе нужно осознать, что выкинуть нам придётся очень много, что невозможно без адекватной замены. > Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, > что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на > поддержку. Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно понимаю. Вчера собрались регулярки и не грузится RPi4, сразу ко мне вопрос. В результате altboot оказался не причём, но так мне хотя бы спокойнее будет, а тебе какая разница, 80 тыс. строк кода поддерживать или 86 тыс., ты же к такому уже привык!? :-) >>> И я до сих пор не видел ни одного патча. Поэтому для >>> меня каждая твоя проблема является большим сюрпризом. >> Кажется, несколько попыток я уже делал, в частности, отдельно предлагал >> bootchain-interactive. > Патчей или PR так и не было. Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у меня на гитхабе аккаунта или я не очень понимаю в этой терминологии. [...] > Так это неправильно. Пользователь может такое хотеть. Да и дело не только > в dhcp -> static. Нужно уметь расконфигурировать интерфейс. Да, согласен, но до этого мы ещё дожили на данном этапе развития. >> if [ ! -s /bin/network-sh-functions ]; then > В 2.22.0-13-g78001064a я специально реализовал проверку фич о которой мы > говорили. Да, но я на 2.23 только сегодня первый раз собрал, у меня до этого более старая версия была. Понятно, что надо будет менять в коде всё, о чём говорили, если уже появилось в make-initrd. >> А полная совместимость с пропагатором требует другого синтаксиса > А зачем эта совместимость ? Ты пишешь про это как про аксиому. Потому что есть целая куча пакетов и документации в продуктах к ним, которые его используют. Например, для работы со слоями NFS, для сетевой установки. Я уже говорил выше, что речь о совместимости именно с этими многолетними наработками, которые разом не выкинуть, не заменить. > Я не хочу отвлекаться на кулстори, но когда мы с inger@ писали инсталлер, > то как-то пережили отсутствие совместимости с mandrake. А тут внезапно > появилось желание иметь совместимость с его частью. Я тоже не люблю совместимость, хочется всё с нуля написать. Но порою это дольше. >>> [...] >>> Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны >>> на системном уровне, чтобы весь код был готов к изменению параметров, но >>> почему-то меня не услышали. >> Тебе видней, как это реализовать на системном уровне, разве кто-то будет >> возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал >> перетащить на верхний уровень bootchain-interactive > Я не понял как ты предлагал это перетакивать. Скопировать код в другой > репозиторий ? п.7 здесь (самый конец): https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html и первый ответ тут: https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html я был уверен, что уже удалил то задание, но нет. :-) так это и был патч для make-initrd с фичей interactive. > [...] >>>>>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >>>>>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >>>>>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >>>>>> сделать. >> P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её >> апстримить. Вот прямо сегодня! :-) > Я уже высказался про это выше. Всё это время я следовал договорённостям. Так что ты меня сильно удивил. Не веришь -- склонируй к себе версию 0.1.5-alt3, удали bootchain-doc, т.к. его не предлагаю пока апстримить, посчитай объём чем-нибудь типа du/wc, а затем обнули до initial commit и сравни с полученным. Ничего тут не увеличилось, я в этом уверен. 200 строк -- не та разница, из-за которой это становится неподъёмной ношей. Мы занимаемся просто причёсыванием и доводкой до абсолютно рабочего состояния. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 2:40 ` Leonid Krivoshein @ 2021-09-23 11:38 ` Alexey Gladkov 2021-09-24 17:31 ` Leonid Krivoshein 0 siblings, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-23 11:38 UTC (permalink / raw) To: make-initrd On Thu, Sep 23, 2021 at 05:40:10AM +0300, Leonid Krivoshein wrote: > > Этот репозитории повторяет стратегию make-initrd-propagator, который > > как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в > > себе. Новый, правда, интегрирован с основным кодом лучше. > > Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и > network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал > на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с > нынешним stage2. Если что-то не так приделываю, можно же это предметно > обсуждать. Да, я сначала думал делать полный или частичный форк фичи > network, потому что были большие сомнения, что удастся с ней > интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше > похожим на propagator (по возможностям) и удалось обойтись без форка, в > отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 > -- работает просто идеально. К вопросу о ревью: вот и как предполагается комментировать код с git.alt ? Ок, буду по ссылкам. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l12 Про это я уже писал. Это проверяется не так. Остальной интегрируется так, что не использует ничего из того с чем интегрируется. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l32 В network-sh-functions есть ipv4_enabled. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l51 Теряются абсолютно все ошибки. Ошибки в ip=, в macaddr, в указании масок. Вместо всего этого будет "can't reconfigure network settings". Этого быть не должно. Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 Этот шаг можно выполнить лишь один раз. Это не вяжется у меня с "Can't bridge up network interface. Try with other network settings, wired connection and/or cable." Если пользователь попробует тот же интерфейс с другими настройками, то второй раз проверки не будет ??? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l65 Хардкод имени интерфейса. is_loopback(). http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l67 Для чего эта проверка ? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l73 Я полагаю это проверка на то что интерфейс поднят ? Если да, то is_link_up Если проверка на присутствие адреса, то "/.initrd/online/$NET_IF". > > Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем > > его переизобретать. > > Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа > быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы > готовимся избавиться от isolinux для legacy/x86, но сколько это будет > тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в > загрузку и на это приходится ориентироваться, так как если не работает, > сразу баг. Я уж не знаю вашей кухни, но вообще-то, да, это сразу бага. Бага на брэндинг. Он передаёт устаревшие параметры. Новый make-initrd+bootchain всё равно требует либо дополнительных, либо других параметров для включения новых фич. > > Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. > > В каком смысле? Я не копировал его повеление в точности. Но методы -- нужны, > совместимость со stage2 -- нужна. Многое сделано лучше и модульно, это > нельзя назвать 100% копией поведения. И всё делалось в пределах исходной > концепции pipeline, код декомпозирован. Если ты не копируешь повеление в точности, то пожалуйста поясни свой тезис: > Но сейчас и тебе надо принять, как данность, что пусть > "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был > внутри make-initrd Если ты не занимаешься копированием, то неправильного "функционала пропагатора" в новом коде быть не должно. > > Я считаю, что должна быть сохранена совместимость до определённой степени. > > Я не считаю, что нужна полная копия поведения. Для последнего у вас есть > > сам propagator. > > Его уже начали капитально переделывать под новые реалии. Но без меня. http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=08639c8fafa30e0f78d19f1c5831fd2b1cc2bc02 Это, кстати, интересно. > > > Можно и нужно обсуждать, как лучше сделать это, не > > > ломая совместимости, и учитывая потребности перехода на что-то более > > > правильное в перспективе. > > Ты сам себе противоречишь. Я должен принять, как данность функционал > > пропагатора и не ломая совместимости с кодом 17 летней (на самом деле > > большей) давности переходить на что-то более правильное. > > Коду инсталлятора уже 17 лет? Ваш _инсталлятор_ был написан для Server 4 (который был ещё до branch4). Этот инсталлер, как и предыдущий использовал propagator как stage1. Так что вашему инсталлеру уже примерно 11-12 лет, а propagator же был за долго до него. > > И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить > > с и переписывать эту "данность" с учётом совместимости буду я ? Отличная > > перспектива. > > Вот тут я не понял, что ты предлагаешь. Изначально весь код делался как > часть make-initrd, это же твой проект. Не все модули, которые пишутся для make-initrd автоматически становятся моими. Некоторые так и не попадают в репозиторий. Всё что я принимаю в репозиторий я понимаю и поддерживаю. Я должен понимать код и как он работает именно потому что он переходит от коммитера в репозиторий. > Не, ну давай будем поддерживать всем миром. )) Именно потому что ты ставишь здесь смайлики я и не принимаю просто "написанный код". > Мне кажется, что моя помощь в написании кода, документации, методики > тестирования и инструментов для автоматизации тестирования с лихвой > покроет даже моё неучастие в дальнейшей судьбе. Обычно так и происходит. Коммитер пишет код, тестирует, документирует его, отдаёт в апстрим и идёт своей дорогой. Но так происходит лишь тогда, когда апстрим понимает и согласен со всеми предложенными изменениями. То что ты написал не подпадает под последнее. У меня есть много вопросов как архитектуре фич, так и к реализации. Когда ты решишь разрешишь все эти вопросы, тогда я заберу код, а ты, если хочешь, можешь не участвовать в его дальнейшей судьбе. > Но я могу помогать с поддержкой, по возможности, хотя слабо представляю, > как это возможно, когда это войдёт в состав make-initrd. После вхождения изменений в мой репозиторий я не требую от тебя какой-то поддержки. Но такое возможно лишь при разрешении всех моих вопросов. > > Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, > > что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на > > поддержку. > > Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно понимаю. > Вчера собрались регулярки и не грузится RPi4, сразу ко мне вопрос. В > результате altboot оказался не причём, но так мне хотя бы спокойнее будет, а > тебе какая разница, 80 тыс. строк кода поддерживать или 86 тыс., ты же к > такому уже привык!? :-) Так вот оно что. То есть ты просто единовременно переписал propagator на шелле, а не на make-initrd, потому что твой код использует остальной мой код по минимуму, получил make-initrd-propagator, но теперь с банановым вкусом и хочешь, чтобы уже с новым неподдерживаемым кодом возился я (ты сам пишешь, что не тянешь его поддержку). Нет, Леонид, так просто у тебя скинуть на меня это не получится. Я заберу у тебя только то с чем буду полностью согласен. > > Патчей или PR так и не было. > > Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у меня > на гитхабе аккаунта или я не очень понимаю в этой терминологии. Леонид, я не сотрудник, который работает с тобой. У меня нет возможности анализировать тестовые задания и патчи в них. Патчи можно слать по почте в рассылку или лично, можно завести аккаунт на github и делать PR там, как это делает Пётр Михалицын. Ещё раз для ясности: Я не готов лазать по каким-то там тестовым заданиям, пакетам в сизифе с целью "а что бы такого ещё запстримить". Мне это не нужно. > > > > А полная совместимость с пропагатором требует другого синтаксиса > > А зачем эта совместимость ? Ты пишешь про это как про аксиому. > > Потому что есть целая куча пакетов и документации в продуктах к ним, которые > его используют. Например, для работы со слоями NFS, для сетевой установки. Я > уже говорил выше, что речь о совместимости именно с этими многолетними > наработками, которые разом не выкинуть, не заменить. Их не нужно выкидывать. Они могут быть реализованы иначе. Я не говорю, что нужно назло переименовывать всё. Я говорю, что старый подход плохо реализуется в новом коде, то его нужно менять и менять документацию. > > Я не понял как ты предлагал это перетакивать. Скопировать код в другой > > репозиторий ? > > п.7 здесь (самый конец): > https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html Ок. Давай процитирую: > > 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала > > процесса > > апстрима или тебе лучше делать это по ходу? > > Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет > удобнее. Мне удобнее по ходу. По ходу!!! Ты хоть куда-нибудь патчи посылал для обсуждения ? В рассылке их нет. В личке тоже. > > 7. Предлагаю такую последовательность отправки коммитов: > > bootchain-interactive, затем bootchain-core + bootchain-getimage + > > bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью > > на > > фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка > > altboot), можно одним коммитом. Так пойдёт? > > Вполне. А тут ты про некую последовательность коммитов говорил, но где они ??? Я до сих пор не получил ни одного коммита. Все эти разговоры пустая болтовня какая-то. > и первый ответ тут: > https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html > > я был уверен, что уже удалил то задание, но нет. :-) > так это и был патч для make-initrd с фичей interactive. Блин, опять какое-то тестовое задание, где нужно искать, что ты там наменял. Я даже ссылку на строчку в diff с которой не согласен не могу прислать сюда. Ещё бы через DHL распечатки кода прислали. Знаешь, что мне такие "коммиты" даром не нужны. Далее обсуждать такой подход добавления изменений в make-initrd не имеет смысла. Если захочешь узнать как это делается без издевательства на ревьювером, то спроси у Глеба или Димы. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-23 11:38 ` Alexey Gladkov @ 2021-09-24 17:31 ` Leonid Krivoshein 2021-09-24 18:35 ` Leonid Krivoshein 2021-09-24 19:00 ` Alexey Gladkov 0 siblings, 2 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-24 17:31 UTC (permalink / raw) To: make-initrd Привет! 23.09.2021 14:38, Alexey Gladkov пишет: > On Thu, Sep 23, 2021 at 05:40:10AM +0300, Leonid Krivoshein wrote: >>> Этот репозитории повторяет стратегию make-initrd-propagator, который >>> как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в >>> себе. Новый, правда, интегрирован с основным кодом лучше. >> Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и >> network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал >> на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с >> нынешним stage2. Если что-то не так приделываю, можно же это предметно >> обсуждать. Да, я сначала думал делать полный или частичный форк фичи >> network, потому что были большие сомнения, что удастся с ней >> интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше >> похожим на propagator (по возможностям) и удалось обойтись без форка, в >> отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 >> -- работает просто идеально. Тут надо пояснить, что о работе и интеграции говорилось с учётом ранее сказанного и того факта, что waitnet времянка снаружи, а не заапстримленный код внутри make-initrd. При создании waitnet ставилась совершенно определённая цель и в этом плане она выполнена на 100%, далее объясню, почему... > К вопросу о ревью: вот и как предполагается комментировать код с git.alt ? > Ок, буду по ссылкам. > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l12 Уже понял, что лучше отдельными патчами в рассылку. Просто, когда-то давно ты и так принимал. > Про это я уже писал. Это проверяется не так. С has_feature() я разобрался. И в новой версии уже она. Но пока код не заапстримлен, полагаться на API в make-initrd и тем более привязываться жёстко к каким-то фичам весьма рисково: любая твоя новая сборка с таким изменением сможет поломать работу ещё не заапстримленного altboot, поэтому я иду по пути минимальной привязки на данном этапе. Поэтому и: > Остальной интегрируется так, что не использует ничего из того с чем > интегрируется. > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l32 > > В network-sh-functions есть ipv4_enabled. Разумеется, я внимательно изучил код фичи и видел эту функцию. > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l51 > > Теряются абсолютно все ошибки. Ошибки в ip=, в macaddr, в указании масок. > Вместо всего этого будет "can't reconfigure network settings". Этого быть > не должно. Тут я полностью согласен. Но уже говорил, что код не финальный. waitnet -- времянка для выяснения конкретной возможности. Если выкинуть этот код, выкинуть шаг waitnet из цепочки загрузки, все 4 сетевых метода сейчас будут работать без него. Надо будет указывать ip=dhcp в /proc/cmdline или задавать другие сетевые настройки. Поэтому отправка в /dev/null сейчас сделана чисто чтобы не портить внешний вид диалога, наверное, лучше отправлять в 1>&2 в этом месте. > Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network. > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 > > Этот шаг можно выполнить лишь один раз. Не согласен! :-) И waitnet демонстрирует это без чистки предыдущей конфигурации. Объясню почему. Сейчас waitnet смотрит, была ли выполнена конфигурация. И если конфигурировался только lo, то повторный запуск без чистки ни на что не повлияет. Он же не создаст дублирующего правила udev, т.к. перед дёрганием явно задаётся IFNAME="0". > Это не вяжется у меня с > > "Can't bridge up network interface. Try with other network settings, wired > connection and/or cable." > > Если пользователь попробует тот же интерфейс с другими настройками, то > второй раз проверки не будет ??? На этом диалоге ранее выполнялся перезапуск машины, в версии 0.1.5-alt3 решил в этом месте перезапустить altboot -- сейчас тут возврат в начальное меню, где можно выбрать другой метод загрузки, не по сети. Т.е., прошло 16 секунд, сеть так и не поднялась. Если этого мало, пользователь дойдёт сюда снова. Но может и другой путь выбрать для загрузки. > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l65 > > Хардкод имени интерфейса. is_loopback(). Не только, это ещё и break loop / защита от пустого каталога. Обычно я тут ставлю "_". > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l67 > > Для чего эта проверка ? Чтобы предотвратить дальнейшую работу цикла, если мы имеем дело не с сетевым интерфейсом. И ещё проверка того факта, что с момента вышестоящей команды ls интерфейс не исчез. > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l73 > > Я полагаю это проверка на то что интерфейс поднят ? Если да, то is_link_up > Если проверка на присутствие адреса, то "/.initrd/online/$NET_IF". Да, разумеется, про более тесную интеграцию я уже выше написал. Где-то ранее мы как раз обсуждали, ты же сам и говорил, что надёжнее не дёргать внутренности make-initrd, а проверять через ip. waitnet -- "проверка боем" того факта, что внутри make-initrd можно повторно дёрнуть фичу network, выполнив конфигурирование в том случае, если его ещё не было, возможность передать ему вполне конкретные настройки. Правильное название этой фичи -- bootchain-network, правильное название шага с диалогами (!) -- neconfig или netsetup, основная цель -- "не делать форк фичи network" достигнута. Разумеется, netconfig/netsetup при апстириме нужно будет интегрировать с фичей network более жёстко, но тогда тебе придётся следить в обеих местах, чтобы не разъезжалось. Собственно, именно это и было целью эксперимента "waitnet", и целью одной из так и не состоявшихся встреч -- обсудить принципиальную возможность интеграции существующих фич с bootchain/interactive. >>> Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем >>> его переизобретать. >> Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа >> быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы >> готовимся избавиться от isolinux для legacy/x86, но сколько это будет >> тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в >> загрузку и на это приходится ориентироваться, так как если не работает, >> сразу баг. > Я уж не знаю вашей кухни, но вообще-то, да, это сразу бага. > Бага на брэндинг. Он передаёт устаревшие параметры. Всё так, но надо учитывать, что их куча, и нет цели и возможности исправить это всё сразу. > Новый make-initrd+bootchain всё равно требует либо дополнительных, либо > других параметров для включения новых фич. Да, но только в тех местах, где добавляются новые фичи, типа netstart, где требуется поддержка их со стороны stage2, так они будут предметно исправляться/добавляться. И даже в этих случаях стараюсь пока справиться с проблемой в stage1. Подход тут такой похож на твой -- make-initrd же решает проблемы и зависимостями в ядре, и фирмварью, где возникает, итд. Вот и altboot это первая часть альтового инсталлятора, а не только загрузка. Никто на эту конструкцию не переползёт, пока она не взлетит. >>> Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. >> В каком смысле? Я не копировал его повеление в точности. Но методы -- нужны, >> совместимость со stage2 -- нужна. Многое сделано лучше и модульно, это >> нельзя назвать 100% копией поведения. И всё делалось в пределах исходной >> концепции pipeline, код декомпозирован. > Если ты не копируешь повеление в точности, то пожалуйста поясни свой > тезис: > >> Но сейчас и тебе надо принять, как данность, что пусть >> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был >> внутри make-initrd > Если ты не занимаешься копированием, то неправильного "функционала > пропагатора" в новом коде быть не должно. Тут я с тобой полностью согласен. И я тоже не хочу пихать в make-initrd плохой код. >>> Я считаю, что должна быть сохранена совместимость до определённой степени. >>> Я не считаю, что нужна полная копия поведения. Для последнего у вас есть >>> сам propagator. >> Его уже начали капитально переделывать под новые реалии. Но без меня. > http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=08639c8fafa30e0f78d19f1c5831fd2b1cc2bc02 > > Это, кстати, интересно. Да, там много интересного и полезного, хоть я и не со всем согласен. Кстати, вывод на /dev/ttyprintk сейчас в bootchian реализуем через сборку образа с BC_LOG_VT=printk. >>>> Можно и нужно обсуждать, как лучше сделать это, не >>>> ломая совместимости, и учитывая потребности перехода на что-то более >>>> правильное в перспективе. >>> Ты сам себе противоречишь. Я должен принять, как данность функционал >>> пропагатора и не ломая совместимости с кодом 17 летней (на самом деле >>> большей) давности переходить на что-то более правильное. >> Коду инсталлятора уже 17 лет? > Ваш _инсталлятор_ был написан для Server 4 (который был ещё до branch4). > Этот инсталлер, как и предыдущий использовал propagator как stage1. Так > что вашему инсталлеру уже примерно 11-12 лет, а propagator же был за долго > до него. Тебе история видней, я лишь борюсь с конкретными взрывами. :-) > [...] > Обычно так и происходит. Коммитер пишет код, тестирует, документирует его, > отдаёт в апстрим и идёт своей дорогой. Но так происходит лишь тогда, когда > апстрим понимает и согласен со всеми предложенными изменениями. > > То что ты написал не подпадает под последнее. Ну вот опять, не надо спешить с выводами. Будем над этим работать! > У меня есть много вопросов > как архитектуре фич, так и к реализации. Когда ты решишь разрешишь все эти > вопросы, тогда я заберу код, а ты, если хочешь, можешь не участвовать в > его дальнейшей судьбе. ОК > >> Но я могу помогать с поддержкой, по возможности, хотя слабо представляю, >> как это возможно, когда это войдёт в состав make-initrd. > После вхождения изменений в мой репозиторий я не требую от тебя какой-то > поддержки. Но такое возможно лишь при разрешении всех моих вопросов. OK > >>> Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, >>> что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на >>> поддержку. >> Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно понимаю. >> Вчера собрались регулярки и не грузится RPi4, сразу ко мне вопрос. В >> результате altboot оказался не причём, но так мне хотя бы спокойнее будет, а >> тебе какая разница, 80 тыс. строк кода поддерживать или 86 тыс., ты же к >> такому уже привык!? :-) > Так вот оно что. Не, ну смайлики тоже надо учитывать. )) > То есть ты просто единовременно переписал propagator на шелле, а не на > make-initrd, потому что твой код использует остальной мой код по > минимуму, получил make-initrd-propagator, но теперь с банановым вкусом и > хочешь, чтобы уже с новым неподдерживаемым кодом возился я (ты сам > пишешь, что не тянешь его поддержку). > > Нет, Леонид, так просто у тебя скинуть на меня это не получится. Я заберу > у тебя только то с чем буду полностью согласен. OK > >>> Патчей или PR так и не было. >> Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у меня >> на гитхабе аккаунта или я не очень понимаю в этой терминологии. > Леонид, я не сотрудник, который работает с тобой. У меня нет возможности > анализировать тестовые задания и патчи в них. > > Патчи можно слать по почте в рассылку или лично, можно завести аккаунт на > github и делать PR там, как это делает Пётр Михалицын. > > Ещё раз для ясности: Я не готов лазать по каким-то там тестовым заданиям, > пакетам в сизифе с целью "а что бы такого ещё запстримить". Мне это не > нужно. > >>>> А полная совместимость с пропагатором требует другого синтаксиса >>> А зачем эта совместимость ? Ты пишешь про это как про аксиому. >> Потому что есть целая куча пакетов и документации в продуктах к ним, которые >> его используют. Например, для работы со слоями NFS, для сетевой установки. Я >> уже говорил выше, что речь о совместимости именно с этими многолетними >> наработками, которые разом не выкинуть, не заменить. > Их не нужно выкидывать. Они могут быть реализованы иначе. Я не говорю, что > нужно назло переименовывать всё. Я говорю, что старый подход плохо > реализуется в новом коде, то его нужно менять и менять документацию. Реально, реализуемо, но не в обозримом будущем. Нет воли, нет исполнителей. Даже то, что мы с тобой с разных сторон делаем, пытаясь заменить propagator, делается с 2018 года. > [...] > А тут ты про некую последовательность коммитов говорил, но где они ??? > Я до сих пор не получил ни одного коммита. Все эти разговоры пустая > болтовня какая-то. И с этим вроде разобрались, а то github, ещё PR какой-то. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-24 17:31 ` Leonid Krivoshein @ 2021-09-24 18:35 ` Leonid Krivoshein 2021-09-24 19:00 ` Alexey Gladkov 1 sibling, 0 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-24 18:35 UTC (permalink / raw) To: make-initrd 24.09.2021 20:31, Leonid Krivoshein пишет: >> Также я уже говорил, что я думаю про дёргание >> /lib/initrd/cmdline.d/network. >> >> http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 >> >> >> Этот шаг можно выполнить лишь один раз. > > Не согласен! :-) И waitnet демонстрирует это без чистки предыдущей > конфигурации. Объясню почему. Сейчас waitnet смотрит, была ли > выполнена конфигурация. И если конфигурировался только lo, то > повторный запуск без чистки ни на что не повлияет. Он же не создаст > дублирующего правила udev, т.к. перед дёрганием явно задаётся IFNAME="0". > > >> Это не вяжется у меня с >> >> "Can't bridge up network interface. Try with other network settings, >> wired >> connection and/or cable." >> >> Если пользователь попробует тот же интерфейс с другими настройками, то >> второй раз проверки не будет ??? > > На этом диалоге ранее выполнялся перезапуск машины, в версии > 0.1.5-alt3 решил в этом месте перезапустить altboot -- сейчас тут > возврат в начальное меню, где можно выбрать другой метод загрузки, не > по сети. Т.е., прошло 16 секунд, сеть так и не поднялась. Если этого > мало, пользователь дойдёт сюда снова. Но может и другой путь выбрать > для загрузки. Кажется, я только сейчас понял вопрос и замечание. С одной стороны, в коде сейчас проверяется IP=0: если да, и другие тоже, значит конфигурирование через /proc/cmdline не выполнено. И в /.initrd/initenv сохраняется IP=1, после чего разово дёргается /lib/initrd/cmdline.d/network, которая до этого для именно конфигурирования настоящих интерфейсов толком не использовалась. И далее стоит ожидание поднятия какой-нибудь сети, также обёрнутое в проверку наличия файла -- если он создан, в нём имя поднятого интерфейса. Так что в диалогах можно повторять этот квест многократно, к повторным дёрганиям фичи network это не приведёт и лишний раз не будет проверяться наличие сети, если оно было выполнено ранее. Но, т.к. waitnet -- времянка и proof of concept, назвать всё её нынешнее поведение правильным нельзя и потенциально при доводке данного шага до задуманного netconfig/netsetup непременно возникнет та проблема, о которой ты говоришь, и без договорённости её конечно не решить. Так что обсуждать эти тонкие моменты более тесной интеграции всё равно придётся. Разумеется, если шаг/диалог будет предусматривать возможность неоднократно настраивать сеть, её и опускать надо аккуратно, и конфигурацию очищать, и network должен быть готов к тому, чтобы его можно было повторно дёргать. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-24 17:31 ` Leonid Krivoshein 2021-09-24 18:35 ` Leonid Krivoshein @ 2021-09-24 19:00 ` Alexey Gladkov 2021-09-24 20:09 ` Leonid Krivoshein 1 sibling, 1 reply; 33+ messages in thread From: Alexey Gladkov @ 2021-09-24 19:00 UTC (permalink / raw) To: make-initrd On Fri, Sep 24, 2021 at 08:31:50PM +0300, Leonid Krivoshein wrote: > Привет! > > > 23.09.2021 14:38, Alexey Gladkov пишет: > > On Thu, Sep 23, 2021 at 05:40:10AM +0300, Leonid Krivoshein wrote: > > > > Этот репозитории повторяет стратегию make-initrd-propagator, который > > > > как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в > > > > себе. Новый, правда, интегрирован с основным кодом лучше. > > > Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и > > > network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал > > > на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с > > > нынешним stage2. Если что-то не так приделываю, можно же это предметно > > > обсуждать. Да, я сначала думал делать полный или частичный форк фичи > > > network, потому что были большие сомнения, что удастся с ней > > > интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше > > > похожим на propagator (по возможностям) и удалось обойтись без форка, в > > > отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 > > > -- работает просто идеально. > > Тут надо пояснить, что о работе и интеграции говорилось с учётом ранее > сказанного и того факта, что waitnet времянка снаружи, а не заапстримленный > код внутри make-initrd. При создании waitnet ставилась совершенно > определённая цель и в этом плане она выполнена на 100%, далее объясню, > почему... > > > > К вопросу о ревью: вот и как предполагается комментировать код с git.alt ? > > Ок, буду по ссылкам. > > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l12 > > Уже понял, что лучше отдельными патчами в рассылку. Просто, когда-то давно > ты и так принимал. > > > > Про это я уже писал. Это проверяется не так. > > С has_feature() я разобрался. И в новой версии уже она. Но пока код не > заапстримлен, полагаться на API в make-initrd и тем более привязываться > жёстко к каким-то фичам весьма рисково: любая твоя новая сборка с таким > изменением сможет поломать работу ещё не заапстримленного altboot, поэтому я > иду по пути минимальной привязки на данном этапе. Поэтому и: > > > Остальной интегрируется так, что не использует ничего из того с чем > > интегрируется. > > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l32 > > > > В network-sh-functions есть ipv4_enabled. > > Разумеется, я внимательно изучил код фичи и видел эту функцию. > > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l51 > > > > Теряются абсолютно все ошибки. Ошибки в ip=, в macaddr, в указании масок. > > Вместо всего этого будет "can't reconfigure network settings". Этого быть > > не должно. > > Тут я полностью согласен. Но уже говорил, что код не финальный. waitnet -- > времянка для выяснения конкретной возможности. Если выкинуть этот код, > выкинуть шаг waitnet из цепочки загрузки, все 4 сетевых метода сейчас будут > работать без него. Надо будет указывать ip=dhcp в /proc/cmdline или задавать > другие сетевые настройки. Поэтому отправка в /dev/null сейчас сделана чисто > чтобы не портить внешний вид диалога, наверное, лучше отправлять в 1>&2 в > этом месте. > > > > Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network. > > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 > > > > Этот шаг можно выполнить лишь один раз. > > Не согласен! :-) Ты делаешь внутри условия запись: if [ ! -s "$NETBOOT_IFNAME" ]; then ... echo "$netdev" >"$NETBOOT_IFNAME" fi Больше ты этот файл нигде не пишешь: http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git&a=search&h=0b2522e81ea6279295bae02a8aa77e84c86d3918&st=grep&s=NETBOOT_IFNAME то есть после записи в этот файл этот if никогда больше не выполнится. Этот шаг можно выполнить лишь один раз. > И waitnet демонстрирует это без чистки предыдущей > конфигурации. Объясню почему. Сейчас waitnet смотрит, была ли выполнена > конфигурация. И если конфигурировался только lo, то повторный запуск без > чистки ни на что не повлияет. Он же не создаст дублирующего правила udev, > т.к. перед дёрганием явно задаётся IFNAME="0". > > > > Это не вяжется у меня с > > > > "Can't bridge up network interface. Try with other network settings, wired > > connection and/or cable." > > > > Если пользователь попробует тот же интерфейс с другими настройками, то > > второй раз проверки не будет ??? > > На этом диалоге ранее выполнялся перезапуск машины, в версии 0.1.5-alt3 > решил в этом месте перезапустить altboot -- сейчас тут возврат в начальное > меню, где можно выбрать другой метод загрузки, не по сети. Т.е., прошло 16 > секунд, сеть так и не поднялась. Если этого мало, пользователь дойдёт сюда > снова. Но может и другой путь выбрать для загрузки. > > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l65 > > > > Хардкод имени интерфейса. is_loopback(). > > Не только, это ещё и break loop / защита от пустого каталога. Обычно я тут > ставлю "_". Тогда так и нужно писать: for d in /sys/class/net/*; do [ -d "$d" ] || continue ... done И не нужно отдельно вписывать lo. Он всегда там есть. > > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l67 > > > > Для чего эта проверка ? > > Чтобы предотвратить дальнейшую работу цикла, если мы имеем дело не с сетевым > интерфейсом. В этом каталоге только сетевые интерфейсы. > И ещё проверка того факта, что с момента вышестоящей команды ls > интерфейс не исчез. Это бессмысленно т.к. интерфейс может исчезнуть сразу после этой проверки. > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l73 > > > > Я полагаю это проверка на то что интерфейс поднят ? Если да, то is_link_up > > Если проверка на присутствие адреса, то "/.initrd/online/$NET_IF". > > Да, разумеется, про более тесную интеграцию я уже выше написал. Где-то ранее > мы как раз обсуждали, ты же сам и говорил, что надёжнее не дёргать > внутренности make-initrd, а проверять через ip. Эм. Кажется, ты меня неправильно понял. Где я такое писал ? > waitnet -- "проверка боем" того факта, что внутри make-initrd можно повторно > дёрнуть фичу network, выполнив конфигурирование в том случае, если его ещё > не было, возможность передать ему вполне конкретные настройки. Правильное > название этой фичи -- bootchain-network, правильное название шага с > диалогами (!) -- neconfig или netsetup, основная цель -- "не делать форк > фичи network" достигнута. > > Разумеется, netconfig/netsetup при апстириме нужно будет интегрировать с > фичей network более жёстко, но тогда тебе придётся следить в обеих местах, > чтобы не разъезжалось. Собственно, именно это и было целью эксперимента > "waitnet", и целью одной из так и не состоявшихся встреч -- обсудить > принципиальную возможность интеграции существующих фич с > bootchain/interactive. > > > > > > Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем > > > > его переизобретать. > > > Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа > > > быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы > > > готовимся избавиться от isolinux для legacy/x86, но сколько это будет > > > тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в > > > загрузку и на это приходится ориентироваться, так как если не работает, > > > сразу баг. > > Я уж не знаю вашей кухни, но вообще-то, да, это сразу бага. > > Бага на брэндинг. Он передаёт устаревшие параметры. > > Всё так, но надо учитывать, что их куча, и нет цели и возможности исправить > это всё сразу. Это не оправдание для костылей любой ценой в новом коде. > > [...] > > А тут ты про некую последовательность коммитов говорил, но где они ??? > > Я до сих пор не получил ни одного коммита. Все эти разговоры пустая > > болтовня какая-то. > > И с этим вроде разобрались, а то github, ещё PR какой-то. Я предложил несколько альтернативных вариантов. В целом, github это всё тот же git репозиторий, только в дополнение он сам вызывает некоторые мои тесты. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-24 19:00 ` Alexey Gladkov @ 2021-09-24 20:09 ` Leonid Krivoshein 0 siblings, 0 replies; 33+ messages in thread From: Leonid Krivoshein @ 2021-09-24 20:09 UTC (permalink / raw) To: make-initrd 24.09.2021 22:00, Alexey Gladkov пишет: > On Fri, Sep 24, 2021 at 08:31:50PM +0300, Leonid Krivoshein wrote: >> [...] >>> Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network. >>> >>> http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 >>> >>> Этот шаг можно выполнить лишь один раз. >> Не согласен! :-) > Ты делаешь внутри условия запись: > > if [ ! -s "$NETBOOT_IFNAME" ]; then > ... > echo "$netdev" >"$NETBOOT_IFNAME" > fi > > Больше ты этот файл нигде не пишешь: > > http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git&a=search&h=0b2522e81ea6279295bae02a8aa77e84c86d3918&st=grep&s=NETBOOT_IFNAME > > то есть после записи в этот файл этот if никогда больше не выполнится. > Этот шаг можно выполнить лишь один раз. В коде два if'а -- первый препятствует повторному дёрганью фичи network, второй, про который ты теперь говоришь, чтобы не проверять заново сеть, если ранее эта проверка уже была выполнена. Но и внутри второго if'а есть ещё один if -- если сеть поднялась, только в этом случае создаётся файл, а диалог возникает, если этот if не выполнен. И да, мы можем оказаться в этом месте снова благодаря вызову alboot_restart() -- он заставляет bootchain перезапустить цепочку с самого начала, с шага altboot. Таким образом возникает ситуация, при которой если даже сеть попытались поднять, но она не поднялась, мы можем повторять эту попытку, не дёргая повторно network. На моей памяти только один случай, когда сразу после подключения сети настройки выдавались не менее 20 секунд (битый ethernet кабель). Фактически это место возможности возраста для повторения попытки. Диалог -- о том, что может стоит переткнуть провод в другой штекер или проверить соединение. >> [...] >>> http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l65 >>> >>> Хардкод имени интерфейса. is_loopback(). >> Не только, это ещё и break loop / защита от пустого каталога. Обычно я тут >> ставлю "_". > Тогда так и нужно писать: > > for d in /sys/class/net/*; do > [ -d "$d" ] || continue > ... > done > > И не нужно отдельно вписывать lo. Он всегда там есть. В принципе, вариант, но у меня везде шебанг с set -f. ОК, подумаем над улучшением этого места. Всё равно waitnet не останется в нынешнем виде. -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2021-09-17 22:08 ` Alexey Gladkov 2021-09-19 21:50 ` Leonid Krivoshein @ 2024-03-07 19:18 ` Leonid Krivoshein 2024-03-12 17:42 ` Alexey Gladkov 1 sibling, 1 reply; 33+ messages in thread From: Leonid Krivoshein @ 2024-03-07 19:18 UTC (permalink / raw) To: make-initrd Алексей, привет! On 9/18/21 01:08, Alexey Gladkov wrote: > On Fri, Sep 17, 2021 at 11:48:50PM +0300, Leonid Krivoshein wrote: >> Как ты смотришь на то, чтобы немного расширить список сохраняемых >> DHCP-опций? Предлагаю наряду с rootpath сохранять siaddr (bootp next server) >> и wins (list of WINS servers), что позволит задавать на DHCP-сервере опции >> для сетевой загрузки по протоколам NFS и CIFS. Часть из них уже используется >> для сетевой загрузки в propagator и alterator-netinst наряду с rootpath. > Я совершенно не против. Я не добавлял ничего другого поскольку не нашёл им > применения. Если кому-то нужно больше, то давай добавим больше. Сегодня в task #342271 проверили, это работает. Без этого коммита: https://git.altlinux.org/tasks/342271/gears/100/git?p=git;a=blob;f=0001-network-read-also-siaddr-and-wins-DHCP-options.patch;h=63d5c813a48199a192f07734b8644f34e2f8ea3b;hb=46d250d2677812541f63d59aebeec13aee7e2543 приходится настраивать руками в диалоге. Оказалось, именно этих двух не хватало для полной совместимости с сетевой загрузкой в стиле пропагатора. Как лучше поступить? Может, утащишь этот коммит к себе в for-master? -- WBR, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [make-initrd] udhcpc script в фиче network 2024-03-07 19:18 ` Leonid Krivoshein @ 2024-03-12 17:42 ` Alexey Gladkov 0 siblings, 0 replies; 33+ messages in thread From: Alexey Gladkov @ 2024-03-12 17:42 UTC (permalink / raw) To: make-initrd On Thu, Mar 07, 2024 at 10:18:45PM +0300, Leonid Krivoshein wrote: > Алексей, привет! > > > On 9/18/21 01:08, Alexey Gladkov wrote: > > On Fri, Sep 17, 2021 at 11:48:50PM +0300, Leonid Krivoshein wrote: > >> Как ты смотришь на то, чтобы немного расширить список сохраняемых > >> DHCP-опций? Предлагаю наряду с rootpath сохранять siaddr (bootp next server) > >> и wins (list of WINS servers), что позволит задавать на DHCP-сервере опции > >> для сетевой загрузки по протоколам NFS и CIFS. Часть из них уже используется > >> для сетевой загрузки в propagator и alterator-netinst наряду с rootpath. > > Я совершенно не против. Я не добавлял ничего другого поскольку не нашёл им > > применения. Если кому-то нужно больше, то давай добавим больше. > > Сегодня в task #342271 проверили, это работает. Без этого коммита: > > https://git.altlinux.org/tasks/342271/gears/100/git?p=git;a=blob;f=0001-network-read-also-siaddr-and-wins-DHCP-options.patch;h=63d5c813a48199a192f07734b8644f34e2f8ea3b;hb=46d250d2677812541f63d59aebeec13aee7e2543 > > приходится настраивать руками в диалоге. Оказалось, именно этих двух не > хватало для полной совместимости с сетевой загрузкой в стиле > пропагатора. Как лучше поступить? Может, утащишь этот коммит к себе в > for-master? Извини замотался. Да, заберу. -- Rgrds, legion ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2024-03-12 17:42 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-17 20:48 [make-initrd] udhcpc script в фиче network Leonid Krivoshein 2021-09-17 22:08 ` Alexey Gladkov 2021-09-19 21:50 ` Leonid Krivoshein 2021-09-21 22:51 ` Leonid Krivoshein 2021-09-22 0:16 ` Leonid Krivoshein 2021-09-22 10:01 ` Alexey Gladkov 2021-09-22 10:09 ` Alexey Gladkov 2021-09-22 10:56 ` Leonid Krivoshein 2021-09-22 11:41 ` Alexey Gladkov 2021-09-22 12:06 ` Leonid Krivoshein 2021-09-22 13:08 ` Alexey Gladkov 2021-09-22 14:46 ` Alexey Gladkov 2021-09-22 16:12 ` Leonid Krivoshein 2021-09-22 19:03 ` Alexey Gladkov 2021-09-22 22:06 ` Leonid Krivoshein 2021-09-23 0:45 ` Alexey Gladkov 2021-09-23 2:31 ` Антон Мидюков 2021-09-23 8:59 ` Alexey Gladkov 2021-09-23 20:40 ` Leonid Krivoshein 2021-09-23 21:15 ` Alexey Gladkov 2021-09-23 21:55 ` Arseny Maslennikov 2021-09-23 22:41 ` Alexey Gladkov 2021-09-23 22:51 ` Leonid Krivoshein 2021-09-23 22:56 ` Leonid Krivoshein 2021-09-23 23:31 ` Alexey Gladkov 2021-09-23 2:40 ` Leonid Krivoshein 2021-09-23 11:38 ` Alexey Gladkov 2021-09-24 17:31 ` Leonid Krivoshein 2021-09-24 18:35 ` Leonid Krivoshein 2021-09-24 19:00 ` Alexey Gladkov 2021-09-24 20:09 ` Leonid Krivoshein 2024-03-07 19:18 ` Leonid Krivoshein 2024-03-12 17:42 ` Alexey Gladkov
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git