Если сеть включили, то она и в чруте есть.
Но проблема есть. Когда грузишься с параметром ip=dhcp, в /etc/resolv.conf пусто. Нужно выключить сетевой интерфейс и снова включить:
ifdown имя_интерфейса
ifup имя_интерфейса
Тогда dns-имена становятся доступны.
Сеть поднимается в initrd теперь, когда параметр загрузки ip=dhcp.

Created attachment 16208 [details]
Обновление alt-p10-cinnamon до p11

Если не использовать eepm, то нас предупреждают, что systemd будет вынесен.

(Ответ для Антон Мидюков на комментарий #2)
> Создано вложение 16208 [details] [подробности]
> Обновление alt-p10-cinnamon до p11
> 
> Если не использовать eepm, то нас предупреждают, что systemd будет вынесен.

Не к тому багу приложилось. Извиняюсь.

(In reply to Антон Мидюков from comment #1)
> Когда грузишься с параметром ip=dhcp, в /etc/resolv.conf пусто
Почему? Из-за resolved-stub в m-p? Или в целевом чруте это симлинк куда-то?

См.: https://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=commitdiff;h=e985cacfcde00cbf01cbdea5f37eac0d7c6d0ae3

(Ответ для Leonid Krivoshein на комментарий #4)
> (In reply to Антон Мидюков from comment #1)
> > Когда грузишься с параметром ip=dhcp, в /etc/resolv.conf пусто
> Почему? Из-за resolved-stub в m-p? Или в целевом чруте это симлинк куда-то?

Не знаю почему. resolved-stub не используется в rescue. Проблема не в чруте, а в самом rescue. Не копируется из initrd /etc/resolved.conf

> 
> См.:
> https://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-
> bootchain.git;a=commitdiff;h=e985cacfcde00cbf01cbdea5f37eac0d7c6d0ae3

Видимо, тут что-то не так.

(Ответ для Антон Мидюков на комментарий #5)
> (Ответ для Leonid Krivoshein на комментарий #4)
> > (In reply to Антон Мидюков from comment #1)
> > > Когда грузишься с параметром ip=dhcp, в /etc/resolv.conf пусто
> > Почему? Из-за resolved-stub в m-p? Или в целевом чруте это симлинк куда-то?
> 
> Не знаю почему. resolved-stub не используется в rescue. Проблема не в чруте,
> а в самом rescue. Не копируется из initrd /etc/resolved.conf

/etc/resolv.conf то есть.

Он копируется теперь только если:

- загрузка с make-initrd-bootchain
- загрузка с параметрами пропагатора automatic=...
- загрузка с параметром ip=dhcp, когда активируется фича network
- фича make-initrd что-то записала в этот файл, т.е. он не пустой
- целевое место назначения не должно быть симлинком на другой файл

Это одно из последних действий после наложения оверлея.
Нужно проверить содержимое файла до выхода из initrd.
Может, у legion@ что-то в фиче network поменялось?

(Ответ для Leonid Krivoshein на комментарий #7)
> Он копируется теперь только если:
> 
> - загрузка с make-initrd-bootchain
> - загрузка с параметрами пропагатора automatic=...
> - загрузка с параметром ip=dhcp, когда активируется фича network
> - фича make-initrd что-то записала в этот файл, т.е. он не пустой
> - целевое место назначения не должно быть симлинком на другой файл
> 

Все условия выполнены.

> Это одно из последних действий после наложения оверлея.
> Нужно проверить содержимое файла до выхода из initrd.

Я проверил, файл /etc/resolv.conf не пустой. Я его скопировал в /root/etc/resolv.conf, и всё хорошо стало. Целевой файл не симлинк.

От метода загрузки не зависит? Метод disk.

(In reply to Антон Мидюков from comment #8)
> От метода загрузки не зависит? Метод disk.
Зависит. Если мы грузимся не по сети, то make-initrd-bootchain сеть не использует и её не ждёт. Копирование файла в altboot выполняется фичей bootchain-waitnet, но, так как для загрузки сеть не нужна, фича не задействована. ip= параметр фичи network в самом make-initrd, но он копированием в целевую систему resolv.conf не занимается. Какая-то кривая конфигурация и, по-моему, даже не баг. Зачем вообще нужен ip=, если метод загрузки disk?

(In reply to Leonid Krivoshein from comment #7)
> - загрузка с параметром ip=dhcp, когда активируется фича network
Тут я неправильно написал. Всё же этот параметр важен, чтобы сработала фича bootchain-waitnet, без него сеть не заработает, но в первую очередь должен быть сетевой метод загрузки, который вытянет по зависимости этот bootchain-waitnet.

(Ответ для Leonid Krivoshein на комментарий #9)
> (In reply to Антон Мидюков from comment #8)
> > От метода загрузки не зависит? Метод disk.
> Зависит. Если мы грузимся не по сети, то make-initrd-bootchain сеть не
> использует и её не ждёт. Копирование файла в altboot выполняется фичей
> bootchain-waitnet, но, так как для загрузки сеть не нужна, фича не
> задействована. ip= параметр фичи network в самом make-initrd, но он
> копированием в целевую систему resolv.conf не занимается. Какая-то кривая
> конфигурация и, по-моему, даже не баг. Зачем вообще нужен ip=, если метод
> загрузки disk?

Произошла коллизия между используемыми параметрами загрузки у startup-rescue и make-initrd. Одинаково называется ip. По нему настраивается и поднимается сетевой интерфейс в rescue. Видимо, стоит назвать по-другому.

Но почему бы не делать waitnet всегда, если есть чего ждать?

(In reply to Антон Мидюков from comment #11)
> Произошла коллизия между используемыми параметрами загрузки у startup-rescue
> и make-initrd. Одинаково называется ip.
Не только. Главная и визуально сильно ошущаемая колизия с ядерным одноимённым параметром. На некоторых архитектурах эта коллизия вызывает ещё и очень большие дополнительные задержки, так как ядро пытается чего-то ждать, потом make-initrd, потом уже только дело доходит до stage2 и startup-rescue.

> По нему настраивается и поднимается сетевой интерфейс в rescue.
> Видимо, стоит назвать по-другому.
Тем более, синтаксис несовместим:
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

> Но почему бы не делать waitnet всегда, если есть чего ждать?
Я не уверен, что мы чего-то дождёмся, если всегда ждать, особенно при разнице в синтаксисе, но вылезет ошибка, и мы вообще не загрузимся без поднятой сети. Если бы можно было сделать так, чтобы make-initrd не активировал фичу network в таком сценарии с rescue. Переименовать параметр в startup-rescue кажется лучшим вариантом, и даже к продуктам успеем переименовать в документации.

(In reply to Антон Мидюков from comment #11)
> Но почему бы не делать waitnet всегда, если есть чего ждать?
Если ip=... предназначен для startup-rescue в stage2, поднимать сеть в ядре и в stage1 точно не надо -- ещё один аргумент в пользу того, что здесь не нужно чего-то всегда ожидать.

(Ответ для Leonid Krivoshein на комментарий #13)
> (In reply to Антон Мидюков from comment #11)
> > Но почему бы не делать waitnet всегда, если есть чего ждать?
> Если ip=... предназначен для startup-rescue в stage2, поднимать сеть в ядре
> и в stage1 точно не надо -- ещё один аргумент в пользу того, что здесь не
> нужно чего-то всегда ожидать.

Хорошо. Но может подскажешь как параметр назвать?

(In reply to Антон Мидюков from comment #14)
> как параметр назвать?
На самом деле без разницы, можно network или net для краткости. Не забывать бы тут регистрировать: https://www.altlinux.org/Cmdline и чтобы не конфликтовал с параметрами ядра и systemd.

(In reply to Leonid Krivoshein from comment #15)
> (In reply to Антон Мидюков from comment #14)
> > как параметр назвать?
> На самом деле без разницы, можно network или net для краткости. Не забывать
> бы тут регистрировать: https://www.altlinux.org/Cmdline и чтобы не
> конфликтовал с параметрами ядра и systemd.
Кстати, если сеть в rescue stage2 поднимается только для запуска ssh, я бы все параметры убрал и сделал только один ssh=... (отдельно можно оставить hash=...).

startup-rescue-0.50-alt1 -> sisyphus:

 Mon Jun 03 2024 Anton Midyukov <antohami@altlinux> 0.50-alt1
 - rescue-remote.init: do not require ip=dhcp for run livecd-net-eth
   (Closes: 50526)