Linux Kernel 7.1: Was ist neu für Server?

Was ist neu im Linux-Kernel 7.1

Der Linux-Kernel 7.1 wurde am 14. Juni 2026 veröffentlicht, neun Wochen nach 7.0. Für Betreiber eines VPS (Virtual Private Server) sind die relevanten Änderungen in vier Bereichen zu finden: Speicher und Dateisysteme, Netzwerk, Speicherverwaltung sowie Prozess- und Container-Steuerung. Der übrige Teil des Releases betrifft überwiegend Desktop- und Grafikfunktionen, die ein Headless-Server nie lädt.

Zuerst ist eine zweite Antwort erforderlich. 7.1 läuft auf Ihrem Server mit hoher Wahrscheinlichkeit nicht und wird dort lange Zeit nicht eingesetzt werden. kernel.org führt 7.1 nicht als Longterm-Release. Am 11. August 2026 sind 6.18, 6.12, 6.6, 6.1, 5.15 und 5.10 die Longterm-Zweige. Jede gängige Serverdistribution basiert auf einem dieser Zweige oder auf einem eigenen, von ihr gepflegten Zweig. Zwischen „neu im Kernel“ und „neu auf Ihrem Server“ liegen Jahre. Dieser Leitfaden behandelt deshalb beide Aspekte.

Welchen Kernel verwendet Ihre VPS derzeit?

uname -r
uname -srm
systemd-detect-virt

uname -r gibt das laufende Kernel-Release aus. Unter Ubuntu 24.04 sieht es wie 6.8.0-79-generic aus. Der Teil vor dem ersten Bindestrich bezeichnet den Upstream-Zweig. Alles danach ist die eigene Build-Nummer Ihrer Distribution und folgt dem Upstream nicht. Canonicals 6.8.0-79 enthält Tausende aus neueren Kerneln zurückportierte Fehlerbehebungen. Es entspricht daher nicht dem Code, den Linus im März 2024 als 6.8 markiert hat. Deshalb sagt die Aussage „mein Kernel ist alt“ weniger aus, als sie vermuten lässt. Die Funktionen sind alt. Die Sicherheitskorrekturen sind es normalerweise nicht.

systemd-detect-virt zeigt, ob Sie den Kernel überhaupt ändern können. Auf einer vollständigen virtuellen Maschine gibt es kvm aus. Dort starten Sie Ihr eigenes Kernel-Image, und ein Upgrade ist ein tatsächliches Upgrade. Bei Container-Virtualisierung gibt es lxc oder openvz aus. Dort wird der Kernel des Hosts gemeinsam verwendet. Bei einem Container-Tarif zeigt uname -r den Kernel des Providers an. Die Installation eines Kernel-Pakets ändert nichts, was Sie booten können. Keine Funktion dieses Releases steht Ihnen zur Verfügung, bevor der Provider den Host mit einem neueren Kernel neu startet. Führen Sie diese Prüfung durch, bevor Sie Kernel-Arbeiten planen.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

Das sind 6 Plattformen, und keine davon startet mit 7.1. Das neueste System ist Ubuntu 26.04 LTS (7.0). Es liegt 1 Upstream-Releases zurück. Das älteste weiterhin unterstützte System liegt 26 Releases zurück. Der standardmäßige GA-Kernel von Ubuntu 24.04 liegt 13 Releases zurück. Debian 13 und RHEL 10 liegen auf der 6.12-Langzeitlinie 9 Releases zurück. Das Zählen von Releases ist eine grobe Messgröße, weil dabei alle Rückportierungen der Distributionen unberücksichtigt bleiben. Es zeigt jedoch die Größenordnung der Abweichung. Wenn Sie abwägen, welches dieser Systeme Sie einsetzen möchten, ist der Vergleich zwischen LTS- und Interim-Release auf einem Server die eigentliche Entscheidung hinter diesen Zahlen.

Speicher und Dateisysteme in 7.1

