Kernel 7.0 hat die Container zerschossen, und plötzlich fühlte sich das „einfache Upgrade“ gar nicht mehr so einfach an

Der Neustart, der aus Zuversicht Panik machte

Es gibt eine ganz besondere Stille nach einem Server-Neustart. Sie kennen die. Die Lüfter beruhigen sich, die Login-Seite kommt zurück, das Dashboard füllt sich langsam, und für ein paar Sekunden denken Sie, die Upgrade-Götter hätten heute vielleicht ein Einsehen gehabt. Dann bemerken Sie den seltsamen Teil: Die VM startet, aber jeder LXC-Container ist tot. Nicht langsam. Nicht unglücklich. Einfach nur startunwillig.

Genau das hat diese Kernel-7.0-Upgrade-Geschichte zu einem echten Nerv-Treffer gemacht. Ein Homelab-Nutzer spielte das Update ein, startete den Proxmox-Host neu, und plötzlich warfen sämtliche Container Fehler, während die virtuelle Maschine durchlief, als wäre nichts gewesen. Das ist die Art von Problem, die sich persönlich anfühlt, weil Container eigentlich der leichtgewichtige, effiziente, unkomplizierte Teil des Stacks sein sollen. Dort parken die Leute DNS, Dashboards, Media-Tools, Automatisierung, Passwortmanager, Monitoring und all die kleinen Dienste, die ein Homelab lebendig wirken lassen. Wenn sie alle gleichzeitig ausfallen, kann sich das ganze Haus kaputt anfühlen.

Die Lösung war am Ende überraschend simpel: lxc-pve und pve-container neu installieren, dann den Host neu starten. Das ist eine gute Nachricht. Es ist aber auch die Art von guter Nachricht, die erst ankommt, nachdem einem schon der Magen in die Kniekehlen gerutscht ist. Denn wenn der Fehler zum ersten Mal auftaucht, steht da nicht: „Keine Sorge, eine Paket-Neuinstallation regelt das.“ Es sieht so aus, als wäre der Kernel gesprungen, die Container-Schicht gestolpert, und jetzt stehen Sie im Trümmerfeld und versuchen sich zu erinnern, welche Dienste eigentlich am wichtigsten waren.

LXCs leben näher am Explosionsradius

Ein Kommentator brachte es mit einem Satz auf den Punkt, der erklärt, warum sich diese Art von Ausfall so plausibel anfühlt: LXCs laufen auf dem Kernel des Hosts. Das ist der Deal. Anders als eine vollständige VM, die ihren eigenen Guest-Kernel mitbringt und eine stärkere Grenze zu den beweglichen Teilen des Hosts hat, lehnt sich ein Container direkt an den Host-Kernel und die Userspace-Verkabelung drumherum an. Deshalb sind Container schnell und effizient. Und deshalb kann ein Upgrade auf Host-Ebene ihnen mitten ins Gesicht schlagen.

Das heißt nicht, dass LXCs zerbrechlicher Schrott sind. Sie sind unglaublich nützlich. Aber sie leben eben näher am Explosionsradius, wenn sich der Host verändert. Ein großes Kernel-Update ist nicht einfach nur eine Zahl, die im Hintergrund eins weiterspringt. Es kann Annahmen rund um cgroups, Namespaces, AppArmor, Mount-Verhalten, LXC-Binaries, Proxmox-Container-Tools und all die Dinge berühren, an die Nutzer erst denken, wenn sie kaputtgehen. Wenn die VM weiterhin startet und die Container nicht, ist das kein Zufall. Das ist Architektur, die ihre Zähne zeigt.

Jemand witzelte, es fühle sich immer so an, als wären es die LXCs, die bei Updates leiden müssen. Das ist etwas unfair, aber leicht nachvollziehbar. Für Homelab-Nutzer werden LXCs oft zum Standardort für alles Kleine. Wenn sie also kaputtgehen, fühlt sich das nicht wie der Ausfall eines einzelnen Dienstes an. Es fühlt sich an, als wäre die gesamte Komfort-Schicht eingestürzt. Ihre VM mag in Ordnung sein, klar. Aber das Dutzend kleiner Dinge, die den Alltag angenehmer machen, hängt jetzt hinter einer Fehlermeldung fest – begleitet von einem flauen Gefühl im Magen.

