Proxmox потерял сеть после переподключения всех дисков

Почему у тебя на первом выводе ip a на мосту есть адрес, а при выводе brctl уже нет? Что трогал?

Enp5s0 не должна быть в состоянии down, если при поднятии линк появляется, то достаточно поправить в etc/network/interfaces, если я правильно помню Debian.

В любом случае, если у тебя мост то есть то нет, то работать не будет, смотри, что происходит, когда мост получает или теряет ip адрес.

В общем, после переподключения дисков proxmox действительно переименовал Enp5s0 в Enp6s0

Командой nano /etc/network/interfaces исправил строчки iface inet manual и bridge-ports с Enp6s0 на Enp5s0

Было - https://drive.google.com/file/d/1uxDgLOBSdsbCnr6cd23XWh0ltgJDuAiI/view?usp=sharing

Стало - https://drive.google.com/file/d/1nGsM_UVrLHMqosQrJPHUl3Lbc9yA4VqE/view?usp=sharing

После этого выполнил systemctl restart networking

И проверил работу командой ifup vmbr0

В итоге все ок и загорелся зеленый индикатор на свитче

Для решения проблемы воспользовался нейронкой deepseek т.к. я только начинаю пробовать в селфхостинг)

Спасибо за такой быстрый ответ!

переподключения дисков proxmox действительно переименовал Enp5s0 в Enp6s0

Как же я ору с якобы пресказуемых имён. Сетевушку же никто не трограл, но она пересела на другую шину. Предсказуемость на уровне старых ethX, только там в случае одной сетевухи такой проблемы нет как класса. Те же яйцы, вид сбоку получился.

Увы, но да.

Ну с появлением udev и с ethX стали возникать проблемы :) А вот до его появления всё было кране ровненько и реально предсказуемо.

Если в системе есть pci-e / pci карты расширения, то при изменении порядка их подключения имя сетевого адаптера может измениться, даже если он распаян на материнской плате.

Если он тоже в виде платы расширения - то вероятность выше.

О том и речь, то что назвали «предсказуемым» стало гораздо более непредсказуемым.

Для решения проблемы воспользовался нейронкой deepseek т.к. я только начинаю пробовать в селфхостинг)

Ааа, так это просто реклама нейросети чтоль?

Типа я почистирал бельё обычным порошком – пятна остались, постирал нейросетью – теперь мне не до стирки. Гггг

// Или нейросети уже сами себя рекламировать начали? А если отказоустойчивость начнуть пробовать и целыми странами ктричество вырубать?

У некоторых материнок биос переназначает номера слотов pci-e. У нормальных производителей серверов такого нет.

то при изменении порядка их подключения имя сетевого адаптера может измениться

П-предсказуемость.

Чувствую теперь нужно делать новое пространство имён сетевых адаптеров, что то типа «Теперь точно-точно предсказуемые имена сетевых адаптеров».

Недавно дистанционно помогал другу устранить такую же (как оказалось) проблему, после втыкания дополнительного проца + памяти на серверной плате Supermicro.

А у себя всегда стандартно делаю на серверов:

root@xxxxxx:~# ll /etc/systemd/network/
total 16
-rw-r--r-- 1 root root 55 May 12  2021 80-eth0.link
-rw-r--r-- 1 root root 55 May 12  2021 81-eth1.link
-rw-r--r-- 1 root root 55 May 12  2021 82-eth2.link
-rw-r--r-- 1 root root 55 May 12  2021 83-eth3.link
root@xxxxxx:~# 
root@xxxxxx:~# cat /etc/systemd/network/80-eth0.link 
[Match]
MACAddress=2c:ea:7f:ec:6f:18
[Link]
Name=eth0
root@xxxxxx:~# 

.. и так для всех интерфейсов. И горя не знаю.

Proxmox не использует systemd-network для настройки сети.

Для серверов разумеется везде /etc/network/intefaces.

Стабильные имена интерфейсов (по маку или еще чего-то еще) через /etc/systemd/network - это не связано с настройки сети через systemd-network, это штатная функциональность самого systemd как init-a.

root@xxxxxx:~# dpkg -l | grep systemd
ii  dbus-user-session                    1.12.28-0+deb11u1                  amd64        simple interprocess messaging system (systemd --user integration)
ii  libnss-systemd:amd64                 247.3-7+deb11u6                    amd64        nss module providing dynamic user and group name resolution
ii  libpam-systemd:amd64                 247.3-7+deb11u6                    amd64        system and service manager - PAM module
ii  libsystemd0:amd64                    247.3-7+deb11u6                    amd64        systemd utility library
ii  libvirt-daemon-system-systemd        7.0.0-3+deb11u3                    all          Libvirt daemon configuration files (systemd)
ii  systemd                              247.3-7+deb11u6                    amd64        system and service manager
ii  systemd-sysv                         247.3-7+deb11u6                    amd64        system and service manager - SysV links
root@xxxxxx:~# 

+1. На физических машинах отключаю предсказуемые имена и прибиваю сетевкам имена вида lan0/lan1 и т.д.(eth* использовать нельзя, там гонка может случится и получишь имя вида eth_<hash>_rename или что-то вроде того) на основании MAC-ов.

Чувствую теперь нужно делать новое пространство имён сетевых адаптеров, что то типа «Теперь точно-точно предсказуемые имена сетевых адаптеров».

И добавлять ещё один параметр в загрузчик :)

eth* использовать нельзя, там гонка может случится и получишь имя вида eth_<hash>_rename или что-то вроде того) на основании MAC-ов.

Можно. Этой фигней udev страдает, так что тут всё просто с отучением.