7.1 kann T10 PI (Protection Information) jetzt innerhalb des Dateisystems erzeugen und prüfen, statt dies nur auf der Blockebene zu tun. Außerdem wird eine flexible T10-Ausrichtung unterstützt. T10 PI besteht aus zusätzlichen Bytes an jedem Block. Sie enthalten eine Prüfsumme und ein Tag, das angibt, zu welchem Block die Daten gehören. Dadurch werden fehlgeleitete oder unvollständige Schreibvorgänge erkannt, statt die Daten als gültig zurückzugeben. Für einen VPS-Mieter liegt die Einschränkung bei der Hardware. Das Gerät muss Integritätsmetadaten bereitstellen. Eine virtuelle Festplatte tut dies normalerweise nicht.

ls /sys/block/vda/integrity/

Auf den meisten VPS-Festplatten ergibt das No such file or directory, weil die Blockebene das Verzeichnis integrity nur anlegt, wenn das Gerät Integritätsunterstützung registriert. Dieser Fehler ist hier das erwartete Ergebnis und kein Defekt. Wenn Sie vor der weiteren Beschäftigung mit Speicherfunktionen wissen möchten, welche Art von Festplatte tatsächlich verwendet wird, sollten Sie zuerst prüfen, ob die VPS-Festplatte tatsächlich NVMe verwendet. Der Unterschied zwischen NVMe und einer SATA-SSD auf einem VPS erklärt, warum sich dadurch Ihre Werte ändern.

Btrfs enthält Korrekturen für die Copy-on-Write-Verstärkung bei Speicherdruck. Außerdem wurde eine Änderung vorgenommen, die das Leeren des ersten Extents in einem überwachten Bereich beschleunigt. Für den im Merge beschriebenen Beispiel-Workload wurden 10% mehr Durchsatz gemeldet. Der Shutdown-Vorgang ist nicht mehr als experimentell gekennzeichnet. XFS verbessert das Leeren von Zero-Ranges und die Suche über iomap. Außerdem wird ein Write Pointer zur Geometrie von Echtzeitgruppen hinzugefügt. Dies bildet die Grundlage für zonierte Geräte. NTFS wurde in dieser Version vollständig neu geschrieben. Es unterstützt jetzt vollständige Schreibvorgänge und eine Umstellung auf iomap. Das ist relevant, wenn Sie auf Ihrem Server jemals ein Disk-Image von einem Windows-Computer einbinden.

Weitere erwähnenswerte Änderungen im Speicherbereich: ublk, der Block-Treiber im Userspace, unterstützt jetzt Zero-Copy-I/O. io_uring unterstützt SCSI-Passthrough-Befehle. Die Unterstützung für selbstverschlüsselnde SED-OPAL-Laufwerke wurde um den Befehl STACK_RESET und den erweiterten Single-User-Modus ergänzt. Außerdem gibt es einen neuen fs-dax-Zeichentreiber für Geräte mit direktem Zugriff. Die VFS hat inode->i_ino von unsigned long auf u64 erweitert. Dadurch entfällt die Obergrenze für Inode-Nummern bei 32-Bit-Builds. Bei den Netzwerkdateisystemen kann der NFS-Server im Kernel seine File Handles jetzt über eine sign_fh-Mount-Option signieren. Der CIFS-Client unterstützt jetzt O_TMPFILE.

Netzwerk: Queue-Leasing und seine Möglichkeiten für Container

Die wichtigste Netzwerkänderung ist das Leasing von Hardware-Queues. Ein virtuelles Netdev kann jetzt eine Queue leasen, die an eine reale Queue eines physischen Netdevs gebunden ist, und als deren Proxy fungieren. Der Zweck ist der Einsatz in Containern. Bisher musste ein Container, der AF_XDP (Address Family Express Data Path, der Socket-Typ, der rohe Pakete ohne Kopieren durch den Netzwerk-Stack an den Userspace übergibt) verwenden wollte, annähernd das gesamte Gerät erhalten. Mit einer geleasten Queue erhält er eine Hardware-Queue, kann AF_XDP und Memory Provider mit nativer Geschwindigkeit ausführen, während der Host den übrigen Teil der NIC behält. Diese Funktion ergänzt die AF_XDP-Unterstützung im Zero-Copy-Pfad von io_uring.

