Linux 7.2 erreicht Supportende, Linux 7.4-rc1 mit Rekord-Merge-Window
Greg Kroah-Hartman hat Linux 7.2.15 als letztes Release der Serie veröffentlicht und rät zum Wechsel auf 7.3. Zeitgleich schließt Linus Torvalds mit 7.4-rc1 das bislang größte Merge Window ab und sieht KI-getriebene Arbeit dort besser aufgehoben.
Die Kernel-Serie Linux 7.2 hat ihr Supportende erreicht. Greg Kroah-Hartman hat am 1. November 2026 Linux 7.2.15 als letztes Release des Zweigs 7.2.y veröffentlicht und rät, auf 7.3.y zu wechseln; aktuell ist dort 7.3.1 vom 30. Oktober 2026. Am selben Tag hat Linus Torvalds Linux 7.4-rc1 freigegeben und damit ein Merge Window mit Rekordumfang abgeschlossen.
Relevant ist das Supportende vor allem für Systeme mit Mainline-nahen Kerneln, etwa Rolling-Release-Distributionen oder eigene Kernel-Builds. Server mit Distributionen, die auf Long-Term-Support-Kernel setzen, sind nicht direkt betroffen. Akuter Handlungsdruck besteht nicht, der Wechsel auf 7.3 gehört aber in das nächste reguläre Wartungsfenster.
Was ist passiert?
Laut LWN enthält 7.2.15 nur eine Handvoll Änderungen und ist ausdrücklich das letzte 7.2.y-Release. Kroah-Hartman räumt ein, dass der Zweig früher als üblich ausläuft. Angesichts des aktuellen Release-Zyklus und der vielen anstehenden Patches für die Stable-Reihe wolle das Team sich auf 7.3.y konzentrieren, da andernfalls acht Zweige gleichzeitig gepflegt werden müssten. Auf kernel.org ist 7.2.15 entsprechend als End-of-Life markiert.
Parallel ist das Merge Window für Linux 7.4 geschlossen. Torvalds nennt es selbst ein großes Merge Window. Laut LWN kamen 18.591 Non-Merge-Changesets hinzu, ein Rekord, der nahezu dem Patch-Volumen des gesamten 7.3-Zyklus entspricht, der selbst schon ein Rekordzyklus war. Bisher haben 2.678 Entwickler zu 7.4 beigetragen, 625 davon zum ersten Mal.
Als Grund nennt Torvalds die Flut an KI-getriebener Arbeit. Er sei deutlich zufriedener, wenn diese Arbeit im Merge Window lande statt vor allem als zusätzliche Fixes in der Stabilisierungsphase der Release Candidates. Das hält er für ein viel gesünderes Modell. Zugleich verweist er darauf, dass viele 7.4 als nächsten LTS-Kernel erwarten, was Releases ebenfalls größer mache. Ein Drittel des Diffs bestehe zudem aus AMD-GPU-Registerdefinitionen.
Für wen ist das relevant?
Den Zweig 7.2 nutzen vor allem Rolling-Release-Distributionen und Admins mit selbst gebauten Mainline-Kerneln. Arch Linux etwa lieferte sein Installationsmedium vom November 2026 noch mit Kernel 7.2.11 aus. Solche Systeme erhalten für 7.2 künftig keine Stable-Fixes mehr.
Nicht betroffen sind Distributionen, die auf einen der Long-Term-Zweige setzen. Laut kernel.org werden derzeit 6.18.60, 6.12.115, 6.6.161, 6.1.191, 5.15.224 und 5.10.273 gepflegt, alle mit Stand vom 30. Oktober 2026. Enterprise-Distributionen mit eigener Kernelpflege folgen ohnehin ihrem eigenen Supportmodell.
Wie dringend ist das?
Ein Supportende ist kein akuter Sicherheitsvorfall. Es bedeutet aber, dass künftige Lücken in 7.2 nicht mehr über den Stable-Zweig geschlossen werden. Wer 7.2 weiter betreibt, sammelt mit jeder neuen Kernel-Schwachstelle offene Risiken an. Linux 7.4-rc1 ist dagegen eine Testversion und gehört nicht auf Produktivsysteme. Laut Phoronix bringt 7.4 unter anderem Vorbereitungen für AMD Zen 6, HDMI 2.1 als Standard im AMDGPU-Treiber, Unterstützung für Intel IPU8 und eine erste Basis für Apple M4.
Was sollten Admins jetzt tun?
- Die laufende Kernelversion mit
uname -rprüfen und Systeme mit 7.2.x inventarisieren. - Bei Rolling-Release-Distributionen den Wechsel auf 7.3.y über die regulären Paketupdates einplanen und nach dem Neustart erneut prüfen.
- Bei eigenen Builds auf 7.3.y oder einen LTS-Zweig wie 6.18 umstellen.
- Auf Servern, wo Stabilität vor neuen Funktionen geht, einen LTS-Kernel bevorzugen.
- Linux 7.4-rc1 nur auf Testsystemen einsetzen.
Einordnung für Unternehmen
Für die meisten Unternehmensserver ändert sich wenig, da sie mit LTS- oder Distributionskerneln laufen. Das vorgezogene Supportende zeigt aber, wie stark der Patch-Strom derzeit wächst. Wer Mainline-Kernel einsetzt, sollte mit kürzeren Supportzeiträumen rechnen und Kernelupdates fest in den Wartungsplan aufnehmen. Für planbaren Betrieb bleiben LTS-Kernel die naheliegende Wahl.
