[make-initrd] udhcpc script в фиче network

Fri Sep 24 22:00:28 MSK 2021

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