Auf der herkömmlichen Seite akzeptieren Sockets in sockfs jetzt user.* Extended Attributes. Ein pfadbasierter AF_UNIX-Socket erbte die xattr-Unterstützung bereits vom darunterliegenden Dateisystem. Ein Socket, der ausschließlich in sockfs lebt, hatte dagegen keine solche Unterstützung. Jetzt kann ein Prozess einen Socket kennzeichnen, und ein eBPF-Programm kann anhand dieser Kennzeichnung filtern.

Zwei Funktionen wurden entfernt. UDP-Lite ist entfallen, weil es keine Anwender gefunden hat. IPv6 kann nicht mehr als ladbares Modul gebaut werden: Wenn Sie IPv6 verwenden möchten, wird es fest einkompiliert. Die zweite Änderung ist in den Kernel-Versionen gängiger Distributionen nicht sichtbar, weil diese IPv6 bereits fest einkompilieren.

Speicherverwaltung: Die Swap-Tabelle ist fertig

Die Überarbeitung von Swap erreicht ihre dritte Phase. In dieser Phase wird die statische Swap-Zuordnung entfernt. Die Anzahl der Swaps liegt jetzt direkt in der Swap-Tabelle. Die gemeldete Einsparung beträgt etwa 30 % der statischen Swap-Metadaten. Dabei handelt es sich um Speicher, den der Kernel proportional zur Größe des Swap-Geräts reserviert, unabhängig davon, ob tatsächlich etwas ausgelagert wird. Bei einer kleinen Swap-Datei ist das absolut gesehen wenig. Der Wert steigt mit der konfigurierten Swap-Größe.

MGLRU (multi-generational least recently used, der neuere Algorithmus zur Seitenrückgewinnung) kann das Young-Flag auf Seiten jetzt stapelweise statt einzeln prüfen. Die mit dieser Änderung veröffentlichte Zahl ist eine Verbesserung von mehr als 60 % auf einem Arm64-Server mit 32 Kernen. Die Stapelverarbeitung bringt vor allem dort Vorteile, wo die Kosten pro Seite am höchsten sind. Daher stammt dieser Wert von einer großen Arm-Maschine. Wenn Sie ein Arm-VPS statt eines x86-VPS betreiben, ist dies die Änderung in 7.1, die sich am ehesten in Ihren eigenen Messungen zeigt. Auf zwei oder vier Kernen ist der Effekt jedoch nicht so groß.

Ebenfalls enthalten sind der Wegfall von Transfers aus sterbenden Memory-Cgroups, CPU-schonendere Scans durch khugepaged und eine umfassende Überarbeitung des Maple Tree im Umgang mit großen Knoten. Nichts davon müssen Sie konfigurieren. Sie bemerken diese Änderungen als geringfügig niedrigere Systemzeit.

Scheduler: sched_ext-Sub-Scheduler und FRED standardmäßig aktiviert

sched_ext, die erweiterbare Scheduler-Klasse, mit der Sie einen CPU-Scheduler als BPF-Programm schreiben und zur Laufzeit laden können, wurde in 6.12 eingeführt. 7.1 ergänzt die grundlegende Struktur für Sub-Scheduler. Dadurch kann eine Control Group später unter einem eigenen Scheduler ausgeführt werden. Lesen Sie diesen Satz genau. Die Implementierung ist in 7.1 noch nicht abgeschlossen. Insbesondere der Enqueue-Pfad fehlt noch. Es handelt sich daher um Vorarbeiten für eine spätere Version und nicht um eine Funktion, die Sie heute aktivieren können.

