From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 22 Sep 2021 16:46:19 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210922144619.3h4va7j4u6m36mka@example.org> References: <20210917220845.s4dgl2hqla7yt4pe@example.org> <5815442b-e5a1-7469-b705-24090749e245@gmail.com> <20210922100901.e5dsw554g6elb3lx@example.org> <52f4526d-7fa7-e0ed-6d2d-12e06f20408c@gmail.com> <20210922114132.yaobsgcz7vrkjgbq@example.org> <8d262440-d8fc-c174-3293-1964e3440617@gmail.com> <20210922130839.b4iwv2arqyggczb3@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [make-initrd] =?utf-8?b?dWRoY3BjIHNjcmlwdCDQsiDRhNC40YfQtSBuZXR3?= =?utf-8?q?ork?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 14:46:20 -0000 Archived-At: List-Archive: 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