Die Logs waren chaotisch, und die Ratschläge wurden es auch

Die Fehlersuche begann dort, wo sie meistens beginnt: bei den Logs. Jemand schlug vor, /var/log/syslog zu prüfen, was sofort zu einem eigenen Mini-Drama wurde, weil das System diese Datei gar nicht hatte. Der Nutzer versuchte es mit tail -n 50 /var/log/syslog und bekam „No such file or directory“. Dann bemerkte er, dass auch /run/pve fehlte, wodurch sich das Ganze weniger wie ein einzelnes Container-Problem anfühlte und mehr so, als wäre Proxmox' Runtime-Verkabelung insgesamt entgleist.

Genau da spaltete sich der Thread zwischen alten Gewohnheiten und modernen Standards. Eine Person sagte, sie installiere immer noch überall rsyslog, weil das ihr erster Blick sei. Eine andere konterte, /var/log/syslog sei auf vielen Setups längst Geschichte, und schickte alle Richtung journalctl. Der ruhigere und nützlichere Rat war, journalctl -b, journalctl -f oder journalctl -xef auszuführen und dann erneut zu versuchen, den Container zu starten. Jemand anderes bat um pct config 101 und pct start 101 --debug – genau das langweilige, aber wirksame Diagnose-Duo, das die Sache tatsächlich voranbringt.

Die gemeldeten Logs waren wenig beruhigend. Es gab Timeouts beim Monitor-Socket, Meldungen, dass die PID für CT 101 nicht ermittelt werden konnte, und eine Beschwerde von pvestatd, dass keine Metrics-Temp-Datei unter /run/pve angelegt werden konnte, weil das Verzeichnis nicht existierte. Das ist der Teil, bei dem man die Augenbrauen hochzieht. Wenn Proxmox' Runtime-Verzeichnis fehlt, sind nicht startende Container vielleicht nur das sichtbarste Symptom. Das ist, als würde man den Lichtschalter beschuldigen, während der halbe Sicherungskasten verrücktspielt.

Die Lösung war einfach, was den Ausfall umso seltsamer wirken ließ

Die endgültige Lösung war fast schon ärgerlich simpel: apt install --reinstall lxc-pve pve-container, gefolgt von einem Host-Neustart. Das war's. Kein Kernel-Rollback. Keine verlorenen Container. Kein Wiederaufbau des gesamten Nodes aus Backups. Keine nächtliche Migration auf eine andere Maschine. Die Container-Pakete neu installieren, neu starten, und die toten LXCs waren wieder da.

Diese Art von Lösung ist gleichzeitig befriedigend und beunruhigend. Befriedigend, weil der Nutzer glimpflich davonkam. Beunruhigend, weil es nahelegt, dass irgendetwas im Upgrade-Pfad zentrale Container-Komponenten in einem schlechten Zustand zurückgelassen hat. Vielleicht installierte sich ein Paket nicht sauber. Vielleicht griff ein Post-Install-Schritt nicht. Vielleicht verbarg der Web-GUI-Upgrade-Pfad eine Warnung, die der Nutzer in einem Terminal gesehen hätte. Vielleicht brauchten die Runtime-Bestandteile eine richtige Auffrischung, die erst durch die erzwungene Neuinstallation kam. Der Thread beweist keine einzelne, saubere Ursache, aber er liefert Admins ein nützliches Muster: Wenn Kernel 7.0 landet und LXCs sich weigern zu starten, während VMs einwandfrei laufen, sollten Sie nicht sofort annehmen, dass Ihre Container ruiniert sind.

Darin steckt eine größere Lektion. Manchmal sind die gruseligsten Infrastruktur-Ausfälle keine tiefgreifende Korruption oder katastrophale Bugs. Manchmal sind es langweilige Paketzustands-Probleme, die nur deshalb katastrophal wirken, weil sie ganz unten im Stack passieren. Ein kaputter Dienst ist ärgerlich. Eine kaputte Container-Schicht fühlt sich existenziell an. Die Lösung mag ein einziger Befehl sein, aber die nötige Ruhe, um ihn auszuprobieren, muss man sich trotzdem erst erarbeiten.

Die Frage nach dem Web-GUI-Upgrade ist wichtig