Intel FRED (flexible return and event delivery) ist auf unterstützter Hardware jetzt standardmäßig aktiviert. FRED ersetzt den älteren x86-Pfad für die Event-Zustellung durch eine übersichtlichere Variante. Im Kernel ist FRED seit 6.9 vorhanden, dort jedoch hinter dem Boot-Argument fred=on. Die standardmäßige Aktivierung zeigt, dass die ausgelieferte Hardware ausreichend getestet wurde. Die bisher veröffentlichten Messungen liegen bei I/O-intensiven Workloads zwischen 4% und 7%. Sie stammen aus Tests von Phoronix auf Client-Silizium. Planen Sie diese Werte daher nicht für einen Server ein, bevor Sie Ihren eigenen Workload gemessen haben.

Die Proxy-Ausführung unterstützt jetzt die Migration des Donors, um den Besitzer eines entfernten Locks zu priorisieren. EEVDF wurde im Umgang mit negativem Lag korrigiert. Der Kern der hochauflösenden Timer wurde umfassend überarbeitet. Diese Änderungen verbessern die Latenzqualität, sind aber über keine Konfigurationsdatei sichtbar.

Neue Prozess- und Containersteuerung in clone3()

Drei Flags wurden zu clone3() hinzugefügt. Jedes davon schließt eine Lücke, die Supervisoren seit Jahren manuell umgehen. CLONE_AUTOREAP sorgt dafür, dass der Child-Prozess sich beim Beenden selbst aufräumt. Dadurch bleibt er nicht als Zombie zurück, wenn ein übergeordneter Prozess möglicherweise nie wait() aufruft. CLONE_NNP setzt no_new_privs bereits bei der Erstellung für den Child-Prozess. Dadurch entfällt das Zeitfenster zwischen clone und dem Setzen des Flags durch den Child-Prozess selbst. CLONE_PIDFD_AUTOKILL bindet die Lebensdauer des Child-Prozesses an den an den übergeordneten Prozess zurückgegebenen pidfd. Wird der pidfd geschlossen, wird der Child-Prozess beendet. Ein beendeter Supervisor kann dadurch keine verwaisten Prozesse weiterlaufen lassen.

Für Mount-Namespaces wurde dieselbe Funktionalität ergänzt. CLONE_EMPTY_MNTNS für clone3() und UNSHARE_EMPTY_MNTNS für unshare() erstellen ein Mount-Namespace ohne Inhalt. Stattdessen wird nicht wie üblich eine vollständige Kopie der Mounts des übergeordneten Prozesses angelegt, die eine Laufzeitumgebung anschließend aushängen muss. Mit FSMOUNT_NAMESPACE kann fsmount() ein Dateisystem direkt in einem neuen Namespace bereitstellen. Container-Laufzeitumgebungen setzen dies seit einem Jahrzehnt manuell zusammen. Mit einem einzigen Aufruf startet eine Laufzeitumgebung nun nicht mehr mit einem Namespace, der die Mounts des Hosts enthält.

Im Bereich der Virtualisierung unterstützt guest_memfd nun userfaultfd. Dadurch kann ein Hypervisor Page Faults des Gasts aus dem Userspace behandeln. Geschütztes KVM auf Arm unterstützt jetzt anonymen Speicher. Im Merge selbst wird diese Funktion als noch nicht produktionsbereit bezeichnet.

Wann erreicht Kernel 7.1 Ihren Server?

Fedora hat ihn bereits. Das Fedora-Update-Repository wechselte im Juli und August 2026 auf die Serie 7.1, weil Fedora den Kernel innerhalb eines Releases auf neue stabile Versionsreihen umstellt. Arch und openSUSE Tumbleweed haben ihn aus demselben Grund. Diese Systeme eignen sich zum Testen, nicht zum Ausführen Ihrer Dienste.

