Nach dem Update und Neustart von Proxmox geht das Netzwerk nicht mehr

[RoxxBBer]

Hallo,

ich habe in der Proxmox GUI die Updates eingespielt und anschließend den Server neu gestartet.
leider fährt der Server nicht mehr von alleine hoch.
- Das System fährt hoch und man sieht den Hinweis, man solle sich unter IP XX einloggen
- Die pve Gui / SSH usw. ist nicht erreichbar / aktiv

überprüfe ich mit

ip a

erhalte ich für alle physischen Netzwerkschnittstellen folgende Ausgabe:
mtu 1500 qdisc noqueue state down group default

normalerweise erscheinen auch die Schnittstellen der Container und VMs diese werden aber nicht angezeigt.

eine Übersicht der Prozesse mit

systemctl status pve*

Zeigt folgende Fehler (hier exemplarisch für einen Container):

● pve-container@3000.service - PVE LXC Container: 3000
     Loaded: loaded (/lib/systemd/system/pve-container@.service; static)
     Active: failed (Result: exit-code) since Sat 2021-09-04 07:50:56 CEST; 14min ago
       Docs: man:lxc-start
             man:lxc
             man:pct
    Process: 3806 ExecStart=/usr/bin/lxc-start -F -n 3000 (code=exited, status=1/FAILURE)
   Main PID: 3806 (code=exited, status=1/FAILURE)
        CPU: 514ms


Sep 04 07:50:54 pve systemd[1]: Started PVE LXC Container: 3000.
Sep 04 07:50:56 pve systemd[1]: pve-container@3000.service: Main process exited, code=exited, status=1/FAILURE
Sep 04 07:50:56 pve systemd[1]: pve-container@3000.service: Failed with result 'exit-code'.

Sep 04 07:50:53 pve pve-guests[3357]: starting CT 3000: UPID:pve:000001D:00000657:6133093D:vzstart:3000:root@pam:
Sep 04 07:50:55 pve pve-guests[3357]: startup for container '3000' failed
Sep 04 07:50:55 pve pvesh[3056]: Starting CT 3000 failed: startup for container '3000' failed
Sep 04 07:50:55 pve pvesh[3056]: Starting CT 5000
Sep 04 07:50:55 pve pve-guests[3057]: <root@pam> starting task UPID:pve:00000FD:00000720:6133093F:vzstart:5000:root@pa>
Sep 04 07:50:55 pve pve-guests[3837]: starting CT 5000: UPID:pve:00000FD:00000720:6133093F:vzstart:5000:root@pam:
Sep 04 07:50:56 pve pve-guests[3837]: startup for container '5000' failed
Sep 04 07:50:56 pve pvesh[3056]: Starting CT 5000 failed: startup for container '5000' failed
Sep 04 07:50:56 pve pve-guests[3056]: <root@pam> end task UPID:pve:00000F1:0000045C:61330938:startall::root@pam: OK
Sep 04 07:50:56 pve systemd[1]: Finished PVE guests.

Ich komme auch nicht mit SSH auf den Server sondern bin gerade froh das iDrac funktioniert und ich auf das Terminal komme.

nutze ich:

service networking restart

komme ich auf die Gui und kann die VM´s fehlerfrei starten.

Aber starte ich den Server neu - ist alles wieder tot.

Hat evtl. jemand eine Ahnung was genau los ist? bzw. wie man es beheben kann?

Vielen Dank

Gruß

RoXXBBer

 

[RoxxBBer]

Hier noch Versionsinfos:

root@pve:~# pveversion -v
proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-5.11: 7.0-7
pve-kernel-helper: 7.0-7
pve-kernel-5.4: 6.4-4
pve-kernel-5.11.22-4-pve: 5.11.22-8
pve-kernel-5.11.22-3-pve: 5.11.22-7
pve-kernel-5.4.124-1-pve: 5.4.124-1
pve-kernel-5.4.73-1-pve: 5.4.73-1
ceph-fuse: 14.2.21-1
corosync: 3.1.2-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.21-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-6
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-10
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-9
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-2
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.4-1
pve-qemu-kvm: 6.0.0-3
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-13
smartmontools: 7.2-pve2
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1