Ein Detail schlich sich still hinein: Der Nutzer hatte über die Web-GUI aktualisiert. Das ist an sich nicht falsch. Proxmox gibt Nutzern nicht ohne Grund eine GUI, und viele bevorzugen sie. Aber bei großen Upgrades klingen Terminal-Puristen plötzlich weniger nervig. In einer Shell sehen Sie Prompts, Paketkonflikte, gehaltene Pakete, Warnungen und Post-Install-Meldungen in Echtzeit. In einer GUI kann sich der Prozess sauberer anfühlen, aber sauberer heißt manchmal auch weniger nachvollziehbar.

Das heißt nicht, dass alle die GUI fürchten sollten. Es heißt, je größer das Upgrade, desto mehr Transparenz wollen Sie haben. Die Leute, die fragten, wie das Upgrade durchgeführt wurde, waren nicht einfach nur neugierig. Sie wollten verstehen, ob etwas übersprungen, verborgen, unterbrochen oder in einem halb aktualisierten Zustand zurückgelassen wurde. Kernel-Upgrades, Proxmox-Paket-Updates, LXC-Userspace, Container-Management-Tools und Runtime-Verzeichnisse müssen alle zusammenpassen. Tun sie das nicht, sagt Ihnen das Dashboard nur, dass die Container nicht starten. Es sagt Ihnen nicht immer, welche Schicht vergessen hat, ihre Schuhe anzuziehen.

Hier werden erfahrene Admins ein wenig abergläubisch, aber auf nützliche Weise. Sie aktualisieren aus einer Konsole oder SSH-Sitzung innerhalb von tmux oder screen. Sie lesen die apt-Ausgabe. Sie stellen sicher, dass keine Pakete zurückgehalten werden. Sie prüfen pveversion -v. Sie starten bewusst neu, nicht weil das System sie dazu gezwungen hat. Sie testen einen unkritischen Container, bevor sie feiern. Glamourös ist das nicht. Durchschlafen zu können aber auch nicht.

Die drei Stimmungen der Community: fehlersuchen, witzeln und zusammenzucken

Die Unterhaltung bewegte sich auf drei klar erkennbaren emotionalen Spuren. Die erste war praktisch: Debug-Befehle ausführen, journalctl prüfen, die Container-Konfiguration untersuchen, den tatsächlichen Fehler finden. Das ist die beste Seite technischer Communitys. Jemand taucht gestresst auf, und Fremde fangen an, das Problem einzugrenzen, ganz ohne großen Vortrag.

Die zweite war zynischer Humor. „LXCs leiden bei Updates immer am meisten“ hat die Form eines Witzes, aber das Gewicht echter Erfahrung. Eine andere Person aktualisierte, nachdem sie kommentiert hatte, und wurde dann von einem anderen Netzwerkproblem innerhalb einer VM erwischt. Zunächst sah alles gut aus, dann brach die interne Dienst-Authentifizierung in einer seltsamen Schleife zusammen. Ein Neustart behob es, dann kam das Problem eine Stunde später zurück. Diese kleine Nebengeschichte ist wichtig, weil sie das eigentliche Zeitfenster nach dem Upgrade einfängt: Das System startet, aber Sie sind noch nicht fertig. Merkwürdigkeiten können warten. Sie können auftauchen, nachdem Dienste anfangen, miteinander zu sprechen, nachdem Caches ablaufen, nachdem geplante Jobs laufen, oder nachdem der Netzwerk-Stack genug Traffic bekommt, um den Riss offenzulegen.

Die dritte Stimmung war stille Erkenntnis. Jeder, der lange genug ein Homelab betreibt, kennt dieses Gefühl. Sie aktualisieren, weil Updates gut sind. Sie starten neu, weil sich der Kernel geändert hat. Dann hört etwas auf zu funktionieren, von dem Sie vergessen hatten, dass es kritisch ist. Plötzlich ist das Lab kein Spielplatz mehr. Es ist Infrastruktur. Es hat Nutzer, auch wenn die Nutzer nur Sie selbst, Ihre Familie und die Smart-Home-Lampen sind, die jetzt seltsam vorwurfsvoll wirken.

Container sind praktisch, bis sie zum Abhängigkeitsgraphen werden

