Proxmox-Kernel-Updates sind anstrengend, sie zu ignorieren fühlt sich aber noch schlimmer an

Kernel-Updates kommen in letzter Zeit so schnell, dass selbst geduldige Proxmox-Nutzer allmählich die Nase voll haben. Ein Admin brachte die Erschöpfung auf den Punkt: Für ihn heißt ein Update, alles herunterzufahren, den Kernel einzuspielen, neu zu booten und dann alles wieder hochzufahren, und das erledigt man nicht mit einem beiläufigen Klick. Macht man das drei- oder viermal in kurzer Folge, fühlt sich selbst verantwortungsvolle Wartung wie ein Laufband mit Login-Prompt an. Seine Frage war einfach: Gibt es wirklich so viele Bugs und Probleme, oder ist das einfach das neue Normal? Die Antwort des Threads lautete im Grunde ja, ja, und leider auch ja.

Viele Updates hängen an benannten Sicherheitslücken

Die stärkste Antwort räumte sofort mit dem Nebel auf: Eine ganze Reihe der jüngsten Kernel-Updates hing mit benannten Sicherheitsproblemen wie CopyFail, DirtyFrag, CIFSwitch, Fragnesia, DirtyDecrypt und PinTheft zusammen. Der Kommentator beschrieb sie als lokale Privilege-Escalation- und Container-Escape-Schwachstellen, was in einem Proxmox-Kontext ein ganz anderes Gewicht hat. Auf einem Desktop stürzt vielleicht eine seltsame App ab und man seufzt, auf Proxmox laufen dagegen Gäste, Container, Storage und Netzwerkdienste. Wenn lokale Privilege-Bugs oder Container-Escape-Pfade im Spiel sind, sieht das Kernel-Karussell weniger nach Beschäftigungstherapie aus und mehr nach Schadensbegrenzung.

Nerven tut der Prozess trotzdem, nur lässt sich der Ärger jetzt leichter rechtfertigen. Jemand sagte, häufige Updates seien lästig, aber vernachlässigte Infrastruktursoftware sei um Längen schlimmer. Ein anderer kämpfte nach eigener Aussage lieber mit Updates als mit den Folgen fehlender Updates. Es ist ein düsterer Deal, denn niemand liebt es, Hosts durchzustarten oder Reboots um laufende Dienste herum zu planen, aber die Alternative wäre, so zu tun, als würden Schwachstellen höflich warten, bis das Wochenende frei ist, und das tun sie nicht. Security-Arbeit hat eben schlechte Manieren.

Update-Müdigkeit ist real

Im Kern ging es im Thread um Erschöpfung, und kaum jemand wollte das Problem wegreden. Ein Kommentator hieß alle im „jetzigen Leben" willkommen und gab zu, bereits Update-Müdigkeit zu spüren. Diese Formulierung trifft, weil sie ein sehr modernes Admin-Problem beschreibt. Die Tools sind besser, die Alerts schneller, die Schwachstellen sichtbarer, und trotzdem muss irgendwann ein Mensch entscheiden, wann er den Knopf drückt. Im Homelab ist dieser Mensch meist auch der Storage-Admin, der Netzwerktechniker, der Incident-Responder und diejenige Person, die einen Film schauen will, ohne die Kiste neu zu starten, auf der alles läuft.

Manche Nutzer spüren den Schmerz stärker, weil ihr Update-Prozess mehr Risiko birgt. Jemand erzählte von einem Remote-System ohne IPMI, bei dem jedes Kernel-Update zu einer kleinen Wette wird: normaler Tag, oder ein halber Sonntag damit verbracht, hinzufahren und eine Maschine zu reparieren, die nicht mehr hochkam? Übertrieben ist das nicht. Wer schon einmal Hardware ohne Kopf und ohne ordentliche Remote-Konsole verwaltet hat, kennt dieses kalte Gefühl. Kernel-Updates mögen notwendig sein, aber Notwendigkeit fügt alter Hardware nicht auf magische Weise Out-of-Band-Management hinzu.

Rollback ist das Sicherheitsventil

Der größte Trost im Thread war, dass Proxmox einen Kernel-Rollback recht zugänglich macht. Ein Nutzer sagte, er habe Updates gemieden, nachdem ein Kernel auf Intel-Systemen nicht mehr gebootet hatte, woraufhin ein anderer darauf hinwies, dass das Zurückrollen auf einen vorherigen Kernel einfach sei. Jemand anderes war begeistert, dass man einen alten Kernel booten, den guten fixieren und einfach weitermachen könne. Schnelle Update-Zyklen sind viel leichter zu ertragen, wenn die Plattform so eine vernünftige Notausgangstür bietet.

