Proxmox-Kernel 6.14 wurde gerade fallengelassen, und Homelab-Admins spüren, wie der Boden wackelt

Kernel-News kommt normalerweise wie trockener Toast daher: notwendig, technisch und leicht zu ignorieren, bis etwas kaputtgeht. Diesmal nicht. Proxmox' Kernel-Serie auf Basis von 6.14 ist jetzt aus dem Support gefallen, und die Ankündigung hat einen sehr spezifischen Nerv in der Community getroffen. Die offizielle Botschaft war klar genug: 6.14 hatte bereits länger gelebt als geplant, die Zahl problematischer Issues wurde zu hoch, und die unterstützten Pfade bedeuten jetzt 6.8 für Proxmox VE 8, 6.17 für Proxmox VE 9, und 7.0 als nächster Standard für VE 9. Aber für Nutzer, die wegen ihres Hardware-Stacks auf 6.14 fixiert waren, war das keine Aufräumarbeit. Es war ein Schubs.

Das Problem ist nicht nur das Updaten

Auf dem Papier klingt „auf einen unterstützten Kernel wechseln“ vernünftig. In der Praxis sind Homelab-Systeme keine sauberen kleinen Diagramme. Sie sind voll mit durchgereichten Controllern, alternden GPUs, DKMS-Treibern, ZFS-Pools und zufälligen Hardware-Kombinationen, die erst nach drei Wochenenden Fluchen funktioniert haben. Ein Nutzer sagte, er habe nach DMAR-Fehlern auf 6.17.9 auf 6.8 zurückgepinnt. Ein anderer steckte wegen NVIDIA-Treibern und Container-Passthrough seit Ewigkeiten auf 6.14 fest. Das ist die Art von Detail, die einen Kernel-Sunset weniger wie ein Routine-Upgrade und mehr wie jemanden fühlen lässt, der die Seilbrücke kappt, während die Leute noch drüberlaufen.

Die Ankündigung kam auch mit einer zweiten tickenden Uhr: 6.17 soll ab Anfang Juli anfangen auszulaufen und sich in Richtung Best-Effort-Updates verschieben. Das bedeutet, die „sichere Mitte“ fühlt sich auch nicht besonders dauerhaft an. Kernel 7.0 ist der zukünftige Pfad, aber zukünftige Pfade sind genau dort, wo sich seltsame I/O-Probleme, fehlgeschlagene Treiber-Builds und Passthrough-Randfälle gerne verstecken. Die Leute lehnen die Änderung also nicht ab, weil sie faul sind. Viele von ihnen rechnen gerade durch, was schlimmer ist: unsupporteten Code zu betreiben oder eine funktionierende Maschine zu sprengen.

DMAR, Passthrough und der Horror von Fast-stabilen Systemen

Die schärfste Angst im Thread kam von Passthrough-Nutzern. Jemand verlinkte eine DMAR-Regression mit Alder-Lake-Hardware und fragte, ob die Bugs behoben seien. Sie hatten SATA- und NVMe-Geräte per vollem PCI-Passthrough durchgereicht und dann nach einem Scrub eine ZFS-Korruption erlebt, woraufhin sie das Array neu aufbauen mussten. Das ist kein Vorfall, den man einfach abschüttelt. Sobald Storage betroffen ist, fühlt sich jedes Kernel-Upgrade wie eine Geiselverhandlung an. Klar, man hat Backups. Man erinnert sich auch genau an das Geräusch, das der eigene Magen gemacht hat, als der Pool das letzte Mal aus der Bahn geriet.

Es gab allerdings auch Gegenstimmen. Ein anderer Nutzer mit einem Supermicro-Board und einem Intel i9-14900K sagte, er reiche einen eingebauten SATA-Controller an TrueNAS in einer VM durch und habe diese DMAR-Meldungen nicht gesehen, während er mit den Kerneln aktuell blieb. Jemand anders schlug vor, intel_iommu=sp_off zu probieren, und ein anderer sagte, diese Option habe bei ähnlichen 10G-NIC-Passthrough-Problemen geholfen. Das ist der seltsame Trost dieser Threads: Niemand hat eine einzige saubere Antwort, aber der Haufen von Hardware-Geschichten wird zu einer eigenen Troubleshooting-Karte. „Funktioniert bei mir“ ist kein Beweis. Aber es ist trotzdem eine nützliche Taschenlampe.

NVIDIA-Nutzer stecken immer noch im Keller

