Created attachment 19981 [details] Содержит реализацию функции lock-all-interfaces-name и последовательность действий обновления ядра, не приводящую к ошибке Здравствуйте. При выполнении процедуры обновления ядра помощью команд apt-get update apt-get install update-kernel -y update-kernel -y reboot на некоторых системах возникает критическая ошибка, приводящая к неработоспособности сетевых служб. Данная проблема была зафиксирована в обращении в техническую поддержку "Потеря сети после обновления ядра [#204205]". Выяснилось, что основной причиной является автоматическое переименование сетевых интерфейсов в процессе обновления ядра системы. Это приводит к нарушению конфигурации сетевых служб и потере сетевого подключения после перезагрузки. Для предотвращения ошибки была разработана функция lock-all-interfaces-name, блокирующая переименование сетевых интерфейсов. Последовательность команд, устраняющая ошибку обновления ядра: lock-all-interfaces-name # Блокировка переименования всех сетевых интерфейсов apt-get update apt-get install update-kernel update-kernel reboot Предлагается интегрировать функционал блокировки переименования сетевых интерфейсов непосредственно в команду update-kernel. Это позволит фиксировать имена сетевых интерфейсов на момент начала обновления ядра и автоматически предотвращать переименование сетевых интерфейсов при обновлении ядра. Можно заметить, что непосредственно во время выполнения команды update-kernel исключается возможность изменения количества сетевых интерфейсов или замена сетевых карт в процессе выполнения обновления ядра. - Предлагаемая реализация команды update-kernel обеспечит более надежную и безопасную процедуру обновления системного ядра на большинстве конфигураций, минимизируя риск возникновения проблем с сетевыми службами. Прилагаю скрипт, содержащий реализацию функции lock-all-interfaces-name. -- PS: Предлагаемый вариант функции lock-all-interfaces-name блокирует переименование всех сетевых интерфейсов. Однако, вероятно, имеет смысл фиксировать только физические интерфейсы. Можно, например, так уточнить фильтрацию сетевых интерфейсов: # Получаем список активных «физических» или «предсказуемых» сетевых интерфейсов ip -br link show | \ awk ' $1 ~ /^(en|eth|wl|ppp|sl|sit0)/ && # eno1, eth0, wlan0, ppp0, sl0 $1 != "lo" {print $1} ' | while read -r iface; do # ... обработка интерфейса ... done Это позволит: - Исключить виртуальные и аналогичные интерфейсы - Учитывать только физические сетевые карты -- Спасибо.
С какой версии ядра на какую версию ядра обновились? Какие интерфейсы сменили имена? Вместо udev правила, нужно генерировать link-файлы: https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html На каждый интерфейс нужно генерировать такой файл командой: cat>/etc/systemd/network/$iface.link <<EOF [Match] MACAddress=$mac [Link] Name=$iface EOF Генерировать нужно только на интерфейсы ethernet: en*.
Created attachment 19984 [details] Скрипт для создания systemd link
(Ответ для Антон Мидюков на комментарий #1) > С какой версии ядра на какую версию ядра обновились? Какие интерфейсы > сменили имена? > 6.1.114-un-def-alt0.c10f.2 -> 6.12.51-alt0.c10f.2 "Поломанный" интерфейс: eno1 > Вместо udev правила, нужно генерировать link-файлы: > https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html > > На каждый интерфейс нужно генерировать такой файл командой: > cat>/etc/systemd/network/$iface.link <<EOF > [Match] > MACAddress=$mac > > [Link] > Name=$iface > EOF > > Генерировать нужно только на интерфейсы ethernet: en*. Т.е. это скрипт выполнять ВМЕСТО предложенного НЕПОСРЕДСТВЕННО перед обновлением ядра, верно? Чем это решение лучше?
(Ответ для rsrs на комментарий #3) > (Ответ для Антон Мидюков на комментарий #1) > > С какой версии ядра на какую версию ядра обновились? Какие интерфейсы > > сменили имена? > > > > 6.1.114-un-def-alt0.c10f.2 -> 6.12.51-alt0.c10f.2 > > "Поломанный" интерфейс: eno1 А на какое имя сменилось? > > > Вместо udev правила, нужно генерировать link-файлы: > > https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html > > > > На каждый интерфейс нужно генерировать такой файл командой: > > cat>/etc/systemd/network/$iface.link <<EOF > > [Match] > > MACAddress=$mac > > > > [Link] > > Name=$iface > > EOF > > > > Генерировать нужно только на интерфейсы ethernet: en*. > > Т.е. это скрипт выполнять ВМЕСТО предложенного НЕПОСРЕДСТВЕННО перед > обновлением ядра, верно? > Эти link файлы нужно один раз создать, желательно сразу после установки системы. И добавлять link-файлы по мере появления новых сетевых карт. > Чем это решение лучше? Тем, что это штатное решение для фиксации имён сетевых интерфейсов в udev. Кроме того, вы зачем-то предлагаете фиксировать вообще все сетевые интерфейсы, что не требуется, и может быть даже вредно.
(Ответ для Антон Мидюков на комментарий #4) > (Ответ для rsrs на комментарий #3) > > (Ответ для Антон Мидюков на комментарий #1) > > > С какой версии ядра на какую версию ядра обновились? Какие интерфейсы > > > сменили имена? > > > > > > > 6.1.114-un-def-alt0.c10f.2 -> 6.12.51-alt0.c10f.2 > > > > "Поломанный" интерфейс: eno1 > > А на какое имя сменилось? Сейчас не могу сказать. Мб. получится повторить позже. > > > > > > Вместо udev правила, нужно генерировать link-файлы: > > > https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html > > > > > > На каждый интерфейс нужно генерировать такой файл командой: > > > cat>/etc/systemd/network/$iface.link <<EOF > > > [Match] > > > MACAddress=$mac > > > > > > [Link] > > > Name=$iface > > > EOF > > > Ок, спасибо. > > > Генерировать нужно только на интерфейсы ethernet: en*. Кстати, возможно же именование и eth*, в том числе (https://www.altlinux.org/NetworkDevicesName)? Именно поэтому была сделана попытка захватить более широкий диапазон именования интерфейсов. Хотя, согласен, может быть избыточно "широко". > > > > Т.е. это скрипт выполнять ВМЕСТО предложенного НЕПОСРЕДСТВЕННО перед > > обновлением ядра, верно? > > > > Эти link файлы нужно один раз создать, желательно сразу после установки > системы. И добавлять link-файлы по мере появления новых сетевых карт. > > > > Чем это решение лучше? > > Тем, что это штатное решение для фиксации имён сетевых интерфейсов в udev. Ок, попробую этот вариант после праздников. > Кроме того, вы зачем-то предлагаете фиксировать вообще все сетевые > интерфейсы, что не требуется Хотелось сделать максимально универсальное решение, захватывающие все возможные варианты именования - "сделал и забыл". Хотя, повторюсь, может быть, действительно, достаточно только фильтровать en* и eth*. >, и может быть даже вредно. Да, возможно Вы правы. -- Собственно, основной посыл этого обращения состоял в избавлении пользователя от необходимости предпринимать какие-то действия для предотвращения возможной критической ошибки при обновлении ядра. Обновление ядра из коробки не должно непредсказуемо ломать сетевую подсистему, даже в отдельных случаях. Поэтому, думаю, было бы правильно либо интегрировать в функционал команды update-kernel предварительную блокировку имён интерфейсов, либо решить это каким-то иным способом в процедуре обновления ядра, чтобы пользователи совершенно неожиданно на длительное время не оставались с мёртвой системой в поисках скорейшего устранения проблемы (как это произошло в моём случае). -- Ещё раз спасибо.
Здравствуйте. > > > > "Поломанный" интерфейс: eno1 > > А на какое имя сменилось? > Нашёл логи. Переименование: eno1 -> eno1np0 Из логов перед обновлением ядра: --- Все сетевые интерфейсы --- 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:72:31:06 brd ff:ff:ff:ff:ff:ff altname enp26s0f0 3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:72:31:07 brd ff:ff:ff:ff:ff:ff altname enp26s0f1 После обновления ядра: --- Все сетевые интерфейсы --- 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:72:31:06 brd ff:ff:ff:ff:ff:ff altname enp26s0f0np0 3: eno2np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:72:31:07 brd ff:ff:ff:ff:ff:ff altname enp26s0f1np1 Более полные логи, собранные перед и после обновления ядра можно найти во вложении к обращению в ТП "Потеря сети после обновления ядра [#204205]".
(Ответ для Антон Мидюков на комментарий #1) > С какой версии ядра на какую версию ядра обновились? Какие интерфейсы > сменили имена? > > Вместо udev правила, нужно генерировать link-файлы: > https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html > > На каждый интерфейс нужно генерировать такой файл командой: > cat>/etc/systemd/network/$iface.link <<EOF > [Match] > MACAddress=$mac > > [Link] > Name=$iface > EOF > > Генерировать нужно только на интерфейсы ethernet: en*. Это решение не сработало. При наличии созданных link-файлов после перезагрузки сеть недоступна. Т.е. на текущий момент вариант с функцией lock-all-interfaces-name является единственно рабочим.
Если в этом есть необходимость, в течение некоторого ближайшего времени у меня есть возможность воспроизвести ситуацию с ошибкой обновления ядра и собрать необходимую дополнительную отладочную информацию до и после обновления. Если такая потребность имеется - пришлите необходимые диагностические скрипты и инструкцию с последовательностью их выполнения. В любом случае, дайте, пожалуйста, знать держать ли мне некоторое время сервер под отладку или отдавать его в эксплуатацию с применением функции lock-all-interfaces-name перед обновлением ядра, после чего воспроизвести проблему уже не получится.
(Ответ для rsrs на комментарий #7) > (Ответ для Антон Мидюков на комментарий #1) > > С какой версии ядра на какую версию ядра обновились? Какие интерфейсы > > сменили имена? > > > > Вместо udev правила, нужно генерировать link-файлы: > > https://www.freedesktop.org/software/systemd/man/latest/systemd.link.html > > > > На каждый интерфейс нужно генерировать такой файл командой: > > cat>/etc/systemd/network/$iface.link <<EOF > > [Match] > > MACAddress=$mac > > > > [Link] > > Name=$iface > > EOF > > > > Генерировать нужно только на интерфейсы ethernet: en*. > > Это решение не сработало. При наличии созданных link-файлов после > перезагрузки сеть недоступна. > > Т.е. на текущий момент вариант с функцией lock-all-interfaces-name является > единственно рабочим. Покажите link-файлы.
Created attachment 19991 [details] eno1.link eno2.link
> Покажите link-файлы. Приложил выше
Created attachment 19993 [details] функция create-persistent-network-interface-names
Такой вариант сработал, сеть после обновления ядра не сломалась: function create-persistent-network-interface-names () { # Bind network interface names of ethernet to MAC addresses ip -br link show | grep -E '^(en|eth)' | awk '{print $1}' | while read -r iface; do local mac=$(ip -br link show "$iface" 2>/dev/null | awk '{print $3}') [ -n "$mac" ] || continue cat >/etc/systemd/network/10-$iface.link <<-EOF [Match] MACAddress=$mac [Link] Name=$iface EOF done }
(Ответ для rsrs на комментарий #13) > Такой вариант сработал, сеть после обновления ядра не сломалась: > > function create-persistent-network-interface-names () { > # Bind network interface names of ethernet to MAC addresses > ip -br link show | grep -E '^(en|eth)' | awk '{print $1}' | while read > -r iface; do > local mac=$(ip -br link show "$iface" 2>/dev/null | awk '{print $3}') > [ -n "$mac" ] || continue > cat >/etc/systemd/network/10-$iface.link <<-EOF > [Match] > MACAddress=$mac > > [Link] > Name=$iface > EOF > done > } То есть помогло переименование link файлов (добавлена приставка 10-)? Сохранять имена eth* не нужно, потому что их не может быть.
(Ответ для Антон Мидюков на комментарий #14) > (Ответ для rsrs на комментарий #13) > > Такой вариант сработал, сеть после обновления ядра не сломалась: > > > > function create-persistent-network-interface-names () { > > # Bind network interface names of ethernet to MAC addresses > > ip -br link show | grep -E '^(en|eth)' | awk '{print $1}' | while read > > -r iface; do > > local mac=$(ip -br link show "$iface" 2>/dev/null | awk '{print $3}') > > [ -n "$mac" ] || continue > > cat >/etc/systemd/network/10-$iface.link <<-EOF > > [Match] > > MACAddress=$mac > > > > [Link] > > Name=$iface > > EOF > > done > > } > > То есть помогло переименование link файлов (добавлена приставка 10-)? > Сохранять имена eth* не нужно, потому что их не может быть. Да, по совету ТП ;)
(Ответ для Антон Мидюков на комментарий #14) > (Ответ для rsrs на комментарий #13) > > Такой вариант сработал, сеть после обновления ядра не сломалась: > > > > function create-persistent-network-interface-names () { > > # Bind network interface names of ethernet to MAC addresses > > ip -br link show | grep -E '^(en|eth)' | awk '{print $1}' | while read > > -r iface; do > > local mac=$(ip -br link show "$iface" 2>/dev/null | awk '{print $3}') > > [ -n "$mac" ] || continue > > cat >/etc/systemd/network/10-$iface.link <<-EOF > > [Match] > > MACAddress=$mac > > > > [Link] > > Name=$iface > > EOF > > done > > } > > То есть помогло переименование link файлов (добавлена приставка 10-)? > Сохранять имена eth* не нужно, потому что их не может быть. Но, конечно, этот скрипт - просто костыль. На самом деле нужно чинить команду update-kernel. Обновление ядра, переименовывающее интерфейсы и не корректирующее все соответствующие зависимости в системе нельзя назвать корректным.
(Ответ для rsrs на комментарий #16) > (Ответ для Антон Мидюков на комментарий #14) > > (Ответ для rsrs на комментарий #13) > > > Такой вариант сработал, сеть после обновления ядра не сломалась: > > > > > > function create-persistent-network-interface-names () { > > > # Bind network interface names of ethernet to MAC addresses > > > ip -br link show | grep -E '^(en|eth)' | awk '{print $1}' | while read > > > -r iface; do > > > local mac=$(ip -br link show "$iface" 2>/dev/null | awk '{print $3}') > > > [ -n "$mac" ] || continue > > > cat >/etc/systemd/network/10-$iface.link <<-EOF > > > [Match] > > > MACAddress=$mac > > > > > > [Link] > > > Name=$iface > > > EOF > > > done > > > } > > > > То есть помогло переименование link файлов (добавлена приставка 10-)? > > Сохранять имена eth* не нужно, потому что их не может быть. > > Но, конечно, этот скрипт - просто костыль. > > На самом деле нужно чинить команду update-kernel. Обновление ядра, > переименовывающее интерфейсы и не корректирующее все соответствующие > зависимости в системе нельзя назвать корректным. update-kernel тут ни при чём. Этот скрипт стоит в конце установки выполнять. Такой перескок может происходить при смене драйверов. Предполагаю, что имя интерфейсов поменялось из-за того, что в ядре 6.1 использовался сторонний модуль сети ixgbe, а в 6.12 апстримный.
(Ответ для Антон Мидюков на комментарий #17) > > update-kernel тут ни при чём. Этот скрипт стоит в конце установки выполнять. Да, сейчас так и сделаю. > > Такой перескок может происходить при смене драйверов. > Предполагаю, что имя интерфейсов поменялось из-за того, что в ядре 6.1 > использовался сторонний модуль сети ixgbe, а в 6.12 апстримный. Да, вероятно. Но для пользователя это выглядит так, что "update-kernel вдруг поломал систему". Поэтому если известен вариант поломки и способ её устранения, то необходимо фиксить именно действия в модуле update-kernel, чтобы пользователь и не догадывался о том, "что имя интерфейсов поменялось из-за того, что в ядре 6.1 > использовался сторонний модуль сети ixgbe, а в 6.12 апстримный". Пользователю нужна исправная система, а не объяснения причины поломки и поиск способа решения в то время, как разработчику этот способ в данном случае уже известен.
(In reply to rsrs from comment #18) > Да, вероятно. Но для пользователя это выглядит так, что "update-kernel вдруг > поломал систему". Здесь пользователь = администратор, который в исходной заявке РМ утверждал, что это произошло на одной машине и не случилось на трёх других. Так надо просто разобраться в причинах, они явно не в дистрибутиве. Начните с того, что сравните пакетную базу на предмет udev rules, посмотрите настройки именования в systemd. Лично я тут ошибки не вижу. Ошибка на ядро? Нет, ваш dmesg подтвердит, что оно не имеет никакого отношения к переименованию интерфейсов. Их переименовывает systemd или udevd, в зависимости от настроек. Именно в них отличия. Менялось ядро, менялись systemd и udevd, но если почитать документацию и настроить всё изначально так, чтобы ничего при обновлении не переименовывалось, никаких дополнительных костылей не потребуется.
(Ответ для Leonid Krivoshein на комментарий #19) > (In reply to rsrs from comment #18) > > Да, вероятно. Но для пользователя это выглядит так, что "update-kernel вдруг > > поломал систему". > Здесь пользователь = администратор, который в исходной заявке РМ утверждал, > что это произошло на одной машине и не случилось на трёх других. Так надо > просто разобраться в причинах, они явно не в дистрибутиве. Проблемы явно в либо в дистрибутиве, либо в реализации команды update-kernel. Это следует из того, что на всех 4-х компьютерах 1. установка ОС выполнялась из ОДНОГО и ТОГО же ISO-образа дистрибутива Альт СП Сервер 10.2 с ИДЕНТИЧНЫМ выбором параметров в мастере установки ОС. 2. На всех свежеустановленных ОС не было выполнено НИКАКИХ изменений, КРОМЕ установки пакета timeshift. После чего на каждом компьютере выполнена последовательность: apt-get update apt-get install update-kernel -y update-kernel -y reboot После выполнения такой последовательности обновления ядра и перезагрузки на одной из 4-х машин сеть оказывается неработоспособной. Только фиксация имён сетевых интерфейсов перед обновлением ядра устраняет проблему. > Начните с того, > что сравните пакетную базу на предмет udev rules, посмотрите настройки > именования в systemd. > > Лично я тут ошибки не вижу. Ошибка на ядро? Нет, ваш dmesg подтвердит, что > оно не имеет никакого отношения к переименованию интерфейсов. Их > переименовывает systemd или udevd, в зависимости от настроек. Именно в них > отличия. Менялось ядро, менялись systemd и udevd, но если почитать > документацию и настроить всё изначально так, чтобы ничего при обновлении не > переименовывалось, никаких дополнительных костылей не потребуется. Повторюсь ещё раз. Никаких изменений в ОС после её установки с моей стороны не производилось - мной НИЧЕГО не настраивалось. (*) Выполнено только лишь apt-get update apt-get install timeshift apt-get install update-kernel update-kernel reboot ВСЁ! Т.е. совокупность (Установка из одного браза ОС)+timeshift+update-kernel+update-kernel на одной машине из 4-х приводит к поломке сети. Влияние администратора (моё) состоит лишь в последовательном запуске (*).
(Ответ для rsrs на комментарий #20) > (Ответ для Leonid Krivoshein на комментарий #19) > > (In reply to rsrs from comment #18) > > > Да, вероятно. Но для пользователя это выглядит так, что "update-kernel вдруг > > > поломал систему". > > Здесь пользователь = администратор, который в исходной заявке РМ утверждал, > > что это произошло на одной машине и не случилось на трёх других. Так надо > > просто разобраться в причинах, они явно не в дистрибутиве. > > Проблемы явно в либо в дистрибутиве, либо в реализации команды update-kernel. > > Это следует из того, что на всех 4-х компьютерах > 1. установка ОС выполнялась из ОДНОГО и ТОГО же ISO-образа дистрибутива Альт > СП Сервер 10.2 с ИДЕНТИЧНЫМ выбором параметров в мастере установки ОС. > 2. На всех свежеустановленных ОС не было выполнено НИКАКИХ изменений, КРОМЕ > установки пакета timeshift. После чего на каждом компьютере выполнена > последовательность: > apt-get update > apt-get install update-kernel -y > update-kernel -y > reboot > > После выполнения такой последовательности обновления ядра и перезагрузки на > одной из 4-х машин сеть оказывается неработоспособной. Только фиксация имён > сетевых интерфейсов перед обновлением ядра устраняет проблему. > > > Начните с того, > > что сравните пакетную базу на предмет udev rules, посмотрите настройки > > именования в systemd. > > > > Лично я тут ошибки не вижу. Ошибка на ядро? Нет, ваш dmesg подтвердит, что > > оно не имеет никакого отношения к переименованию интерфейсов. Их > > переименовывает systemd или udevd, в зависимости от настроек. Именно в них > > отличия. Менялось ядро, менялись systemd и udevd, но если почитать > > документацию и настроить всё изначально так, чтобы ничего при обновлении не > > переименовывалось, никаких дополнительных костылей не потребуется. > > Повторюсь ещё раз. Никаких изменений в ОС после её установки с моей стороны > не производилось - мной НИЧЕГО не настраивалось. > (*) Выполнено только лишь > apt-get update > apt-get install timeshift > apt-get install update-kernel > update-kernel > reboot > > ВСЁ! > > Т.е. совокупность (Установка из одного браза > ОС)+timeshift+update-kernel+update-kernel на одной машине из 4-х приводит к > поломке сети. > > Влияние администратора (моё) состоит лишь в последовательном запуске (*). Сетевая карта на данной машине какая? А какие на тех?
Я вполне допускаю, что проблема не частая и с трудом мб воспроизводима на стенде. В этом случае одним из простейших решений видится, как минимум, пятистрочное дополнение программы update-kernel, выполняющая блокировку переименования сетевых интерфейсов перед запуском основного функционала программы.
(Ответ для Антон Мидюков на комментарий #21) > (Ответ для rsrs на комментарий #20) > > (Ответ для Leonid Krivoshein на комментарий #19) > > > (In reply to rsrs from comment #18) > > > > Да, вероятно. Но для пользователя это выглядит так, что "update-kernel вдруг > > > > поломал систему". > > > Здесь пользователь = администратор, который в исходной заявке РМ утверждал, > > > что это произошло на одной машине и не случилось на трёх других. Так надо > > > просто разобраться в причинах, они явно не в дистрибутиве. > > > > Проблемы явно в либо в дистрибутиве, либо в реализации команды update-kernel. > > > > Это следует из того, что на всех 4-х компьютерах > > 1. установка ОС выполнялась из ОДНОГО и ТОГО же ISO-образа дистрибутива Альт > > СП Сервер 10.2 с ИДЕНТИЧНЫМ выбором параметров в мастере установки ОС. > > 2. На всех свежеустановленных ОС не было выполнено НИКАКИХ изменений, КРОМЕ > > установки пакета timeshift. После чего на каждом компьютере выполнена > > последовательность: > > apt-get update > > apt-get install update-kernel -y > > update-kernel -y > > reboot > > > > После выполнения такой последовательности обновления ядра и перезагрузки на > > одной из 4-х машин сеть оказывается неработоспособной. Только фиксация имён > > сетевых интерфейсов перед обновлением ядра устраняет проблему. > > > > > Начните с того, > > > что сравните пакетную базу на предмет udev rules, посмотрите настройки > > > именования в systemd. > > > > > > Лично я тут ошибки не вижу. Ошибка на ядро? Нет, ваш dmesg подтвердит, что > > > оно не имеет никакого отношения к переименованию интерфейсов. Их > > > переименовывает systemd или udevd, в зависимости от настроек. Именно в них > > > отличия. Менялось ядро, менялись systemd и udevd, но если почитать > > > документацию и настроить всё изначально так, чтобы ничего при обновлении не > > > переименовывалось, никаких дополнительных костылей не потребуется. > > > > Повторюсь ещё раз. Никаких изменений в ОС после её установки с моей стороны > > не производилось - мной НИЧЕГО не настраивалось. > > (*) Выполнено только лишь > > apt-get update > > apt-get install timeshift > > apt-get install update-kernel > > update-kernel > > reboot > > > > ВСЁ! > > > > Т.е. совокупность (Установка из одного браза > > ОС)+timeshift+update-kernel+update-kernel на одной машине из 4-х приводит к > > поломке сети. > > > > Влияние администратора (моё) состоит лишь в последовательном запуске (*). > > Сетевая карта на данной машине какая? А какие на тех? Сетевые карты разные. Если нужно, я могу выполнить требуемые действия по сбору информации об оборудовании на всех 4-х серверах.
(Ответ для rsrs на комментарий #23) > (Ответ для Антон Мидюков на комментарий #21) > > Сетевая карта на данной машине какая? А какие на тех? > > Сетевые карты разные. > > Если нужно, я могу выполнить требуемые действия по сбору информации об > оборудовании на всех 4-х серверах. Предоставьте, пожалуйста, вывод команды: lspci -vvk
Created attachment 20032 [details] Вывод lspci -vvk для 4-х машин
(Ответ для rsrs на комментарий #25) > Создано вложение 20032 [details] [подробности] > Вывод lspci -vvk для 4-х машин data2.lspci-vvk.log - лог с проблемной машины
Возможно позволит понять, что случилось, следующее: Со старым ядром: # udevadm test-builtin net_id /sys/class/net/eno1 # udevadm test-builtin net_id /sys/class/net/eno2 И с новым: # udevadm test-builtin net_id /sys/class/net/eno1np0 # udevadm test-builtin net_id /sys/class/net/eno2np1
(Ответ для Антон Мидюков на комментарий #27) > Возможно позволит понять, что случилось, следующее: Возможно это и позволило бы. Но так долго держать сервер в тестовом режиме было нельзя, поэтому сервер уже отдан в эксплуатацию и посмотреть на его состояние со старым ядром уже не получится. Могу лишь отметить, что достаточно большой объём файлов с логам перед обновлением ядра и после, собранный на проблемной машине, находится в обращении в техническую поддержку "Потеря сети после обновления ядра [#204205]". Там можно найти подробную информацию. > > Со старым ядром: > # udevadm test-builtin net_id /sys/class/net/eno1 > # udevadm test-builtin net_id /sys/class/net/eno2 > > > И с новым: > # udevadm test-builtin net_id /sys/class/net/eno1np0 > # udevadm test-builtin net_id /sys/class/net/eno2np1
(In reply to rsrs from comment #23) > Сетевые карты разные. Различия могут быть как в оборудовании, так и в настройках. > Если нужно, я могу выполнить требуемые действия по сбору информации об > оборудовании на всех 4-х серверах. Я смотрел эту заявку и видел, что она не доработана. Вы (и мы) не доразобрались в причинах, а это первоочередное. Болячки полагается лечить, когда диагноз известен. Нужно сравнить две ситуации, два отчёта sosreport.
(Ответ для Leonid Krivoshein на комментарий #29) > (In reply to rsrs from comment #23) > > Сетевые карты разные. > Различия могут быть как в оборудовании, так и в настройках. > > > Если нужно, я могу выполнить требуемые действия по сбору информации об > > оборудовании на всех 4-х серверах. > Я смотрел эту заявку и видел, что она не доработана. Вы (и мы) не > доразобрались в причинах, а это первоочередное. Болячки полагается лечить, > когда диагноз известен. Нужно сравнить две ситуации, два отчёта sosreport. Сервер уже в эксплуатации. Есть шанс забрать его на минимальное время для тестирования. Поэтому нужна подробная инструкция без необходимости уточнений в ходе её исполнения — чтобы успеть собрать все данные в ограниченное время.
(Ответ для Leonid Krivoshein на комментарий #29) > (In reply to rsrs from comment #23) > > Сетевые карты разные. > Различия могут быть как в оборудовании, так и в настройках. > > > Если нужно, я могу выполнить требуемые действия по сбору информации об > > оборудовании на всех 4-х серверах. > Я смотрел эту заявку и видел, что она не доработана. Вы (и мы) не > доразобрались в причинах, а это первоочередное. Болячки полагается лечить, > когда диагноз известен. Нужно сравнить две ситуации, два отчёта sosreport. Обнаружилось любопытное ;) Логи ввиду размера прикрепить не удалось, поэтому ссылка вложения к этому сообщению: https://disk.yandex.ru/d/PL0_uTbMkMsezw Если обновлять ядро непосредственно из репозиториев с зеркал Альта, то ядро 6.12 не предлагается к установке. Во вложении лог "repo update.altsp.su-ALTLinux-c10f2.log" -- Если обновлять ядро из локального зеркала репозитория, то ядро обновляется до 6.12. Во вложении: - лог "repo 192.168.0.21-mirror c10f2.log" - папка "192.168.0.21-mirror c10f2" с настройками и логами локального зеркала репозитория -- Во вложении: Скрипты - "01 install timeshift.sh": выполнен непосредственно после установки ОС - "02 update-kernel.sh": выполнен непосредственно после "01 install timeshift.sh" В папке "-update-kernel-error-logs-" - логи, собранные до обновления ядра - логи, собранные после обновления ядра перед перезагрузкой - логи, собранные после обновления ядра после перезагрузки
(In reply to rsrs from comment #31) > Если обновлять ядро непосредственно из репозиториев с зеркал Альта, то ядро > 6.12 не предлагается к установке. На эту тему стоит завести отдельный баг с шагами воспроизведения. Лог вывода не соответсвует скрипту, вывод apt-repo в логах не показан. По командам кажется, что добавляется репозиторий rsync: это значит, что список репозиториев был пуст перед этим либо выполняется смешение репозиториев, что недопустимо, даже с репозиторием диска. Вполне возможно, что update-kernel и не рассчитана на rsync. Тем не менее, в определённом окружении мне удалось добиться странного поведения update-kernel в результате которого ядро un-def не обновляется на 6.12. Что-то из окружения влияло на make-initrd, который ругался вылетая, но это не отрабатывало как ошибка в update-kernel. Помогало решить проблему предварительное перемонтирование /tmp с опцией exec.
А в логе "01 install timeshift.log" показан полный вывод, по нему уже понятней, но вот это точно ошибка: # apt-repo rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64 classic gostcrypto rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64-i586 classic rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/noarch classic rpm cdrom:[ALT SP Server 10.2 11100-01 x86_64 build 2024-11-27]/ ALTLinux main Смешение репозиториев, не учтена особенность дистрибутива, не выполнено переключение на Интернет репозиторий с репозитория диска, где одновременно меняется disttag для многих уже установленных пакетов.
(Ответ для Leonid Krivoshein на комментарий #33) > А в логе "01 install timeshift.log" показан полный вывод, по нему уже > понятней, но вот это точно ошибка: > > # apt-repo > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64 classic > gostcrypto > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64-i586 classic > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/noarch classic > rpm cdrom:[ALT SP Server 10.2 11100-01 x86_64 build 2024-11-27]/ ALTLinux > main > > Смешение репозиториев, не учтена особенность дистрибутива, не выполнено > переключение на Интернет репозиторий с репозитория диска, где одновременно > меняется disttag для многих уже установленных пакетов. Там нет физически ни dvd-привода, ни собственно диска, поэтому смешения быть не может.
(Ответ для Leonid Krivoshein на комментарий #33) > А в логе "01 install timeshift.log" показан полный вывод, по нему уже > понятней, но вот это точно ошибка: > > # apt-repo > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64 classic > gostcrypto > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/x86_64-i586 classic > rpm [cert8] rsync://update.altsp.su/ALTLinux c10f2/branch/noarch classic > rpm cdrom:[ALT SP Server 10.2 11100-01 x86_64 build 2024-11-27]/ ALTLinux > main > > Смешение репозиториев, не учтена особенность дистрибутива, не выполнено > переключение на Интернет репозиторий с репозитория диска, где одновременно > меняется disttag для многих уже установленных пакетов. Думаю завтра попробовать варианты на виртуальной машине.
По логам уже почти всё понятно, но лучше всего дать такую команду: su- export SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/eno1np0 Именно в таком варианте она покажет не только получившиеся значения, но и причины их получения. Сравнивать надо только после обновления на двух машинах. Так мы увидим, почему не отрабатывает NamePolicy=keep, введённая в v241.
Приведу здесь выжимку из логов... 99-default.link (не отличается): [Match] OriginalName=* [Link] NamePolicy=keep kernel database onboard slot path AlternativeNamesPolicy=database onboard slot path MACAddressPolicy=persistent Внутриядерные зависимости модуля (не отличаются): kernel/drivers/net/ethernet/intel/i40e/i40e.ko: kernel/drivers/infiniband/hw/irdma/irdma.ko: kernel/drivers/net/ethernet/intel/i40e/i40e.ko kernel/drivers/net/ethernet/intel/ice/ice.ko kernel/drivers/infiniband/core/ib_uverbs.ko kernel/drivers/infiniband/core/ib_core.ko udev/systemd без отличий: libgudev-237-alt1.x86_64 libudev1-249.17-alt3.x86_64 systemd-249.17-alt3.x86_64 udev-249.17-alt3.x86_64 udev-rules-hotplug-cpu-1.0-alt1.noarch udev-rules-sgutils-1.47-alt1.noarch Кроме последнего, после обновления: udev-rules-sgutils-1.48-alt1.c10.1.noarch Всё остальное отличается... Ядро до: 6.1.114-un-def-alt0.c10f.2 Ядро после: 6.12.56-6.12-alt0.c10f.2 lsmod до: i40e 520192 1 irdma lsmod после: i40e 593920 1 irdma libie 8192 2 i40e,ice udevadm test-builtin net_id ... |grep ID_ до: ID_NET_NAMING_SCHEME=v249 ID_NET_NAME_MAC=enx3cecef723106 ID_OUI_FROM_DATABASE=Super Micro Computer, Inc. ID_NET_NAME_ONBOARD=eno1 ID_NET_LABEL_ONBOARD=Intel LAN X557 #1 ID_NET_NAME_PATH=enp26s0f0 udevadm test-builtin net_id ... |grep ID_ после: ID_NET_NAMING_SCHEME=v249 ID_NET_NAME_MAC=enx3cecef723106 ID_OUI_FROM_DATABASE=Super Micro Computer, Inc. ID_NET_NAME_ONBOARD=eno1np0 ID_NET_LABEL_ONBOARD=Intel LAN X557 #1 ID_NET_NAME_PATH=enp26s0f0np0 $ ip addr show dev eno1 |head -n3 до: 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 3c:ec:ef:72:31:06 brd ff:ff:ff:ff:ff:ff altname enp26s0f0 $ ip addr show dev eno1np0 |head -n3 после: 2: eno1np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 3c:ec:ef:72:31:06 brd ff:ff:ff:ff:ff:ff altname enp26s0f0np0 То есть, версии udev и systemd не изменились, не поменялась политика наименования, в плохом случае политика keep почему-то не отработала, но видимо отработала какая-то из следующих за ней. Например, если ядро утверждает, что выдаёт предсказуемое имя, могла отработать политика kernel. Но по dmesg видно, что ядро дало имя eth0, переименование произошло уже после запуска systemd на 27-й секунде загрузки. Ядро у нас действительно поменялось и оно стало дополнительно сообщать через sysfs имя физического порта (np0). Вот что об этом сказано в документации: When creating names for network cards, some naming schemes use data from sysfs populated by the kernel. This means that although a specific naming scheme in udev(7) is picked, the network card's name can still change when a new kernel version adds a new sysfs attribute. For example, if kernel starts setting the phys_port_name, udev will append the "nphys_port_name" suffix to the device name. Можно ограничинить получение дополнительных атрибутов в sysfs через /etc/udev/hwdb.d/50-net-naming-allowlist.hwdb и /etc/udev/hwdb.d/50-net-naming-denylist.hwdb, как это сделать говорится здесь: https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html . Зачем-то копируется 99-default.link, хотя он есть в c10f2 в составе udev. Осталось понять, почему в плохом случае политика отрабатывает именно так, а не иначе, как предлагалось в предыдущем комментарии. Также нужно будет внимательней изучить содержимое /etc/udev/hwdb.d/, оно не попало в sosreport. Забегая вперёд: то, что пытаетесь реализовать, это политика mac, которую задвинули аж на последнее место. Есть много причин на неё не ориентироваться. Да и вообще в этом багрепорте речь идёт об изобретении того, что уже сделано в systemd штатными средствами.
https://github.com/flatcar/Flatcar/issues/36#issuecomment-595249283 -- к слову, были в 2020 подобные жалобы, всё давно исправили, т.е. с v240 схемы именования должны работать. Как раз нужно пригледеться к отладочному выводу вида "Device already has a name given by userspace, not renaming", возможно проблема как раз в том, что отрабатывает keep сразу с новым значением.
https://github.com/systemd/systemd/issues/9006#issuecomment-389928989 -- и забегая совсем вперёд, тут больше для Антона: у нас нет systemd в initrd, но если переименование кто-то делает там, например, с dracut, то все созданные .link файлы тоже должны попасть в stage1 при его генерации.
(Ответ для Leonid Krivoshein на комментарий #36) > По логам уже почти всё понятно, но лучше всего дать такую команду: > > su- > export SYSTEMD_LOG_LEVEL=debug > udevadm test-builtin net_setup_link /sys/class/net/eno1np0 > > Именно в таком варианте она покажет не только получившиеся значения, но и > причины их получения. Сравнивать надо только после обновления на двух > машинах. Так мы увидим, почему не отрабатывает NamePolicy=keep, введённая в > v241. Уточните, пожалуйста, о каких двух машинах идёт речь? Проблемной и беспроблемной? Собрать эту информацию после обновления ядра до перезагрузки или после?
(Ответ для Leonid Krivoshein на комментарий #39) > https://github.com/systemd/systemd/issues/9006#issuecomment-389928989 -- и > забегая совсем вперёд, тут больше для Антона: у нас нет systemd в initrd, но > если переименование кто-то делает там, например, с dracut, то все созданные > .link файлы тоже должны попасть в stage1 при его генерации. В initrd модули ядра для поддержки сети не попадают. dracut не используется.
>Ядро у нас действительно поменялось и оно стало дополнительно сообщать через sysfs имя физического порта (np0). Ну вот и причина. Я бы хотел понять, поменялся используемый драйвер сети со стороннего на апстримный или нет.
Created attachment 20049 [details] Логи после обновления ядра перед перезагрузкой
Created attachment 20050 [details] Логи после обновления ядра после перезагрузки
(Ответ для Leonid Krivoshein на комментарий #36) > По логам уже почти всё понятно, но лучше всего дать такую команду: > > su- > export SYSTEMD_LOG_LEVEL=debug > udevadm test-builtin net_setup_link /sys/class/net/eno1np0 > > Именно в таком варианте она покажет не только получившиеся значения, но и > причины их получения. Сравнивать надо только после обновления на двух > машинах. Так мы увидим, почему не отрабатывает NamePolicy=keep, введённая в > v241. Выложил after-update-kernel-after-reboot-20251112-095435.7z after-update-kernel-before-reboot-20251112-094917.7z
(Ответ для Антон Мидюков на комментарий #42) > >Ядро у нас действительно поменялось и оно стало дополнительно сообщать через sysfs имя физического порта (np0). > > Ну вот и причина. Я бы хотел понять, поменялся используемый драйвер сети со > стороннего на апстримный или нет. Какую информацию и в какой момент следует собрать?
(Ответ для rsrs на комментарий #45) > (Ответ для Leonid Krivoshein на комментарий #36) > > По логам уже почти всё понятно, но лучше всего дать такую команду: > > > > su- > > export SYSTEMD_LOG_LEVEL=debug > > udevadm test-builtin net_setup_link /sys/class/net/eno1np0 > > > > Именно в таком варианте она покажет не только получившиеся значения, но и > > причины их получения. Сравнивать надо только после обновления на двух > > машинах. Так мы увидим, почему не отрабатывает NamePolicy=keep, введённая в > > v241. > > Выложил > after-update-kernel-after-reboot-20251112-095435.7z > after-update-kernel-before-reboot-20251112-094917.7z Это логи с проблемной машины. Этого достаточно?
(In reply to rsrs from comment #40) > Уточните, пожалуйста, о каких двух машинах идёт речь? Проблемной и > беспроблемной? Верно. > Собрать эту информацию после обновления ядра до перезагрузки или после? Только после. (In reply to Антон Мидюков from comment #42) > Ну вот и причина. Я бы хотел понять, поменялся используемый драйвер сети со > стороннего на апстримный или нет. Можно уточнить у vt@ насчёт i40e. Внешне разница есть только в lsmod. Скорее какая-то настройка в BIOS вокруг IOMMU / SR-IOV на отличающейся машине стала добавлять "np0" к пути и к имени интерфейса в более новой версии драйвера, о чём как раз говорится в документации systemd. Настройки BIOS/UEFI в любом случае стоит самостоятельно сравнить. И чего тут не было сделано -- вывод с -nnk: lspci -nnk -s <PCI SLOT> Интересует, отличаются ли PCI ID i40e у машин с разными результатами?
(Ответ для Leonid Krivoshein на комментарий #48) > (In reply to rsrs from comment #40) > > Уточните, пожалуйста, о каких двух машинах идёт речь? Проблемной и > > беспроблемной? > Верно. > > > Собрать эту информацию после обновления ядра до перезагрузки или после? > Только после. > > (In reply to Антон Мидюков from comment #42) > > Ну вот и причина. Я бы хотел понять, поменялся используемый драйвер сети со > > стороннего на апстримный или нет. > Можно уточнить у vt@ насчёт i40e. Внешне разница есть только в lsmod. Скорее > какая-то настройка в BIOS вокруг IOMMU / SR-IOV на отличающейся машине стала > добавлять "np0" к пути и к имени интерфейса в более новой версии драйвера, о > чём как раз говорится в документации systemd. > > Настройки BIOS/UEFI в любом случае стоит самостоятельно сравнить. И чего тут > не было сделано -- вывод с -nnk: > > lspci -nnk -s <PCI SLOT> > Что подставить вместо <PCI SLOT>? Можно точную командную строку?
(Ответ для rsrs на комментарий #49) > (Ответ для Leonid Krivoshein на комментарий #48) > > (In reply to rsrs from comment #40) > > > Уточните, пожалуйста, о каких двух машинах идёт речь? Проблемной и > > > беспроблемной? > > Верно. > > > > > Собрать эту информацию после обновления ядра до перезагрузки или после? > > Только после. > > > > (In reply to Антон Мидюков from comment #42) > > > Ну вот и причина. Я бы хотел понять, поменялся используемый драйвер сети со > > > стороннего на апстримный или нет. > > Можно уточнить у vt@ насчёт i40e. Внешне разница есть только в lsmod. Скорее > > какая-то настройка в BIOS вокруг IOMMU / SR-IOV на отличающейся машине стала > > добавлять "np0" к пути и к имени интерфейса в более новой версии драйвера, о > > чём как раз говорится в документации systemd. > > > > Настройки BIOS/UEFI в любом случае стоит самостоятельно сравнить. И чего тут > > не было сделано -- вывод с -nnk: > > > > lspci -nnk -s <PCI SLOT> > > > > Что подставить вместо <PCI SLOT>? Можно точную командную строку? Требуется это: # lspci -nnk | grep -i eth 1a:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection X722 for 1GbE [8086:37d1] (rev 09) 1a:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Connection X722 for 1GbE [8086:37d1] (rev 09) ?
(Ответ для Leonid Krivoshein на комментарий #48) > (In reply to rsrs from comment #40) > > Уточните, пожалуйста, о каких двух машинах идёт речь? Проблемной и > > беспроблемной? > Верно. > > > Собрать эту информацию после обновления ядра до перезагрузки или после? > Только после. > > Настройки BIOS/UEFI в любом случае стоит самостоятельно сравнить. И чего тут > не было сделано -- вывод с -nnk: > > lspci -nnk -s <PCI SLOT> > Логи с машины без ошибки: https://disk.yandex.ru/d/YWW2Tu886nR3OA Логи с машины с ошибкой: https://disk.yandex.ru/d/ypnKbbSuumKDeg
(In reply to rsrs from comment #50) > Требуется это: Да, сойдёт! На будущее: lspci -nnk -s 1a:00.0 покажет сразу subID + модуль ядра. > # lspci -nnk | grep -i eth > 1a:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection > X722 for 1GbE [8086:37d1] (rev 09) https://cateee.net/lkddb/web-lkddb/NET_VENDOR_INTEL.html Ищите на странице "37d1" в нижней части -- поддержка с апстримных ядер 4.3+.
Обнаружил недостачу (2 shaba@)! В убунтовском udev есть такой файл: /lib/systemd/network/73-usb-net-by-mac.link: [Match] Path=*-usb-* [Link] NamePolicy=mac Интересно, есть ли он в апстримной версии? У нас даже в Сизифе его нет. Отладка показывает, что на ряде конфигураций применяется именно он и при его отсутсвии как раз ожидаются проблемы с некоторыми Ethernet'ами.
(In reply to Leonid Krivoshein from comment #53) > Интересно, есть ли он в апстримной версии? У нас даже в Сизифе его нет. В апстримной версии его тоже нет. Однако и в Debian он тоже имеется. Пример: # export SYSTEMD_LOG_LEVEL=debug # udevadm test-builtin net_setup_link /sys/class/net/enx180f76011320 SELinux enabled state cached to: disabled Trying to open "/etc/systemd/hwdb/hwdb.bin"... Trying to open "/etc/udev/hwdb.bin"... Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"... Trying to open "/lib/systemd/hwdb/hwdb.bin"... Trying to open "/lib/udev/hwdb.bin"... === trie on-disk === tool version: 249 file size: 11619158 bytes header size 80 bytes strings 2383646 bytes nodes 9235432 bytes Load module index Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy Found container virtualization none. Loaded timestamp for '/etc/systemd/network'. Loaded timestamp for '/usr/lib/systemd/network'. Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link Created link configuration context. ID_NET_DRIVER=ax88179_178a enx180f76011320: Device has name_assign_type=4 enx180f76011320: Config file /usr/lib/systemd/network/73-usb-net-by-mac.link is applied enx180f76011320: Failed to get ACTION= property: No such file or directory enx180f76011320: Could not apply link configuration, ignoring: No such file or directory ID_NET_LINK_FILE=/usr/lib/systemd/network/73-usb-net-by-mac.link Unload module index Unloaded link configuration context. Схема именовния та же, что в c10f2: v249.
Если верить документации, при отладке мы должны были увидеть что-то вроде: https://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=blob;f=man/systemd.link.xml#l1554 Т.е., даже при наличии других файлов .link, не совпадающих по условиям, успешное применение 99-default.link. Но мы видим какие-то ошибки с не очень внятной диагностикой по типу вывода выше и ниже: ... ID_NET_DRIVER=virtio_net ens5: Device has name_assign_type=4 ens5: Config file /lib/systemd/network/99-default.link is applied ens5: Failed to get ACTION= property: No such file or directory ens5: Could not apply link configuration, ignoring: No such file or directory ID_NET_LINK_FILE=/lib/systemd/network/99-default.link ... ... eno2np1: Device has name_assign_type=4 eno2np1: Config file /lib/systemd/network/99-default.link is applied eno2np1: Failed to get ACTION= property: No such file or directory eno2np1: Could not apply link configuration, ignoring: No such file or directory ID_NET_DRIVER=i40e ID_NET_LINK_FILE=/lib/systemd/network/99-default.link ... Could not apply link configuration, ignoring Я проверил, такое происходит не только в ОС Альт. Возможно это нормально, поскольку здесь речь не о финальном конфигурировании, это про builtin, но всё же интересно, почему так происходит? Почему не применяются настройки из дефолтного .link-файла, хотя по документации должны? Ковыряние в исходниках привело к тому, что для полной диагностики нужно поднять ещё и уровень логирования udev.log_level=debug или через udev_log=debug в конфиге /etc/udev/udev.conf + make-initrd. Но это тоже ничего не дало, даже при запуске udevadm -d..., т.е. уровень udev никак не хочет диагностироваться. Возможно, где-то настройка логирования udev перебивается при загрузке. https://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=blob;f=src/udev/net/link-config.c;hb=3b49d02584ae8c69a5de4c0d5484fc81aaf5bfb7#l603 https://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=blob;f=src/libsystemd/sd-device/sd-device.c;hb=3b49d02584ae8c69a5de4c0d5484fc81aaf5bfb7#l1121 По исходникам видно, что вылет почти сразу из-за отсутсвия действия add/remove/change, что логично, т.к. со стороны udev нет такого эвента. -ENOENT это и есть No such file or directory из-за device->action < 0. Всё же интересно сравнить PCI ID/SUB ID между нормой и плохим случаем. Можно выложить вывод прямо в баг (всего три строки) или просто сказать -- совпадают ID или нет. Также стоит сравнить настройки BIOS. По отладочному выводу видно, что 99-default.link не применяется в обоих случаях, но я мог запутаться в изобилии логов. Хорошо бы ещё сравнить вывод udevadm -d test /sys/class/net/<iface> -- вот он единственный, кто сейчас показал причину, почему так происходит, как отрабатывают политики, также видно, что многое приезжает из udev hwdb.