Gruß RoXXBBer

 

[Dunuin]

Deine /etc/network/interfaces Datei wäre hilfreich.

 

[RoxxBBer]

Danke,

hier der Inhalt der Datei:

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

iface enp6stf0 inet manual

iface enp6stf1 inet manual

iface enp6stf2 inet manual

iface enp6stf3 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
        address XX.XX.XX.XX/24
        gateway XX.XX.XX.XX
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

auto vmbr20
iface vmbr20 inet manual
        bridge-ports enp6s0f0
        bridge-stp off
        bridge-fd 0
#OpnSense / LAN

auto vmbr30
iface vmbr30 inet manual
        bridge-ports enp6s0f1
        bridge-stp off
        bridge-fd 0
#OpnSense / WAN

auto vmbr40
iface vmbr40 inet manual
        bridge-ports enp6s0f2
        bridge-stp off
        bridge-fd 0
#OpnSense / WLAN

auto vmbr50
iface vmbr50 inet manual
        bridge-ports enp6s0f3
        bridge-stp off
        bridge-fd 0
#OpnSense / OPT

auto vmbr60
iface vmbr60 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0
#OpnSense / DMZ

an dieser habe ich nichts verändert und es läuft mit dieser Konfiguration seit ca. 2-3 Jahren ohne Probleme.
Ich habe wie oben beschrieben lediglich die verfügbaren Updates installiert und seitdem habe ich diese Probleme

Gruß RoXXBBer

 

[Mathias R]

Hallo,
Du könntest ein Update auf ifupdown2 probieren.
Das läuft bei mir sowohl auf bridged, als auch auf routed Servern sehr stabil und fährt problemlos hoch.
Wenn es aber um WLAN geht, das ist im Moment des Starts der VMs noch nicht verfügbar und funktioniert auch bei mir nur, wenn ich die VMs später starte. Hier einfach den automatischen Start der VMs verzögern oder diese gleich per Script starten wenn das WLAN verfügbar ist.

Gruß,
Mathias

 

[RoxxBBer]

Hallo,

vielen Dank für deine Antwort, ich habe gerade noch mal auf dem Server nachgesehen, ich habe ifupdown2 bereits installiert (ich glaube das kam sogar mal mit dem PVE7 upgrade vor ein paar Wochen)
Wlan ist nicht im Einsatz - das sind alles LAN Adapter

ifupdown2 is already the newest version (3.1.0-1+pmx3).

Danke Gruß RoXXBBer

 

[Mathias R]

Hallo,
dann könnte möglicherweise Dein Netzwerk zu spät hochkommen.
Hier dann entweder die Container verzögert hochfahren oder per Script starten sobald das Netzwerk verfügbar ist.
Gruß,
Mathias

 

[RoxxBBer]

Hallo,

Das Problem ist nicht der Container - das komplette Netzwerk kommt nicht hoch und somit keine einziger Container oder VM - den Container oben habe ich als Beispiel gepostet.
Erst nachdem ich den Netzwerkdienst mit "service networking restart" komplett neu starte, kann ich auf die Webgui und die VMS starten, oder per SSH zugreifen.

gebe ich nach dem Boot "ip a" ein, dann sind alle interfaces DOWN. - aber ich verstehe nicht warum

Gruß

RoXXBBer

 

[Mathias R]

Hallo,
hatte ich auch mal mit einer Netzwerkkarte, die nicht ganz kompatibel war.
Dann einfach einen automatischen Script, der ein service networking restart ausführt, sofern die Connectivität nicht da ist (schnelle Lösung).

Du könntest zur Fehlersuche auch mal mit einzelnen Karten ohne bond und bridges testen und die interfaces schrittweise wieder erweitern um den Fehler einzugrenzen.

Gruß, Mathias

 

[Falk R.]