Alle anderen warten. Das ist beabsichtigt. Debian 13 wurde mit 6.12 veröffentlicht und bleibt während der gesamten Lebensdauer des Releases bei 6.12. Korrekturen werden zurückportiert. RHEL 10 wurde mit 6.12.0 veröffentlicht und verfährt ebenso. Ubuntu 26.04 LTS wurde im April 2026 mit 7.0 veröffentlicht. Ubuntu 24.04 LTS verfügt über einen Hardware Enablement Stack. Dieser übernimmt einen neueren Kernel aus späteren Ubuntu-Releases in das LTS-Release. Mit dem Point-Release 24.04.4 verwendet dieser Stack 6.17. Mit 24.04.5 soll er am 27. August 2026 auf 7.0 wechseln.

Hier liegt der häufigste Irrtum. Ein HWE-Stack wechselt auf den Kernel, den das neueste Interim-Release enthält. Dadurch kann eine Upstream-Version vollständig übersprungen werden. 7.0 ist in einem Ubuntu-LTS-Release enthalten. 7.1 wird möglicherweise nie die Basis eines LTS-Releases, weil das folgende Interim-Release bereits eine spätere Version enthält. Was aus 7.1 in Ihr LTS-Release gelangt, sind die Korrekturen. Sie werden in die von Ihnen verwendete Version zurückportiert. Die Funktionen bleiben größtenteils in der neueren Version.

Wenn Sie auf einem stabilen Server dennoch einen neueren Kernel benötigen, gibt es nur wenige unterstützte Wege.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Prüfen Sie nach dem Reboot, welchen Kernel Sie tatsächlich gestartet haben:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r sollte jetzt die neue Version anzeigen. dpkg -l zeigt alle noch installierten Kernel-Images. Wenn uname -r die alte Version anzeigt, während dpkg -l die neue auflistet, wurde das Paket installiert, aber der Standard des Bootloaders nicht geändert. Prüfen Sie die GRUB-Menüeinträge. Wenn /var/run/reboot-required vorhanden ist, hat ein Paket den Kernel aktualisiert und seitdem wurde kein Reboot durchgeführt. Das ist der häufigste Grund dafür, dass ein gepatchter Server weiterhin den verwundbaren Code ausführt.

Sollten Sie auf einem produktiven VPS Kernel 7.1 einsetzen?

Nein. Der Grund ist nicht bloße Vorsicht. Ein Distributionskernel ist Teil eines Supportvertrags. Canonical, Red Hat, SUSE und Debian übernehmen Sicherheitskorrekturen in ihre eingefrorene Kernel-Linie und testen sie mit dem Userspace, den sie zusammen mit dem Kernel ausliefern. Ein Mainline-Kernel aus einem Archiv eines Drittanbieters oder ein selbst erstellter Kernel bietet Ihnen zwar neue Funktionen, nimmt Ihnen diese Arbeit aber ab, weil niemand Sicherheitskorrekturen in Ihren Build zurückportiert. Sie werden zum Maintainer eines Kernels.

Die Ausnahmen sind real, aber selten: Hardware, die der ältere Kernel nicht unterstützt, oder eine von Ihnen für Ihre eigene Arbeitslast gemessene Leistungsänderung, deren Konsequenzen Sie bewusst übernehmen wollen. Auf einem VPS trifft der erste Fall fast nie zu, weil die für Sie sichtbare Hardware virtuell ist. In allen anderen Fällen sollten Sie den Distributionskernel aktuell halten und neu starten, wenn er dazu auffordert. Wenn ein Distributionsupgrade ohnehin auf Ihrer Liste steht, bringt Sie der Wechsel von Ubuntu 24.04 auf 26.04 in einem Schritt von 6.8 auf 7.0. Das ist ein größerer Sprung, als ihn ein einzelnes Kernelpaket bieten wird.

FAQ

Wie prüfe ich, welchen Linux-Kernel mein VPS ausführt?

