Proxmox stürzt ab. Gibt es irgendwo ein Log ?

[RudiP]

was passiert (falls möglich) wenn du den switch mal weglässt und direkt an den Routeranschluss gehst?

Geht schlecht, zu langer weg zum Router.
Aber es ja ja zig Monate mit dem Switch funktioniert und ein Portwechsel hat auch nichts geändert.

Ich nenne das "Wackelkontakt" ;D...

Würde ich zustimmen, wenn es am Kabel wackeln liegen würde. Aber egal, ob ich am einen ende oder am anderen mal kurz ausstopsel, danach gehts wieder.
Oder ja auch, wie ich jetzt festgestellt habe, wenn ich am Switch den Port kurz deaktiviere und wieder aktiviere. Da wackel ich überhaupt nicht am Kabel.

Im System Log von Proxmox, was ich eben mal durch Zufall entdeckt habe, kann ich folgendes lesen.

May 30 11:20:01 pve kernel: e1000e 0000:00:19.0 eno1: Detected Hardware Unit Hang: TDH <65> TDT <7c> next_to_use <7c> next_to_clean <64>buffer_info[next_to_clean]: time_stamp <10837e3a7> next_to_watch <65> jiffies <1083884c0> next_to_watch.status <0>MAC Status <80083>PHY Status <796d>PHY 1000BASE-T Status <806>PHY Extended Status <3000>PCI Status <10>
May 30 11:20:01 pve kernel: e1000e 0000:00:19.0 eno1: NIC Link is Down
May 30 11:20:02 pve kernel: vmbr0: port 1(eno1) entered disabled state
May 30 11:20:02 pve kernel: eth0: entered promiscuous mode
May 30 11:20:02 pve pvestatd[1174]: storage 'NAS_Proxmox' is not online
May 30 11:20:05 pve kernel: e1000e 0000:00:19.0 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
May 30 11:20:05 pve kernel: vmbr0: port 1(eno1) entered blocking state
May 30 11:20:05 pve kernel: vmbr0: port 1(eno1) entered forwarding state
May 30 11:20:13 pve kernel: eth0: left promiscuous mode
May 30 11:20:25 pve kernel: e1000e 0000:00:19.0 eno1: NIC Link is Down
May 30 11:20:25 pve kernel: vmbr0: port 1(eno1) entered disabled state
May 30 11:20:30 pve kernel: e1000e 0000:00:19.0 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
May 30 11:20:30 pve kernel: vmbr0: port 1(eno1) entered blocking state
May 30 11:20:30 pve kernel: vmbr0: port 1(eno1) entered forwarding state

Proxmox hat also erkannt, das die Hardware Unit hängt.
Diese Meldung, das die Hardware hängt taucht dann auch im 1 oder 2 Sekunden Takt immer wieder auf, bis ich den Fehler halt behebe.

 

[blurrrr]

Hast Du denn mittlerweile mal das non-subscription-Repo eingebunden und die Updates installiert?

Falls das Problem dann noch immer besteht, mal bzgl. Treibern für die NIC (i218v) schauen (bitte nur direkt von Intel) und damit nochmal testen. Scheint jedenfalls kein unbekanntes Problem zu sein. Die Lösung von @Confluencer scheint auch zu helfen (wobei das Problem als solches damit ja nicht gelöst ist, sondern nur umgangen wird). Alternativ - auch nur ein "umgehen" - eine andere NIC nutzen.

 

[the other]

Moinsen,
Kannst du den (war es nicht ein) Minirechner nicht kurz tragen? Gerade weil

Aber es ja ja zig Monate mit dem Switch funktioniert und ein Portwechsel hat auch nichts geändert.

würde ich es auch noch mal ohne versuchen, als Ausschlussdiagnostik quasi.

Was für eine Hardware als NIC ist eingebaut? Weil...es gibt da wohl für Intel e1000er Modelle einen bekannten Bug, der wohl eine solche Meldung auslöst (bzw einen solchen Fehler, der dann gemeldet wird). Hat zumindest eine kurze Suche so zu Tage gefördert > Suchergebnisse

 

[RudiP]

Hast Du denn mittlerweile mal das non-subscription-Repo eingebunden und die Updates installiert?

Also meine sources.list sieht so aus.

deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib

# Proxmox VE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

# security updates
deb http://security.debian.org/debian-security bookworm-security main contrib

danach auch "Aktualisieren" und ">_ Upgrade" gemacht.

Falls das Problem dann noch immer besteht, mal bzgl. Treibern für die NIC (i218v) schauen (bitte nur direkt von Intel) und damit nochmal testen. Scheint jedenfalls kein unbekanntes Problem zu sein. Die Lösung von @Confluencer scheint auch zu helfen (wobei das Problem als solches damit ja nicht gelöst ist, sondern nur umgangen wird). Alternativ - auch nur ein "umgehen" - eine andere NIC nutzen.

Mir graut vor einem Treiber Update. Aber ja, the Other, scheint so, als wenn die verbaute OnBoard Karte da Probleme macht. Warum erst nach Monatelangem Betrieb, wer weiß das schon.

Ich hatte gestern mal den Speed auf 100 MBit im Switch gesetzt. Seit dem läuft es (noch) ohne Ausfall.
Ist aber keine Dauerlösung.

Seufz. Ja, ich mach das Update.

 

[blurrrr]

Naja, "wat mutt, dat mutt", wirst es schon überleben

 

[RudiP]

Kurzes Update.
Treiber aktualisieren scheidet aus. Habs mir angesehen und für mich beschlossen, das Risiko, etwas falsch zu machen und dann geht gar nichts mehr, ist mir zu groß.