Dann ist da noch NVIDIA, weil es immer NVIDIA gibt. Ein Nutzer mit einer GPU der 1000er-Serie sagte, er könne das NVIDIA-Modul auf Kernel 6.17 immer noch nicht bauen. Ein anderer hatte eine GTX 1070 zum Encodieren und wollte wissen, ob die Treibersituation sicher sei, bevor er neuere Kernel anfasst. Jemand bot tatsächlich einen Rettungsanker: Er habe NVIDIA-550-Treiber über ein GitHub-Repo zum Bauen und Laufen mit Kernel 7.0 gebracht. Die Antwort war dankbar, aber vorsichtig. Ein maßgeschneidertes Skript mag den Job erledigen, aber viele Admins würden ihren Media-Stack lieber nicht mit etwas zusammenkleben, das sich anfühlt, als wäre es nur ein Repo von der Aufgabe entfernt.

Diese Spannung ist vertraut. Die Open-Source-Welt ist voller mutiger Workarounds, und viele davon sind wirklich nützlich. Aber produktionsnahe Homelabs sitzen in einer seltsamen Zwischenzone. Sie sind keine Unternehmensinfrastruktur, betreiben aber trotzdem Familienfotos, Plex-Boxen, Home-Automation, Backups, Remote-Work-Tools und manchmal echte Geschäftsdienste. „Probier einfach den gepatchten Treiber“ klingt anders, wenn die Maschine der einzige Server ist. Kernel 6.14 aus dem Support zu nehmen macht NVIDIA nicht auf magische Weise einfacher. Es macht nur das Verharren schlimmer.

Unsupportet heißt nicht gelöscht, aber es heißt einsam

Eine praktische Frage schnitt durch die Panik: Deinstalliert Proxmox automatisch unsupportete Kernel, die nicht in Benutzung sind? Die Antwort aus dem Thread war: nein, nicht direkt. Unsupportet heißt nicht, dass Proxmox in Ihr System greift und den Kernel herausreißt. Aber Debian bietet möglicherweise an, Kernel zu autoremoven, die es für nicht mehr benötigt hält, weshalb Nutzer die apt-Ausgabe tatsächlich lesen sollten, statt Ja zu hämmern wie bei einem Cookie-Banner. Es gab auch eine Warnung: Wenn Sie 6.14 jetzt entfernen, können Sie es später möglicherweise nicht mehr installieren, sobald es aus den Repositories verschwindet.

Das ist die stille Gefahr des Kernel-Pinnings. Es fühlt sich an wie Stabilität, bis es zur Sackgasse wird. Den alten Kernel zu behalten kann Zeit erkaufen, besonders wenn ein neuerer GPU-Treiber oder Passthrough kaputtmacht. Aber sobald die Sicherheitsupdates aufhören und die Pakete weiterziehen, beginnt dieses gepinnte Setup, sich in eine Insel zu verwandeln. Ein Kommentator sagte, seine Nodes seien nicht nach außerhalb des Netzwerks exponiert, und Firewall-Regeln würden den Zugriff einschränken, weshalb er das Risiko vorerst akzeptiert habe. Das ist ehrlich. Es ist auch der Satz, den jeder Admin sagt, kurz bevor er einen weiteren Posten auf den mentalen Schuldenberg legt.

Der Upgrade-Pfad ist eine Vertrauensübung

Die stärkste Meinung hier ist nicht „alle sollten heute auf 7.0 springen“ oder „ein funktionierendes System nie upgraden“. Es ist, dass Kernel-Übergänge Vertrauensübungen sind, und Proxmox-Nutzer haben ein sehr gutes Gedächtnis. Wenn ein Kernel Passthrough kaputtmacht, Storage korrumpiert oder einen DKMS-Build zerstört, vergessen die Leute das nicht nur, weil die nächste Ankündigung sagt, der ältere Branch sei erledigt. Sie wollen klare Notizen, Berichte über bekanntermaßen funktionierende Hardware, Rollback-Optionen und genug Community-Gerede, um zu wissen, ob sie in ein Minenfeld laufen. Das ist keine Paranoia. Das ist Wartung.

Trotzdem ist für immer eingefroren zu bleiben kein Plan. Der vernünftige Weg ist unspektakulär, aber real: Backups aktuell halten, sicherstellen, dass noch ein bootfähiger älterer Kernel vorhanden ist, den neuen Kernel testen, bevor irgendetwas entfernt wird, apt wie ein Falke beobachten und hardwarespezifische Berichte lesen, bevor man den eigenen eigenwilligen Stack der Zukunft anvertraut. Der Abgang von Kernel 6.14 tut weh, weil er eine Entscheidung erzwingt, die Nutzer bereits hinausgezögert hatten. Und deshalb fühlt sich der Thread so angespannt an. Niemand ist sauer, dass unsupportete Software irgendwann stirbt. Sie sind sauer, weil es für manche Systeme die letzte Version war, die funktioniert hat.