[SOLVED] Nach Netzwerkausfall hängt shutdown/boot Prozess bei pve-cluster filesystem

ViennaTux

ViennaTux

Well-Known Member
Proxmox Subscriber
Sep 11, 2017
70
20
48
56
Wien
www.pinguin-systeme.at
Letztens ist beim neu laden der Netzwerk-Konfiguration ein Fehler aufgetreten, konkret wurde der Parameter "hwaddress" in /etc/network/interfaces als falsch moniert und die NW Konfiguration nicht geladen. Der Parameter ist aber seit mindestens einem Reboot drin.
Da ich remote drauf war - so wie 19 mal vorher - war natürlich die Verbindung weg.
Beim Neustart über die Konsole blieb proxmox beim shutdown hängen beim Punkt "Stop pve-cluster filesystem" ohne irgendeine Reaktion.
Die Person vor Ort hat nach einer Stunde die Maschine aus- und wieder eingeschlatet, da blieb der boot-Prozess dann an der selben Stelle hängen, nachdem er zuvor schon einen Datastore nicht finden konnte.

Nach dem dritten erfolglosen Versuch konnte ich in die emergency shell und dort sowohl den datastore einhngen als auch die nw Konfig korrigieren. Das hat aber nichts mehr gebracht, die Maschine kommt nicht mehr hoch.
Kennt das jemand? Gibt's dazu vielleicht eine Idee für den Grund?

TIA
 
Last edited:
bitte den genauen fehler, das boot journal (journalctl -b0) und die interfaces files (normal und .new) posten..
 
Leider existiert das alles nicht mehr, da ich nicht mehr in der Lage war, irgendetwas an der OS Platte zu machen, oder von dort logs zu sichern. Zum Glück waren die VM Disks auf anderen Platten gesichert, die ich durch ausbauen und späteres neu einlesen weiterverwenden konnte.
Die pve Installation mußte ich, da die Zeit drängte und der komplette Betrieb des Kunden stand, neu hochziehen.
(Bitte keine Diskussion über Redundanzen, Backups und Ausfallsicherheit an dieser Stelle, der Kunde ist so schon mühsam genug und wird mir den Schaden umhängen wollen)
 
kein problem - ohne wirds nur schwer die ursache zu finden ;) falls es nochmal auftritt (oder sich in einem nachgebauten testsystem reproduzieren laesst) waere mindestens das interfaces file alt/neu wichtig!
 
interfaces hat sich nur durch die Zeile
hwaddress xx:xx:xx:xx:xx
unterschieden.
Die Option ist bei mir auf fast allen Maschinen die ich über 6.1 bis 7 hochgezogen habe drin gewesen und hat nie Probleme bereitet.
Beim Reboot ist die Maschine anscheinend ohne NW hochgekommen und hat angefangen, pve cluster zusammenzustoppeln (zumindest wirkt es so). Die Frage ist, ob es sowas wie eine "default" Netzwerk-Konfig gibt, mit der px das cluster filesystem versucht zusammenzustellen, wenn kein Netz vorhanden ist.
 
nein - das cluster filesystem weigert sich sogar zu starten, wenn der hostname nicht auf eine lokal konfigurierte IP adresse aufloest.. ("Unable to get local IP address" im log). ich vermute auch eher dass die hwaddress zeile nicht das eigentliche problem war - vll ein copy-paste fehler oder aehnliches der ifupdown2 irgendwo grundsaetzlich falsch abbiegen hat lassen .. wurde das interfaces file haendisch bearbeitet oder ueber die API/GUI?

edit: korrektur, das pmxcfs verlangt nur das die aufloesung klappt, nicht dass die addresse auch konfiguriert ist. "default netzwerkkonfig" gibts in dem sinn trotzdem keine, abgesehen vom immer vorhandenen loopback interface lo.
 
Last edited:
Naja, die hwaddress Zeile stand seit mind. 3 reboots drin, der letzte edit war über die UI, da wurde aber nur ein comment gesetzt bei vmbr0.

Meine Vermutung bzgl. Netzwerk kam (auch) daher, dass der Kunde ohne mein Wissen (und leider auch ohne grundlegende Kenntnisse der Netzwerktechnik im Allgemeinen) einen Multiport WAN Router angesteckt hatte, der auf dem selben physischen Netzwerk eine zusätzliche IP Range mit dazugehörigem DHCP Server angeboten hat. Also Marsianer wohin man schaute.
Deshalb die Frage nach deiner "Notfall" oder Fallback Netzwerk-Konfig.

Ich werde also nicht mit Sicherheit sagen können was passiert ist. Richtig?
 
klingt nach vielen moeglichen fehlerquellen.. aber ja, vermutlich hat der zusaetzliche router/dhcp server sowohl den reload als auch den boot blockiert (wie genau kann ich aus der ferne/ohne kenntnis des netzwerk aufbaus und der konfig nicht sagen).. der reload war dann nur die gelegenheit, bei der das problem von 'latent' zu 'akut' geworden ist (z.b. weil ein dhcp lease hergebenen worden ist, aber kein neuer mehr zu bekommen war..)
 
Der Aufbau wäre relativ einfach:

eine UTM, die Basis DHCP und DNS spielt, so lange, bis der virtualisierte DNS/DHCP Server auf proxmox da ist, dann ist sie nur mehr Fallback.
Eine IP Range Klasse C, und da spukt ein rogue dhcp mit einer anderen Klasse C Range hinein. Da die UTM immer zuerst checkt, ob der interne Server da ist, ist der rogue vermutlich schneller -> und schon ist der palawatch fertig...
Aber kann das den boot prozess so durcheinander bringen?
 
wie gesagt - ohne logs wahrscheinlich schwer zu eruieren was genau schief gegangen ist.. aber ja, kaputtes/gestoertes netzwerk setup kann definitiv dazu fuehren dass der boot haengt
 
You must log in or register to reply here.
Top Bottom