42527 2022-04-21 09:38:21 +0300 заранее сконфигурированный lo мешает созданию нестандартного lo при старте сети 2022-06-21 17:13:02 +0300 1 1 4 Development Sisyphus make-initrd unstable x86_64 Linux CLOSED NOTABUG P5 normal --- 1 asy legion antohami glebfm iv ldv legion placeholder sem vt qa-sisyphus oldest_to_newest 209822 0 asy 2022-04-21 09:38:21 +0300 Сконфигурированный в initrd lo впоследствии мешает создать lo, отличный от обычно используемого. Сначала подумал на etcnet (Bug 42518), но дело, на самом деле, в initrd. С ядром и initrd из p8 lo получается правильный. Вопрос, что с этим делать. lo действительно в initrd нужен? 209827 1 legion 2022-04-21 10:35:31 +0300 Сейчас lo в initrd конфигурирует единый сервис и некоторые фичи зависят от сети как сервиса вообще. Так что выключить его просто, но вот задача при каких условиях его возвращать. Плюс вопрос обратной совместимости. make-initrd конфигурировал lo с самого начала потому что (насколько помню) некоторым становилось не комфортно без него. 2ldv@ Дим, ты не подскажешь насколько утилиты чувствительны к полностью несконфигурированному lo ? 211933 2 legion 2022-06-21 15:52:39 +0300 рабата 211941 3 asy 2022-06-21 16:49:46 +0300 Вот думаю, может действительно фичей считать, а не багой. Интерфейс с TYPE=dummy вроде нормальной заменой для классического lo выглядит, если надо адрес, который не зависит от физических интерфейсов. 211946 4 legion 2022-06-21 17:12:52 +0300 Параметры конфигурации в initrd и в системе могут различаться. Системы конфигурации должны уметь переконфигурировать интерфейсы если они уже есть.