Непредсказуемые сетевые имена.

Если ты прочитаешь документацию по реализации предсказуемых имён в systemd-udev, то увидишь, что один из критериев именования - номер устройства на шине PCI / PCI-E.

Ты изменил порядок устройств на шине - изменились имена устройств.

Как-то, так, всё очень предсказуемо, т.е. согласно документации.

Можешь вернуть eth* имена и прописать в udev правила с привязкой имён устройств к маку. Даже назначить те же имена, что были до изменения расположения устройств на шине PCI / PCI-E.

Товарищи, читайте документацию и будет вам счастье. )))

За подробностями вот: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

What precisely has changed in v197?
With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.

Как-то, так, всё очень предсказуемо, т.е. согласно документации.

В документации может быть написано что новое имя будет в виде случайного uuid и это к предсказуемости отношения не имеет.

Более того, даже если в голове просчитать как поменяются имена, согласно документации толку от этого ровно ноль, конфигурация ранее привязанная к именам сломается гарантированно. Хоть ты предскажешь имена, хоть нет, полезешь исправлять.

Единственный выход это заранее прибить имя к устройству, но тогда эта «предсказуемая» смена имён имеет ровно никакого смысла.

Вот эти вот имена назначаемые устройствам, должны быть не именами, а просто дополнительными метками, такими что ранее настроенная конфигурация не ломалась, но ты мог по этой метке узнать где конкретно сейчас вставлено устройство.

https://www.altlinux.org/NetworkDevicesName

Более того, даже если в голове просчитать как поменяются имена, согласно документации толку от этого ровно ноль, конфигурация ранее привязанная к именам сломается гарантированно. Хоть ты предскажешь имена, хоть нет, полезешь исправлять.

Единственный выход это заранее прибить имя к устройству, но тогда эта «предсказуемая» смена имён имеет ровно никакого смысла.

Я и не сказал, что это можно предсказать. Там же написано, что схема именования устройств приближена к нумерации устройств в BIOS (UEFI) и она тебе гарантирует, что от перезагрузки к перезагрузке имена сетевых устройств будут одинаковыми.

У меня была ситуация и не раз, когда на старой схеме именования устройств eth* менялись номера сетевых устройств при перезагрузке.

Они зависели от порядка инициализации (загрузки модуля, инициализации драйвером устройства) ядром Linux.

При чём, если не путаю это даже как-то происходило когда ни аппаратная часть не менялась, ни ядро не пересобиралось.

Это потом я уже в /etc/udev/rules.d/70-persistent-net.rules прописал правило для привязки к маку.

А так, если собрать ядро с другим набором драйверов и имена сетевых устройств в eth* схеме менялись, но это без наличия файла /etc/udev/rules.d/70-persistent-net.rules.

Потом, когда в udev Леннарт добавил такое поведение я в начале, конечно плевался, как и все и даже какое-то время использовал старую схему, её и сейчас можно включить.

Но в механике, предложенной леннартом, с привязкой к номерам устройств BIOS (UEFI) имя сетевого интерфейса не изменится в случае отсутствия модуля ядра или порядка загрузки модулей ядром.

Единственная проблема - изменение конфигурации оборудования, как у автора.

Так что везде есть свои нюансы, просто нужно учитывать.

Вот эти вот имена назначаемые устройствам, должны быть не именами, а просто дополнительными метками, такими что ранее настроенная конфигурация не ломалась, но ты мог по этой метке узнать где конкретно сейчас вставлено устройство.

Если ты посмотришь логи ядра Linux, то оно по прежнему так и инициализирует сетевые интерфейсы как eth*, а потом udev их переименовывает согласно предсказуемой схеме.

Чтобы быть жёстко уверенным - прописывай имена в /etc/udev/rules.d/70-persistent-net.rules.

но ты мог по этой метке узнать где конкретно сейчас вставлено устройство

Напиши об этом Леннарту, может реализует или реализуй сам.

Да, без перевода сложно разобраться, английский язык очень сложен.

Ты можешь через параметры ядра заставить Linux использовать старые имена типа eth0:

net.ifnames=0

Но они тебе не всрались, если ты не понимаешь зачем это может пригодиться.

А зачем может пригодиться? По мне, что так, что так доступ к сетевым интерфейсам одинаков.

Ну разве что циклом в скрипте перебирать удобнее.

А зачем может пригодиться?

При использовании Network Manager и тп - низачем. Это виртуалкопроблемы

В proxmox и так поголовно имена интерфейсов в ВМ всегда ens18.

Да и нет никаких проблем, что так, что так.

Какие у тебя проблемы с именами интерфейсов в ВМ?

Хотя скажу, что аппаратная конфигурация ВМ не часто меняется на кластерах виртуализаци, что админимтрирую.

С XEN и VMare ESXi тоже не помню каких-то проблем.

Аналогично просто с QEMU / KVM.

Так в чём проблема? С виртуалками что так, что так просто.

На OpenStack oVirt тоже вроде бы нет проблем.

На самих узлах Proxmox имена физических сетевых интерфейсов eno1, eno2 … enoN.