Führen Sie uname -r aus. Der Befehl gibt beispielsweise 6.8.0-79-generic aus. Die Nummer vor dem ersten Bindestrich bezeichnet die Upstream-Linie, auf der Ihre Distribution aufbaut. Alles danach ist die eigene Build-Nummer der Distribution und enthält zurückportierte Fehlerbehebungen. Führen Sie anschließend systemd-detect-virt aus. Gibt der Befehl lxc oder openvz aus, verwenden Sie Container-Virtualisierung. Sie teilen sich den Kernel des Hosts und können ihn nicht ändern. Gibt er kvm aus, booten Sie Ihr eigenes Kernel-Image und sind selbst für Aktualisierungen zuständig.

Ist Linux 7.1 ein Longterm-Support-Kernel?

Nein. Am 11 August 2026 sind die auf kernel.org aufgeführten Longterm-Linien 6.18, 6.12, 6.6, 6.1, 5.15 und 5.10. 7.1 gehört nicht dazu. Es handelt sich um eine normale Stable-Version. Ihre Stable-Linie wird kurz nach dem Erscheinen der nächsten Mainline-Version eingestellt. Wenn Sie einen Kernel mit mehreren Jahren an Fehlerbehebungen und einer ebenso langen verbleibenden Pflegezeit benötigen, bietet Ihre Distribution dies bereits mit ihrem Kernel.

Wann werden Ubuntu oder Debian Kernel 7.1 ausliefern?

Wahrscheinlich nie als Standard. Debian 13 bleibt während der gesamten Lebensdauer dieser Version bei 6.12. RHEL 10 bleibt bei 6.12.0. Ubuntu 26.04 LTS wurde mit 7.0 veröffentlicht. Ein Ubuntu-Hardware-Enablement-Stack wechselt zu dem Kernel, den die neueste Interim-Version enthält. Dadurch kann eine Upstream-Linie vollständig übersprungen werden. Ubuntu 24.04 LTS soll seinen HWE-Kernel mit der Point-Release 24.04.5 am 27 August 2026 auf 7.0 umstellen. Die Fehlerbehebungen aus 7.1 erreichen Sie als Backports in einer älteren Linie. Die Funktionen in der Regel nicht.

Was ist in Linux 7.1 für einen virtuellen privaten Server tatsächlich relevant?

Vier Punkte. Durch das Leasen von Hardware-Warteschlangen kann ein Container eine echte NIC-Warteschlange für AF_XDP mit nativer Geschwindigkeit verwenden. Die dritte Phase der Überarbeitung des Swap-Systems entfernt die statische Swap-Zuordnung und reduziert die vom Kernel für das Swap-Gerät gehaltenen Metadaten laut Angabe um 30 %. MGLRU kann die Young-Flags von Seiten stapelweise prüfen. Der größte veröffentlichte Leistungsgewinn wurde auf einem Arm-Server mit vielen Kernen gemessen. Außerdem erhielt clone3() die Funktionen CLONE_AUTOREAP, CLONE_NNP und CLONE_PIDFD_AUTOKILL, die die Überwachung von Kindprozessen sicherer machen. Unterstützung für T10-Integritätsinformationen auf Dateisystemebene wurde ebenfalls hinzugefügt. Eine virtuelle Festplatte stellt die dafür erforderlichen Integritätsmetadaten jedoch nur selten bereit.

Wird ein Kernel-Upgrade meinen VPS beschädigen?

Die häufigsten Fehler treten beim Booten auf. Ein vollständiges /boot lässt update-initramfs während der Installation mit No space left on device fehlschlagen. Dadurch bleibt das Paket teilweise konfiguriert. Entfernen Sie alte Kernel mit sudo apt autoremove --purge und installieren Sie das Paket anschließend erneut. Out-of-Tree-Module, die gegen den alten Kernel gebaut wurden, lassen sich nicht mehr laden. Alles, was von DKMS verwaltet wird, muss daher neu gebaut werden. Ein fehlgeschlagener Neubau bleibt unbemerkt, bis das Modul zur Laufzeit fehlt. Wenn uname -r nach einem Reboot weiterhin die alte Version meldet, während dpkg -l das neue Image auflistet, ist die Installation nicht beschädigt. Der Standard des Bootloaders wurde nicht geändert.