Proxmox, Stromausfälle und das eine Mal, als initramfs klammheimlich meine Woche ruinierte

Stromausfälle sollen eigentlich langweilig sein. Das Licht geht aus, das Licht geht wieder an, und vielleicht blinkt die Mikrowellenuhr wieder 12:00, als wäre es 1998. Im Homelab können sie sich jedoch zu etwas deutlich Dramatischerem auswachsen — der Sorte, bei der der Server mit einem schwarzen Bildschirm und einer kryptischen Fehlermeldung startet, die für die Situation viel zu gelassen wirkt.

Genau so hat diese Woche angefangen.

Nach einem kurzen Stromausfall zu Hause kam mein Proxmox-Server wieder hoch … so halb. Das BIOS lud. GRUB erschien. Der Kernel startete. Und dann blieb alles stehen, mit einer Meldung, die im Grunde sagte: „Root-Dateisystem nicht eingehängt". Keine Shell. Kein Login. Kein freundlicher Recovery-Prompt. Nur ein System, das sich absolut weigerte, weiterzumachen.

Wenn Sie Proxmox zu Hause betreiben, kommt Ihnen diese Geschichte vielleicht unangenehm bekannt vor.

Der falsche Trost von „Es lief doch gestern noch"

Einer der frustrierendsten Aspekte von Boot-Fehlern ist, wie unfair sie sich anfühlen. Nichts hat sich geändert. Keine Updates. Keine neuen Festplatten. Kein nächtliches Herumbasteln. Der Server ist ausgegangen, weil der Strom weg war, und jetzt kam er nicht mehr hoch. Das war's.

Der erste Instinkt war natürlich Verleugnung. Noch einmal neu starten. Derselbe Fehler. Einen älteren Kernel aus dem GRUB-Menü versuchen. Dasselbe Ergebnis. An diesem Punkt beginnt man, mit der Maschine zu verhandeln. Vielleicht braucht sie nur noch einen Neustart. Vielleicht behebt sich der Fehler ja wie von Zauberhand.

Tut er nicht.

Wenn Linux Ihnen mitteilt, dass es das Root-Dateisystem nicht einhängen kann, übertreibt es nicht. Irgendetwas wirklich Wichtiges fehlt, ist defekt oder nicht lesbar. Und ist dieser Punkt erst erreicht, führt kein eleganter Weg mehr daran vorbei, sich die Ärmel hochzukrempeln.

Boot-Fehler, die Ihnen fast nichts verraten

„Root fs not mounted" klingt eindeutig — bis man merkt, wie viele Dinge das bedeuten könnte.

• Ist die Festplatte defekt?
• Ist das Dateisystem beschädigt?
• Hat sich die UUID geändert?
• Fehlen dem Kernel Treiber?
• Ist initramfs kaputt?

Dem System ist es egal, welcher Fall zutrifft, und es wird Ihnen nicht dabei helfen, das einzugrenzen. Das ist Ihr Job.

Der erste wirkliche Schritt war der Start von einer Live-Umgebung. Jedes Linux-Live-ISO tut es, aber auch der Proxmox-Installer selbst eignet sich gut zur Wiederherstellung. Ist man erst einmal drin, sieht man endlich, was die Maschine sieht.

Die Laufwerke waren da. Die Partitionen sahen normal aus. Die ZFS-Pools importierten sauber. Keine offensichtliche Dateisystem-Beschädigung. Damit waren die Alptraum-Szenarien vom Tisch.

Warum also konnte das System nicht booten?

initramfs: Kleine Datei, riesige Verantwortung

Wenn Sie bisher noch nie über initramfs nachdenken mussten: Glückwunsch. Das bedeutet, es hat still und leise seine Arbeit gemacht.

initramfs ist ein winziges, temporäres Dateisystem, das beim frühen Boot-Vorgang in den Speicher geladen wird. Sein einziger Zweck ist es, die Treiber und Module zu laden, die der Kernel braucht, um Ihr eigentliches Root-Dateisystem zu finden und einzuhängen. Fehlt ihm ein Storage-Treiber, ein Dateisystem-Modul oder irgendetwas Kritisches, läuft der Kernel gegen eine Wand und gibt auf.

Stromausfall während eines Updates ist eine der einfachsten Arten, es kaputtzumachen.

Und ist initramfs erst einmal defekt, sehen die Symptome genau wie ein totes System aus — selbst wenn Ihre Festplatten völlig in Ordnung sind.

Der Fix, der „eigentlich einfach" sein sollte — und es nicht war

In der Theorie ist die Lösung einfach: initramfs neu erzeugen.

Aus einer chroot- oder Recovery-Shell heraus führt man den üblichen Befehl aus, um es für die installierten Kernel neu zu bauen. Auf den meisten Systemen ist das dann auch schon erledigt.

Nur dieses Mal eben nicht.