Ну а проверить имя сетевого интерфейса в случае изменения конфигурации сервера - дело исполнителя работ.

Но соглашусь, что в случае смены имени менять потом конфигурацию ВМ придётся для настройки мостов.

https://learn.microsoft.com/ru-ru/troubleshoot/azure/virtual-machines/linux/cannot-connect-debian-linux

как пример биопроблем любителей виртуального секса с линуксом

Это высосанная из пальца проблема. Понятно, что нужно проверить конфигурацию оборудования и мена интерфейсов. Просто нужно об этом знать.

Но имеет место быть, да.

Спасибо за уточнение!

С net.ifnames=0 тоже нужно учитывать, что при переносе VM, если сменился MAC адрес и существует файл /etc/udev/rules.d/70-persistent-net с определением привязки eth0 к старому мак адресу - в новой ВМ среде интерфейс будет eth1.

Можешь вернуть eth* имена и прописать в udev правила с привязкой имён устройств к маку.

А как быть с usb-радиомодемом который работает в режим «raw-ip»,а не «802-3»,поэтому мака не имеет, и обзывается как угодно - то wwx028ddd964a36 то wwx226236d808e7 то вдруг внезапно wwan0 ? Дебиановская схема именования что,вообще не учитывает таких случаев когда мака может не быть? Причем я так и не понял почему иногда всё же остается wwan0,а иногда переименовывается.

У меня была ситуация и не раз, когда на старой схеме именования устройств eth* менялись номера сетевых устройств при перезагрузке.

У меня такое тоже было там где в машине несколько сетевых карточек стояло. Поэтому я не возражал против идеи привязать имена к их расположению на шине. В конце концов нет разницы писать ли в конфиге eth0 или enp2s0. Но засада случилась в сетевыми устройствами подключаемыми в usb. У них бывает что НЕТ mac-адреса - например у радиомодемов работающих как raw-ip устройства,а не 802-3. И вот тут при каждой загрузке имена «прыгать» начинают. Причем иногда вообще wwan0 остается то есть никакой переименование не срабатывает. Как это чинить не откатываясь на старую схему именования устройств - пока не понял. Как объяснить системе что привязывать usb-устройства надо не к маку,а к положению на шине usb? Да еще так чтобы при очередном апгрейде udev отредактированные конфиги «молча» не затёрлись.

как это работает?

Через жопу
net.ifnames=0 в параметры ядра добавь и забудь про эту выходку поттеринга

Да не. Меня не напрягает это. Просто меня несколько удивило то, что физически устройства остались подключены к тем же портам, а имена изменились. Тему чисто из любопытства создавал.

Вот потому и через жопу) казалось бы должны быть привязаны к слоту pci и если карту не перемещал то имя должно остаться, но на практике...отдельный вид мазахизма - usb-eth карты у которых в имени полностью mac этой карты прописывается

net.ifnames=0 в параметры ядра добавь

Тогда возвращаемся к проблеме непредсказуемости именования в зависимости от случайного порядка инициализации,что вобщем-то тоже плохо и тут я с Поттерингом согласен. Смысл моего вопроса был именно в том,как бы для usb-устройств сделать привязку не к маку,которого нет,а к положению на шине. Это бы меня устроило. Вдруг тут есть кто-то глубоко разбирающийся в конфигах udev и знает как эту вобщем-то мелочь подправить.

отдельный вид мазахизма - usb-eth карты у которых в имени полностью mac этой карты прописывается

Да, особенно если такая карта работает в raw-ip (радиомодемы) и mac у нее вообще ОТСУТСТВУЕТ. Интересно,откуда берется то,что прописывается в имени в этом случае? Причем разное при перезагрузках! А иногда вообще не переименовывается и остается wwan0

Например, если тот слот, в который переставил звуковую карту, подключен через PCI-бридж, то занялся дополнительный номер PCI Bus ID. В результате номера переехали с 7 и 8 на 9 и 10.

Если прямо любопытно, то сравни выводы lspci до и после.

Вообще, если сетевая карта распаяна на материнке, то BIOS по-хорошему должен был предлагать для нее имя eno2.

как это работает?

Если тебя беспокоит, что имена прыгают, то это принципиально нерешаемая на уровне софта задача.

Если интересует почему названия такие всратые, то это системд, всасывая удев, ломал совместимость софта.

отдельный вид мазахизма - usb-eth карты у которых в имени полностью mac этой карты прописывается

Для радиомодемов,представляющихся сетевой картой, я это победил. Тут написал: LTE module и Debian (комментарий)

Вопрос чисто из любопытства: как это работает?

Я, когда софтовый роутер на системном блоке делал, на котором PCI-Ethernet, там CPU без встроенного видео, поэтому, чтоб установить ОСь и настроить, вставлял видеокарту. Затем, получив доступ по SSH вынимал видюху и не мог попасть по SSH именно на PCI-Ethernet порт. Тоже долго не мог понять почему нет доступа без видюхи. В общем это всё к тому, что все мы дилетанты…=)