Das ist das Tückische an LXCs in Proxmox: Sie vermehren sich, weil sie so einfach sind. Einen für DNS hochziehen. Einen für den Reverse-Proxy. Einen für Monitoring. Einen für Download-Tools. Einen für eine Datenbank. Einen für ein Dashboard. Einen für irgendein Ding, das Sie vor sechs Monaten getestet haben und auf das Sie sich jetzt irgendwie verlassen. Schon bald ist die Container-Liste keine Liste von Apps mehr. Sie ist ein Abhängigkeitsgraph im freundlichen UI-Gewand.

Wenn also nach einem Kernel-Update jeder LXC ausfällt, ist der Schaden nicht bei allen Nutzern gleich. Für die eine Person bedeutet es vielleicht, dass der Media-Stack down ist. Für eine andere, dass das lokale DNS weg ist und sich das halbe Netzwerk gespenstisch anfühlt. Für wieder jemand anderen betrifft es Authentifizierung, Automatisierung oder Backup-Orchestrierung. Deshalb kann die Reaktion auf „installiert doch einfach die Pakete neu“ sowohl Dankbarkeit als auch Genervtheit auslösen. Der Befehl ist einfach, aber das, was auf dem Spiel steht, ist es nicht.

Es steckt auch eine Identitätsfrage dahinter. Homelab-Nutzer lernen oft durch Ausprobieren, und Proxmox ist beliebt, weil es ernsthafte Virtualisierung zugänglich wirken lässt. Aber Kernel-Upgrades legen die professionelle Realität unter der freundlichen Oberfläche frei. Ein Hypervisor ist kein App Store. Container sind keine kleinen Zauberkästen. Der Host zählt. Der Paketzustand zählt. Die Logs zählen. Und ja, manchmal besteht der „beste Ansatz“ nicht darin, in der GUI herumzuklicken, sondern in eine Shell zu wechseln und das System zu fragen, was tatsächlich kaputtgegangen ist.

Das Fazit: Fürchten Sie Kernel 7.0 nicht, aber behandeln Sie es auch nicht wie ein Theme-Update

Dieser Vorfall beweist nicht, dass Kernel 7.0 eine Katastrophe ist. Er beweist nicht einmal einen breiten LXC-Bug. Der Nutzer löste das Problem mit einer Neuinstallation von Proxmox' LXC-/Container-Paketen und einem Neustart, während andere vor allem übliche Diagnoseschritte beisteuerten. Trotzdem ist das genau die Art von Beitrag, die sich vor einem großen Upgrade in den Köpfen der Leute festsetzt. Nicht weil er spektakulär war, sondern weil er glaubwürdig war.

Der vernünftige Weg ist langweilig. Erstellen Sie vor dem Upgrade Backups. Prüfen Sie, ob Sie die Container, die Ihnen wichtig sind, auch wiederherstellen können. Führen Sie das Upgrade dort aus, wo Sie es beobachten können. Nutzen Sie journalctl, statt alten Syslog-Annahmen hinterherzujagen. Testen Sie nach dem Neustart VMs und LXCs getrennt voneinander. Wenn Container ausfallen, während VMs funktionieren, schauen Sie sich pct start <id> --debug, journalctl -b, den Paketstatus und die Frage an, ob eine Neuinstallation von lxc-pve und pve-container Sinn ergibt. Klicken Sie nicht wild drauflos. Gehen Sie nicht davon aus, dass alle Container für immer tot sind. Gehen Sie nicht davon aus, dass die GUI Ihnen die ganze Geschichte erzählt hat.

Was dieser Upgrade-Schreck eigentlich sagt, ist simpel: LXCs sind mächtig, weil sie sich den Host teilen. Genau deshalb zählen Änderungen am Host auch so sehr. Kernel 7.0 mag in Ordnung sein. Proxmox mag in Ordnung sein. Ihre Container sind vielleicht nur eine Neuinstallation von „in Ordnung“ entfernt. Aber in dem Moment nach dem Neustart, wenn die VM startet und jeder LXC sich weigert, kann sich „in Ordnung“ sehr weit weg anfühlen. Das ist der Deal mit Homelab-Infrastruktur. Sie bringt einem Dinge durch kleine Katastrophen bei, und manchmal ist die Lektion nur einen Befehl lang.