Пфахах, нене) Просто в моменте решил воспользоваться и написал с помощью чего в итоге смог пофиксить)) Потому что читал форумы вечером за день до этого, эффективность лично у меня было сильна меньше. Как для чайника))

Машина обесточивалась. Может чел ещё clear nvram сделал

Машина обесточивалась. Может чел ещё clear nvram сделал

Кстати допустимо. Например батарейка уже всё.
ЗЫ И вот уже не помню, машинки с воткнутым джампером clear-cmos вообще грузятся или после очистки джампер надо снимать? Если грузятся то не исключено, что кто-то когда-то его воткнул, да и забыл про это.

Я пробовал как раз через правила udev во времена ядра 3.4 кажется(точнее не вспомню) на серваке с 4 и более сетевухами каждый третий ребут - минимум один из интерфейсом зависает в полупереименованном состоянии(с вот тем кривым именем) если в качестве имен использовать eth0/eth1/eth2/eth3

Ну или как подсказали выше переименовывать через systemd-networkd - он явно позже срабатывает. У меня такой возможности не было - там была гента и OpenRC, а переходить тогда на systemd только ради этого - нет спасибо.

Я пробовал как раз через правила udev во времена ядра 3.4 кажется(точнее не вспомню) на серваке с 4 и более сетевухами каждый третий ребут - минимум один из интерфейсом зависает в полупереименованном состоянии(с вот тем кривым именем) если в качестве имен использовать eth0/eth1/eth2/eth3

Так вы udev отучили не лезть куда не просят?
ЗЫ То, что такие полупереименованные благодаря udev случались, подтверждаю! Сам на эти грабельки наступал, собстно поэтому никаких переименований!

даже если он распаян на материнской плате

Если плата более-менее не кривая, то там вполне предсказуемые имена eno*. Но у меня, кажется, всего на одной-двух такое было. А сейчас и вовсе такая хрень, если ThunderBolt включён:

2: enp57s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
3: enp58s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

В зависимости от кофигурации устройств, могут стать и 98 с 99. Но и в NM, и в systemd-networkd можно делать привязку по MAC, так что я не заморачиваюсь с переименованием.

Ну или как подсказали выше переименовывать через systemd-networkd - он явно позже срабатывает

Он этим не занимается. Файлы .link обрабатывает udev. Переименовывать в eth, кстати, там не рекомендуется во избежание путаницы. Но при желании можно.

Но и в NM, и в systemd-networkd можно делать привязку по MAC

Тут чисто предположительно тоже засада может быть в случае если вы MAC меняете. Но это пальцем в небо.

Курсив получился случайно:

Файлы *.link обрабатывает udev. Переименовывать в eth*, кстати, там не рекомендуется во избежание путаницы.

Тут чисто предположительно тоже засада может быть в случае если вы MAC меняете.

Привязка к заводскому адресу, это не мешает его менять, в том числе прямо в том же NM.

Сам себе проблему создал. Выкини Proxmox и используй QEMU.

Тут чисто предположительно тоже засада может быть в случае если вы MAC меняете.

Привязка к заводскому адресу, это не мешает его менять, в том числе прямо в том же NM.

Все зависит от того как именно меняете. Если всё средствами одного комбайна, то наверное должно работать, если же это меняется разными средствами, то возможны варианты. Но вот выше приводили другой пример Proxmox потерял сеть после переподключения всех дисков (комментарий) и это правильный пример. Так что никто не гарантирует, что и в NM не случится засада.

Все зависит от того как именно меняете.

Нет, ядро у тебя одно.

Ведро-то одно, методов больше одного.

Так вы udev отучили не лезть куда не просят?

Что под этим подразумевается? net.ifnames=0 в опции ядра? Этого(+естественно собственных правил переименования в eth*) недостаточно.

Или предлагается переименовывать устройства руками где-нибудь в rc.local и перезапускать сеть? Спасибо, не надо.

Что под этим подразумевается? net.ifnames=0 в опции ядра?

Нет, не про это. Я про ваше «минимум один из интерфейсом зависает в полупереименованном состоянии». Это то, чем занимается udev. Повторю вопрос «Так вы udev отучили не лезть куда не просят?» Мне просто интересно, вы добили удава или так и мучались? :)

Как я уже говорил - если сменить схему именования на lan0/lan1/lan2/lan3 и т.д. никаких проблем с переименованием и предсказуемостью названий сетевых карт не возникает.

Хотя как знать, встречал я бажный биос в дешевой китайской плате, которая периодически делала случайным третий октет MAC-адреса встроенной сетевухи. Ну вот просто потому что.

Тут да, наверное привязка к адресу устройства на шине вместо MAC-а будет более предпочтительна, лол

встречал я бажный биос в дешевой китайской плате, которая периодически делала случайным третий октет MAC-адреса встроенной сетевухи.

Век живи. Спасибо за информацию! Натолкнешься на такое и долго будешь пытаться понять «что ты делаешь не так».

Не имеет значения, это свойство линка.

Не имеет значения, это свойство линка.

Имеет. Меняем до старта NM эффект один, меняем после эффект другой, меняем в параллель random.

Меняем до старта NM эффект один, меняем после эффект другой, меняем в параллель random.

Какой эффект? «Поменяй» MAC, и посмотри в вывод ip l — это должно добавить ясности.

Ещё раз специально для альтернативно одаренных анонов:
1. поменяли до старта NM - mac измененный
2. поменяли после старта NM - мак родной
3. запускаем в паралель изменение мак и старт NM - рулетка

Ещё раз специально для альтернативно одаренных

Не понимаешь, что тебе говорят? Переходи на личности. Все маководы такие, или это приобретённый дефект?

Комментировать остальное смысла нет, приходи после дообучения.