Ich habe aber mal im BIOS das VT-d ausgeschaltet UND RX und TX Übertragungssteuerung deaktiviert. Soll bei einigen geholfen haben.
Läuft jetzt seit einigen Stunden ohne Probleme, aber aus Erfahrung weiß ich, dass das noch nichts zu heißen hat.
In ein paar Tagen weiß ich sicher mehr.

 

[RudiP]

Leider hat auch das nichts geholfen. Er lief zwar jetzt ne weile ohne Probleme, aber gegen 22:xx hat er dann wieder gehangen.

Ich habe auch eine andere PCI Netzwerkkarte (Realtek 8139) eingebaut, bekomme die aber nicht zum laufen und keine Ahnung, wie man Treiber installiert. Was ich da im Internet gefunden habe, muß man entweder selbst kompilieren oder nutzt Befehle, die ich bei Proxmox gar nicht habe.

 

[blurrrr]

Was heisst denn, dass Du sie nicht zum laufen bekommst? Wird die NIC mit lspci | grep Ethernet (oder lshw -C network) angezeigt, oder taucht sie da auch schon nicht auf? Falls sie dort auftaucht... Interface via ip a zu sehen?

 

[Confluencer]

Ich weiß gar nicht wie das Verhalten ist, wenn man nachträglich eine Nic hinzufügt.

Ist Ewigkeiten her, dass ich sowas gemacht habt. Muss man die noch manuell in /etc/network/interfaces eintragen, oder sollte die Oberfläche es direkt erkennen?

Mit lspci -k | grep Ethernet -A3 sollte man auch sehen können welcher Treiber verwendet wird. Danach kann man mit dmesg | grep <kernel module> (<kernel module>=Wert von "Kernel driver in use" vom vorherigen Befehl) herausfinden welchen Namen das Gerät bekommen hat.

Ich kann mir gut vorstellen, dass man den Eintrag selbst in der /etc/network/interfaces machen muss, bevor man das Gerät in der UI sehen kann. Am Ende bin ich mir aber nicht sicher, ob es notwendig ist, oder nicht.

 

[blurrrr]

Ich habe auch eine andere PCI Netzwerkkarte (Realtek 8139) eingebaut,

Mir kam das mit dem "PCI" schon direkt merkwürdig vor...:

RTL8139

PCI

10BASE-T, 100BASE-TX

(Quelle: https://de.wikipedia.org/wiki/Realtek)

Das Ding scheint ja wohl schon "etwas" älter zu sein (25+ Jahre?) Aufgabe für heute: Ab in den nächsten Laden (Mediamarkt, Saturn, sonstiger Laden für Computer-Zubehör) und eine NIC besorgen, bitte irgendwas aus den letzten 10 Jahren ().

 

[RudiP]

Was heisst denn, dass Du sie nicht zum laufen bekommst? Wird die NIC mit lspci | grep Ethernet (oder lshw -C network) angezeigt, oder taucht sie da auch schon nicht auf? Falls sie dort auftaucht... Interface via ip a zu sehen?

04:00.0 Unassigned class [ffff]: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev ff)
Kernel modules: 8139cp, 8139too
Erkannt wird sie wohl schon, aber halt nicht nutzbar.
und nein, bei ip a ist die nicht zu sehen.

Das Ding scheint ja wohl schon "etwas" älter zu sein (25+ Jahre?) Aufgabe für heute: Ab in den nächsten Laden (Mediamarkt, Saturn, sonstiger Laden für Computer-Zubehör) und eine NIC besorgen, bitte irgendwas aus den letzten 10 Jahren ().

Hallo ? Ich bin auch schon 25+. Mal ganz nett bleiben, von wegen Altersdiskriminierung.
Ja, die kann durchaus was älter sein, aber ich dachte, das Linux doch damit klar kommen sollte. Windows kann es ja auch.
Aber gut. Kommende Woche erst mal Urlaub, muß ich dann halt 2, 3 mal am Tag rein gucken, ob HA noch läuft oder nicht.

 

[blurrrr]

Kernel modules: 8139cp, 8139too

Schauste mal mittels lsmod nach, ob da auch entsprechendes geladen wird. "cp" ist wohl die ältere Variante, von daher sollte theoretisch die "too"-Variante geladen sein. Falls nicht: modprobe 8139too.

aber ich dachte, das Linux doch damit klar kommen sollte

Najo, "irgendwie" kriegt man oftmals noch was zum laufen, aber mir stellt sich eigentlich primär die Frage, was genau Du mit "100"Mbit willst?

 

[RudiP]

Schauste mal mittels lsmod nach, ob da auch entsprechendes geladen wird. "cp" ist wohl die ältere Variante, von daher sollte theoretisch die "too"-Variante geladen sein. Falls nicht: modprobe 8139too.

Es gibt einen Eintrag

8139too 45056 0

used = 0. Hmmm
modprobe habe ich mal gemacht, denke aber, reboot muß dann wohl gemacht werden.

Najo, "irgendwie" kriegt man oftmals noch was zum laufen, aber mir stellt sich eigentlich primär die Frage, was genau Du mit "100"Mbit willst?

Es geht primär nur darum, festzustellen, woher der Fehler kommt, das die Schnittstelle immer wieder mal ausfällt. Da ist mir der Speed erst mal egal.

 

[RudiP]

reboot ist durch und lsmod liefert

Module Size Used by
8139too 45056 0
8139cp 40960 0
mii 20480 2 8139cp,8139too

bei ip a sehe ich auch nur die bisherige Netzwerkkarte und wenn ich das Kabel umstecke und boote, komme ich an Proxmox nicht mehr dran, außer über die lokale Konsole.