Eventuell waren im Update neue Treiber, hast du mal die Firmware geprüft und ein Update durchgeführt?

 

[RoxxBBer]

Hallo,

das könnte tatsächlich sein, im apt log ist ein Update der Firmware enthalten, aber wie drehe ich das zurück?

Commandline: apt-get dist-upgrade
Install: pve-kernel-5.11.22-4-pve:amd64 (5.11.22-8, automatic)
Upgrade: pve-firmware:amd64 (3.2-4, 3.3-1), pve-kernel-5.11:amd64 (7.0-6, 7.0-7), pve-kernel-helper:amd64 (7.0-6, 7.0-7)

Commandline: apt-get autoremove -y
Remove: pve-kernel-5.11.22-2-pve:amd64 (5.11.22-4)

Wobei es schon komisch wäre, denn alle 6 LAN Ports werden auf Down gesetzt - 4x Intel Quad und 2 x die Dell Broadcom Onboard müsste dann nicht eher nur eine "Kategorie" ausfallen? - und das sind ja keine exotischen LAN Chips - also denke ich

Danke

Gruß

RoXXBBer

 

[Falk R.]

Ich hatte das schon mehrfach bei Kunden, wenn ein OS Update neue Treiber mitbringt gibt es komische Fehler.
Da hilft oft ein Firmwareupdate der Netzwerkkarten.
Es kann auch sein, dass eine NIC Fehler im Netzwerkstack verursacht und deshalb alle NICs offline bleiben.

 

[RoxxBBer]

Hallo,

Danke für die Antwort, leider Enden hier meine Linux Kenntnisse - wie kann ich das Korrigieren oder die Netzwerkkarten mit neuer Firmware beglücken? gibts da Pakete von den Herstellern?

Danke

Gruß

RoxxBBer

 

[Falk R.]

Bei DELL Servern ist das sehr einfach. Da gibt es ein ISO was du booten kannst und der updatet alles oder die Firmware übers iDRAC einspielen.

 

[RoxxBBer]

Hallo,

ich habe das mit der Firmware innerhalb von iDRAC nun ausprobiert, diese habe ich zurückgerollt, bzw. gab es in der Zwischenzeit auch ein Update dafür, dass ich auch eingespielt habe. Leider ohne Erfolg. Ich bekomme den Proxmox nur zum laufen wenn ich "service networking restart" nach dem boot benutze.

Gruß RoxxBBer

 

[Falk R.]

Wie sieht denn deine Netzwerkkonfiguration aus? Nutzt du Spanning Tree, wenn ja, dann setze die Ports deines Servers auf Portfast.

 

[RoxxBBer]

Hallo,

Ich nutze einen UNIFI Switch - Spanning tree steht per default auf RSTP.
Aber kann das dazu führen, dass die Ports beim boot alle down sind - es hat ja immerhin ein paar Jahre funktioniert.
Nur seit dem letzten Linux Firmware Upgrade gibt es diese Probleme.

Gruß

RoxxBBer

 

[Falk R.]

Spanning Tree setzt einen Port wenn der online kommt kurz auf Blocking bis der Switch geprüft hat, dass es keine alternative Strecke / Loop gibt.
Es kann sein, das nach dem Update einiges schneller von statten geht und ein Check Paket ob der Link OK ist genau in der Blocking Phase raus geht.
Da kommt kein Response und der Server setzt die NIC offline. So ein ähnliche Problem habe ich bei Windows Servern, die erkennen nicht mehr ob es ein Domänennetzwerk ist und setzen dann das Profil öffentlich. Die Ursache ist jedes mal, dass Prüfpakete verloren gehen im Blocking State.

 

[RoxxBBer]

Ich habe es gerade ausgeschalten, leider sind die NICS noch immer down beim booten.

Gruß

RoxxBBer

 

[Falk R.]

Jetzt gehen mir auch die Ideen aus, Im Netz findet man dazu auch nur ganz oft den Workaround mit einem Script was die NIC Down setzt und danach wieder Up.