Das Risiko verschwindet durch einen Rollback allerdings nicht, es wird nur überlebbar. Die schlimmsten Bugs, wie es ein Kommentator formulierte, sind die, die nicht sofort auffallen. Ein Kernel, der nicht bootet, ist erschreckend, aber immerhin offensichtlich. Ein subtiles Storage-Problem, seltsames Passthrough-Verhalten, ein sporadischer Netzwerkbug oder ein Container-Isolationsfehler kann viel fieser sein, weil man denkt, alles sei in Ordnung, bis es das nicht mehr ist. Deshalb fühlen sich Kernel-Updates wie eine psychologische Steuer an: Neben „Bootet es?" steht immer auch die Frage „Was hat sich verändert, das ich erst nächste Woche merke?"

Automatisierung wurde zum Fluchtplan

Sobald der Thread akzeptiert hatte, dass Updates nicht verschwinden, wanderte das Gespräch in Richtung Automatisierung. Ein Nutzer wollte gestaffelte Homelab-Updates, Node für Node, damit nicht die gesamte Umgebung auf einmal katastrophal ausfällt. Das ist der richtige Instinkt. Selbst in einem kleinen Lab bittet man um Ärger, wenn man jeden Host gleichzeitig zum Versuchskaninchen macht. Ein gestaffelter Rollout gibt einem die Chance, schlechtes Verhalten abzufangen, bevor es sich über den gesamten Stack ausbreitet. Glamourös ist das nicht, aber so wird Wartung eben nicht zum Roulette.

Ansible wurde zur naheliegenden Empfehlung. Mehrere Kommentatoren pushten es stark, einer meinte, je früher man anfange, desto besser. Ein anderer sagte, Automatisierung sei das eine, das man nicht aufschieben sollte, weil man dadurch mehr Zeit habe, alles andere aufzuschieben, während die Infrastruktur wie am Schnürchen läuft. Das ist lustig, weil es stimmt. Manuelle Updates fühlen sich beherrschbar an, bis sie es plötzlich nicht mehr sind. Die ersten paar Maschinen sind einfach, dann kommen Reports, Windows-Kisten, Container, Remote-Nodes und ein verfluchter Server ohne IPMI dazu, und plötzlich sieht YAML aus wie Selbstfürsorge.

Mehr Bugs, oder bessere Taschenlampen?

Unter den Update-Beschwerden steckte auch eine größere Frage: Werden Kernel wirklich schlechter, oder finden wir nur mehr Probleme? Ein Kommentator sagte, er sei sich bei Veränderungen in Bug-Volumen und -Schwere unsicher, vermutete aber, dass LLM-gestützte Reviews und bessere Tools technische Probleme aufdecken, die zuvor übersehen wurden. Ein anderer ergänzte, dass das Volumen an Kernel-CVEs wegen neuerer Tools, mehr Prüfung und veränderter Kategorisierung von Problemen steige. Der Unterschied ist wichtig, denn mehr gemeldete Bugs heißen nicht immer, dass Software zusammenbricht. Manchmal ist nur das Licht heller geworden.

Natürlich zeigen hellere Lichter auch hässliche Räume. Ob die Fehler neu sind oder nur neu entdeckt, Admins müssen sie patchen. Unangenehm daran ist, dass sich ein gesünderer Security-Prozess im Alltag trotzdem schlimmer anfühlen kann, weil er mehr sichtbare Arbeit erzeugt. Die Maschine war vorher nie magisch sicher; man bekam nur weniger Erinnerungen daran. Jetzt wird jedes Changelog zu einem kleinen Angstpaket. Ein Kommentator empfahl, das Changelog direkt in der GUI zu prüfen, indem man auf das Kernel-Paket klickt und das Changelog öffnet. Das ist guter Rat, weil Ungewissheit die Müdigkeit verschlimmert, und wer weiß, was sich geändert hat, kennt wenigstens den Grund für den Reboot.

Das ist Wartung, die erwachsen wird

Die Antwort auf die Ausgangsfrage ist unübersichtlich. Ja, es gab viele Kernel-Updates, viele hängen mit echten Sicherheitsfixes zusammen, und das Tempo ist anstrengend. Trotzdem ist es meist die schlechtere Wette, sie zu ignorieren. Proxmox-Nutzer stecken am selben Punkt wie der Rest der modernen Infrastruktur, mit mehr Prüfung, mehr Patches, mehr Offenlegung und mehr Verantwortung. Das macht keinen Spaß, ist aber auch kein Zeichen, dass alles verloren ist.

Gesünder ist ein fester Rhythmus, in dem ein Kernel-Update kein eigenes Ritual mehr braucht. Lesen Sie Changelogs, behalten Sie Rollback-Optionen und entfernen Sie bekannt gute Kernel nicht zu schnell. Automatisieren Sie, was sich automatisieren lässt, und staffeln Sie Updates, statt jeden Node gleichzeitig zu treffen. Sorgen Sie außerdem dafür, dass Remote-Maschinen einen Rettungsplan haben, besonders wenn ihnen IPMI fehlt. Das Update-Laufband wird sich vielleicht nicht bald verlangsamen, aber es kann weniger persönlich werden: Die Zahl der Patches bleibt, nur die Herzinfarkte pro Patch werden weniger.