Вчера столкнулся, что в chroot отсутствует интернет, а в rescue отсутствует возможность проброса интернета в chroot. Суть моего предложения - это добавить пункт с возможностью проброса в chroot интернет.
Если сеть включили, то она и в чруте есть. Но проблема есть. Когда грузишься с параметром 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)