Jeder Versuch, initramfs neu zu bauen, schlug fehl. Und das nicht mit einer hilfreichen Fehlermeldung. Nur gerade genug Ausgabe, um zu zeigen, dass etwas nicht stimmte, gefolgt von einem abrupten Abbruch. Auf den ersten Blick sah es nach einer weiteren kaputten Abhängigkeit oder einem halb installierten Paket aus.

Hier wurde es interessant.

Das Paket, von dem Sie vergessen hatten, dass Sie es je installiert haben

Monate zuvor hatte ich vorübergehend eine alte NVIDIA-GPU in den Server eingebaut. Ein schnelles Experiment, nichts Ernstes. Ich installierte ein Helper-Paket, um die GPU-Virtualisierung zu erleichtern, testete es und baute die Karte irgendwann wieder aus.

Was ich offenbar nicht entfernt hatte, war alles andere.

Dieses NVIDIA-Helper-Paket hatte sich still und heimlich gehalten. Und jetzt, bei der initramfs-Generierung, scheiterte es krachend, weil die Hardware, die es erwartete, schlicht nicht mehr da war.

Unter normalen Umständen würde man das nie bemerken. Das System bootete problemlos. Updates funktionierten. Das Leben ging weiter.

Bis der Strom ausfiel.

Wenn alte Experimente einen wieder einholen

Das ist der Teil, der am meisten wehtut. Der Fehler wurde nicht durch etwas verursacht, das ich kürzlich getan hatte. Es war kein riskantes Update und keine übereilte Konfigurationsänderung. Es waren technische Schulden. Von der Sorte, die man vergisst, weil sie sich nie beschwert.

initramfs ist es egal, wie alt ein Paket ist. Ist es in den Boot-Prozess eingeklinkt und schlägt fehl, geht das gesamte System mit unter.

Nachdem die NVIDIA-Pakete vollständig entfernt waren — nicht nur die offensichtlichen, sondern alle Helper und Abhängigkeiten —, funktionierte der Rebuild endlich. initramfs wurde sauber neu erzeugt. Die Kernel bauten ohne Fehler.

Beim nächsten Neustart kam das System zurück, als wäre nie etwas gewesen.

Warum saubere Shutdowns das kaum verursachen

Das sei einmal ausdrücklich gesagt: Ein normaler Neustart oder Shutdown verursacht so gut wie nie diese Art von Problem. Moderne Dateisysteme schützen sich selbst gut. initramfs-Updates sind in der Regel atomar.

Aber ein Stromausfall kümmert sich nicht um Timing.

Wenn der Strom gerade in dem Moment ausfällt, in dem das System Kernel aktualisiert, initramfs neu baut oder Bootloader-Dateien anfasst, würfeln Sie mit dem Schicksal. Meistens gewinnen Sie. Manchmal eben so gar nicht.

Lektionen, die man sich schwer erarbeitet hat

Ein paar Erkenntnisse bleiben, wenn sich der Staub gelegt hat.

Erstens: initramfs verdient mehr Respekt, als es bekommt. Es ist klein, unsichtbar und absolut essenziell. Wenn es kaputtgeht, humpelt das System nicht weiter — es bleibt einfach stehen.

Zweitens: Alte Pakete spielen eine Rolle. Besonders solche, die sich in systemnahe Bereiche einklinken. Wenn Sie mit dem Experimentieren fertig sind, räumen Sie richtig auf. Ihr zukünftiges Ich wird es Ihnen danken.

Drittens: Wiederherstellung ist oft möglich. Boot-Fehler fühlen sich katastrophal an, aber meistens sind die Daten in Ordnung. Das Betriebssystem braucht nur Hilfe, sich selbst nicht mehr im Weg zu stehen.

Und schließlich: Ja, legen Sie sich eine USV zu.

Ein kurzer Stromausfall sollte eigentlich nicht reichen, um Ihre Woche zu ruinieren, aber ohne Batteriepufferung kann er das durchaus. Eine USV mit sauberer Shutdown-Signalisierung zu kombinieren, ist eine dieser langweiligen Investitionen, die sich erst an dem Tag aufregend anfühlen, an dem sie Sie retten.

Die leise Art von Fehler, aus der man am meisten lernt

Es gibt etwas einzigartig Frustrierendes an einem Problem, das sich erst bemerkbar macht, wenn gar nichts mehr geht. Keine Warnungen. Kein Degraded Mode. Nur ein totenstiller Server nach einem kurzen Flackern des Lichts.

Aber genau das sind auch die Fehler, aus denen man am meisten darüber lernt, wie das eigene System wirklich funktioniert. Nicht die glänzenden Teile. Die frühen Boot-Schritte. Die winzigen Dateien, die alles zusammenhalten.

initramfs hat mir die Woche ruiniert, klar. Aber es hat sich auch einen festen Platz auf der mentalen Checkliste verdient.

Beim nächsten Stromausfall weiß ich wenigstens, wo ich zuerst nachsehen muss.