Ubuntu Server: GA- oder HWE-Kernel verwenden?

Setzt das Point-Release einen neuen Kernel auf meinem Ubuntu-Server ein?

Nein. Auf einem Ubuntu-Server wird die Auswahl zwischen dem HWE-Kernel und dem GA-Kernel durch ein installiertes Paket festgelegt. Ein Point-Release installiert dieses Paket nicht automatisch. Der Begriff „enablement“ wird in den Release Notes für zwei unterschiedliche Vorgänge verwendet. Daher entsteht die Verwechslung. Hardware Enablement (HWE) bezeichnet den neueren Kernel-Zweig. Upgrade Enablement bezeichnet den separaten Zeitpunkt, ab dem der Upgrade-Pfad von einer LTS-Version zur nächsten geöffnet wird. Ein bereits laufender Server, der bereits den GA-Kernel verwendet, bleibt bei jedem Point-Release seiner LTS-Version beim GA-Kernel.

Welche Kernel-Tracks GA und HWE sind

GA (General Availability) ist der Kernel, den ein Ubuntu LTS am Veröffentlichungstag ausliefert. Dieser Upstream-Kernel bleibt während des regulären Supportzeitraums der Version unverändert. Sicherheits- und Fehlerkorrekturen werden zurückportiert. Deshalb ändert sich die letzte Zahl in uname -r alle paar Wochen. Die Upstream-Version am Anfang der Zeichenfolge ändert sich nicht.

HWE (Hardware Enablement) ist der andere Track. Canonical portiert den Kernel jeder späteren Interim-Version in das LTS zurück. Dieser Vorgang endet beim Kernel des nächsten LTS. Dadurch wechselt der Enablement-Kernel ungefähr alle sechs Monate auf eine neuere Upstream-Version, bis er die letzte dieser Versionen erreicht. Canonical bezeichnet dies als Rolling-Update-Modell. Der letzte Enablement-Kernel ist der GA-Kernel des nächsten LTS. Für den restlichen LTS-Zeitraum bleibt er auf dieser Upstream-Version und erhält Korrekturen auf dieselbe Weise wie GA. Desktop-Images installieren den Enablement-Kernel standardmäßig. Server- und Cloud-Images installieren standardmäßig GA. Der Enablement-Stack wird über ein optionales Paket aktiviert.

Der Unterschied ist kurz zusammengefasst: GA bietet eine Kernel-Version, die sich über Jahre nicht ändert. HWE bietet neuere Treiber und neuere Kernel-Funktionen. Solange der Track fortlaufend aktualisiert wird, erfordert HWE ungefähr alle sechs Monate eine Versionsaktualisierung und einen Reboot.

Welche Kernel-Schiene ist derzeit aktiv?

uname -r enthält nie das Wort hwe. Beide Schienen geben eine Version aus, die mit -generic endet. Der Name des laufenden Kernels allein beantwortet die Frage daher nicht. Das installierte Meta-Paket zeigt, welcher Schiene Ihre Updates folgen. Der Vergleich mit uname -r zeigt, welcher Kernel tatsächlich läuft.

uname -r
grep VERSION_ID /etc/os-release
apt-cache policy linux-generic linux-generic-hwe-24.04

Ersetzen Sie 24.04 durch die Nummer, die VERSION_ID auf Ihrem eigenen System ausgibt. apt-cache policy gibt für jedes von Ihnen angegebene Paket eine Zeile mit Installed: aus. Diese Zeile bedeutet, dass ein Paket installiert ist. Sie bedeutet nicht, dass der zugehörige Kernel läuft. Installed: (none) für das Paket -hwe- und eine Version für linux-generic bedeuten, dass Ihre Updates der GA-Schiene folgen, sofern kein anderes Enablement-Meta-Paket wie linux-virtual-hwe-24.04 installiert ist. Die weiter unten aufgeführten Befehle prüfen das. Umgekehrt folgen Sie der Enablement-Schiene. Wenn beide Pakete eine Version tragen, befinden sich beide Kernel auf dem Datenträger. Bei Ubuntus standardmäßigem GRUB_DEFAULT=0 startet GRUB den neuesten Kernel. Das ist der Enablement-Kernel. Wenn jedoch jemand GRUB_DEFAULT auf einen bestimmten Eintrag oder auf saved gesetzt hat, kann der GA-Kernel trotzdem gestartet werden. Nur uname -r zeigt, welcher Kernel tatsächlich läuft.

Einige Provider-Images installieren linux-image-virtual statt linux-generic. Dabei handelt es sich um einen kleineren Modulsatz für virtuelle Maschinen. Er hat eine eigene Enablement-Variante. Raten Sie den Namen nicht. Fragen Sie das System ab, welche Kernel-Pakete ausgewählt wurden. Fragen Sie anschließend das Paketarchiv ab, welche Enablement-Pakete für Ihr Release vorhanden sind.

apt-mark showmanual | grep '^linux-'
apt-cache search linux-image | grep hwe
apt-cache depends linux-image-generic-hwe-24.04
dpkg -l 'linux-image-*' | grep '^ii'
ls /boot/vmlinuz-*

apt-cache depends zeigt, auf welches Kernel-Image das Enablement-Meta-Paket derzeit verweist. Wenn die Version dieses Images mit uname -r übereinstimmt, läuft der Enablement-Kernel. ls /boot/vmlinuz-* zeigt, welche Kernel tatsächlich installiert und startfähig sind. Das sind oft mehr, als Sie erwarten.

Was jeder Point Release für die einzelnen Tracks ändert

Im GA-Track ändert ein Point Release nichts an einem laufenden Server. Ein Point Release ist ein aktualisiertes Installationsabbild plus die Updates, die apt bereits bereitstellt. Es legt fest, was eine neu installierte Maschine erhält, nicht, welche Pakete auf einer bestehenden Maschine ausgeführt werden. Was ein Ubuntu Point Release tatsächlich ändert behandelt die übrigen Aspekte.

Im Enablement-Track wird das Meta-Paket in einem regulären Kernel-Update-Zyklus aktualisiert, der vor dem Point Release stattfindet, nicht am Veröffentlichungstag. Canonical aktualisiert den Enablement-Kernel vor jedem LTS Point Release mit Ausnahme des ersten. Für 24.04.3, das am 2025-08-07 veröffentlicht wurde, war der Wechsel von 6.11 auf 6.14 für den Kernel-SRU-Zyklus vom 2025.06.16 geplant. linux-image-generic-hwe-24.04 ändert seine Abhängigkeit auf ein neueres Kernel-Image, und Ihr nächster regulärer Update-Lauf installiert dieses Image. Die apt-Handbuchseite erklärt ausdrücklich, warum ein einfacher Update-Lauf ausreicht: „Neue Pakete werden installiert, wenn dies zur Erfüllung von Abhängigkeiten erforderlich ist, aber bestehende Pakete werden niemals entfernt.“ Daher installiert apt upgrade den neuen Kernel. Er wird erst beim nächsten Reboot zum laufenden Kernel.

Auf 24.04 ist der Rollvorgang bereits abgeschlossen. Am 2026-10-12 hängt linux-generic-hwe-24.04 auf amd64 von einem Kernel-Image der Version 7.0 ab, dem GA-Kernel von 26.04. Ab diesem Zeitpunkt erhält dieser Track Fehlerkorrekturen, aber keine weiteren Versionssprünge der Upstream-Version.

Ob ein unattended-Job dies für Sie erledigt, hängt von Ihrer eigenen Konfiguration ab. Lesen Sie /etc/apt/apt.conf.d/50unattended-upgrades und sehen Sie sich den Block Allowed-Origins an. Die ausgelieferte Standardkonfiguration aktiviert die Release- und Security-Pockets und lässt die Updates-Pocket auskommentiert. Dadurch werden Enablement-Schritte nicht verhindert, weil Ubuntu Kernel-Meta-Paket-Updates, einschließlich der Enablement-Wechsel, ebenfalls in der Security-Pocket veröffentlicht. Am 2026-10-12 ist die Version 7.0.0-38.38~24.04.4 von linux-generic-hwe-24.04 in noble-security veröffentlicht. Bei einer Standardkonfiguration mit installiertem Enablement-Meta-Paket installiert unattended-upgrades daher jeden neuen Enablement-Kernel automatisch. Er wird trotzdem erst nach einem Reboot ausgeführt. Prüfen Sie die Datei, statt eine der beiden Möglichkeiten anzunehmen.

Die Support-Zeiträume ergeben sich aus demselben Mechanismus. Der GA-Kernel wird während des Standardzeitraums des LTS-Releases ohne Ihr Zutun unterstützt. Jeder Enablement-Kernel wird unterstützt, bis der nächste Enablement-Kernel ihn ersetzt. Der letzte Kernel ist die Ausnahme: Er wird für den verbleibenden Zeitraum des LTS unterstützt. Bis zu diesem letzten Schritt ist HWE nur dann ein unterstützter Track, wenn Sie jeden Schritt mitgehen. Wenn Sie auf diesem Track zwei Schritte zurückliegen, verwenden Sie einen Kernel, der keine Fehlerkorrekturen mehr erhält, und apt weist nicht darauf hin.

Übernehmen Sie keine exakten Daten aus Blogbeiträgen, auch nicht aus diesem. Canonical veröffentlicht ein Enddatum für jede Kernel-Version auf der Ubuntu-Kernel-Lifecycle-Seite sowie die Release- und Supportdaten auf der Ubuntu-Release-Cycle-Seite. Vergleichen Sie diese Seiten mit den Ausgaben von uname -r und grep VERSION_ID /etc/os-release auf Ihrem Server. Nur diese beiden Fakten beschreiben den Zustand Ihrer Maschine.

Warum der Enablement-Kernel bei einem VPS selten hilft

HWE ist für Hardware gedacht. Ein Laptop oder ein physischer Server mit einer neueren NIC (Network Interface Card), einem neueren Speichercontroller oder einer neueren GPU als der LTS-Kernel funktioniert oft erst dann korrekt, wenn ein neuerer Kernel verfügbar ist. Der Enablement-Kernel behebt dieses Problem. Bei echter Hardware entscheidet er häufig darüber, ob das System funktioniert oder ausfällt.

Ein gemieteter VPS hat dieses Problem nicht, weil er diese Hardware nicht sieht. Ein Gastbetriebssystem sieht eine kleine und bewusst alte Auswahl virtueller Geräte. Prüfen Sie Ihre Geräte.

sudo apt install -y pciutils
lspci -nnk

lspci -nnk gibt jedes Gerät zusammen mit dem darunter gebundenen Kernel-Treiber aus. Auf den meisten VPS-Instanzen ist die Liste kurz: virtio_net für das Netzwerk und virtio_blk oder virtio_scsi für die Laufwerke. Diese Treiber sind seit vielen Jahren im Mainline-Kernel enthalten. Das virtuelle Gerät stellt absichtlich eine stabile Schnittstelle bereit, weil der Gast weiter funktionieren muss, wenn der Anbieter ihn auf andere physische Hardware verschiebt. Der Grund, aus dem viele den Enablement-Kernel installieren, besteht auf einem gemieteten Server daher meistens nicht.

Die Kosten bleiben jedoch bestehen. Jeder Enablement-Schritt bringt ein neues Kernel-Binary mit einem eigenen Reboot mit sich. Dieser kommt zusätzlich zu den Reboots hinzu, die Sie ohnehin für Security-Kernel durchführen. Bei einem einzelnen VPS ohne Failover-Ziel bedeutet ein Reboot Downtime, die Sie planen und überwachen müssen. Live-Kernel-Patching kann einige Security-Reboots vermeiden. Den Reboot für einen Versionssprung kann es jedoch nicht vermeiden, weil dabei ein anderer Kernel verwendet wird und nicht nur ein gepatchter Kernel.

Wann Sie zum Enablement-Kernel wechseln sollten

In vier Fällen lautet die Antwort tatsächlich ja.

• Der Hypervisor stellt ein Gerät bereit, das Ihr Kernel nicht ansteuern kann. Das Symptom ist eindeutig: Eine Schnittstelle fehlt in ip -brief link oder ein Datenträger fehlt in lsblk, obwohl das Gerät in lspci -nnk vorhanden ist und darunter keine Kernel driver in use:-Zeile angezeigt wird.
• Die von Ihnen eingesetzte Software nennt eine höhere minimale Kernel-Version als Ihre installierte Version. Container-Runtimes, Datenbanken und eBPF-Tools tun dies. Vergleichen Sie die vom Hersteller angegebene Mindestversion mit uname -r und richten Sie sich nach den Angaben des Herstellers.
• Sie stoßen auf einen Fehler, der upstream nach der GA-Version behoben und nicht zurückportiert wurde. Bestätigen Sie vor dem Wechsel, dass der Fix tatsächlich in der Enablement-Version enthalten ist. Andernfalls führen Sie die Neustarts durch und behalten den Fehler.
• Sie benötigen eine Dateisystem- oder Netzwerkfunktion, die nach der GA-Version hinzugefügt wurde, und diese Funktion ist der Grund, aus dem der Server existiert.

Wenn keiner dieser Punkte auf Ihren Server zutrifft, ist GA die richtige Wahl. Den Server unverändert zu lassen, ist dann eine bewusste Entscheidung und keine Nachlässigkeit.

So wechseln Sie die Version, und was Sie nach dem Reboot prüfen sollten

Prüfen Sie zuerst den freien Speicherplatz. Wenn /boot eine kleine separate Partition ist, kann eine zweite Kernel-Zeile sie füllen. apt bleibt dann mit No space left on device in einem halb konfigurierten Zustand stehen.

df -h /boot
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
ls /boot/vmlinuz-*
sudo reboot

Wenn der Server wieder erreichbar ist, prüfen Sie, was sich geändert hat und was unverändert geblieben ist.

uname -r
ip -brief link
lsblk
journalctl -k -b 0 -p err --no-pager

uname -r sollte jetzt dem benannten Image apt-cache depends linux-image-generic-hwe-24.04 entsprechen. Bei 24.04 bedeutet das derzeit eine höhere Upstream-Version als zuvor: 7.0 anstelle von 6.8. Bei einem Release, dessen Enablement-Track noch nicht weitergeschaltet wurde, kann die Upstream-Version gleich bleiben: Am 2026-10-12 hängen sowohl linux-generic als auch linux-generic-hwe-26.04 auf 26.04 von 7.0.0-38.38 ab. Die Netzwerk- und Datenträgerauflistungen sollten genau wie zuvor aussehen, weil weiterhin dieselben virtuellen Geräte vorhanden sind. Ein fehlendes Interface ist hier der eine relevante Fehler, weil der Server dann normalerweise nur noch über die Konsole des Providers erreichbar ist. journalctl -k -b 0 -p err gibt die Kernelmeldungen dieses Boots ab der Priorität error und höher aus (err, crit, alert und emerg). Auf einem gesunden VPS ist die Ausgabe leer oder nahezu leer. Den Kernel-Log auf einem VPS lesen erklärt die Bedeutung der zahlreichen Meldungen. Löschen Sie den alten Kernel nicht am selben Tag. Er ist Ihr Rückweg.

So kehren Sie zurück, wenn sich der neue Kernel fehlerhaft verhält

Der alte Kernel ist weiterhin installiert und im GRUB-Menü verfügbar. Öffnen Sie die Konsole Ihres Providers, starten Sie den Server neu und wählen Sie unter „Advanced options for Ubuntu“ den vorherigen Kernel aus. Dadurch stellen Sie einmalig fest, dass der alte Kernel weiterhin startet. Die Auswahl für künftige Neustarts dauerhaft festzulegen, ist eine separate Aufgabe. Sie wird unter Festlegen, mit welchem Kernel Ihr VPS startet beschrieben. Wenn der Server nicht mehr zurückkommt und die Konsole stattdessen eine GRUB-Eingabeaufforderung oder einen Kernel Panic anzeigt, beschreibt Ein VPS, der nach einem Kernel-Update nicht startet den Wiederherstellungsweg.

Sobald Sie mit einem funktionierenden Kernel gestartet sind, stellen Sie die Pakete zurück.

sudo apt install linux-generic
sudo apt remove linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04
sudo reboot

Durch das Entfernen der Meta-Pakete wird verhindert, dass beim nächsten Enablement-Schritt die nächste Kernel-Version installiert wird. Das bereits installierte Kernel-Image wird dadurch nicht entfernt. Auf einem laufenden System ändert sich daher zunächst nichts. Prüfen Sie nach dem Neustart, ob uname -r wieder die GA-Version anzeigt. sudo apt autoremove --purge entfernt einige alte Images, aber nicht unbedingt das Image, das Sie gerade verlassen haben. APT behält immer den laufenden Kernel und den neuesten installierten Kernel. Das Enablement-Image ist normalerweise das neueste. Sobald uname -r bestätigt, dass dieses Image nicht ausgeführt wird, entfernen Sie die Pakete linux-image-, linux-modules- und linux-modules-extra- dieser Version anhand ihres Namens. Verwenden Sie dabei die Version, die dpkg -l 'linux-image-*' anzeigt. Alte Kernel aus /boot entfernen beschreibt den schwierigeren Fall, in dem /boot vollgelaufen ist, bevor Sie diesen Schritt ausführen konnten.

Noch ein wichtiger Punkt: Beim nächsten LTS stellt sich die Track-Frage von selbst. Der Wechsel zum nächsten LTS bringt dessen GA-Kernel. Dieser ist neuer als der GA-Kernel, den Sie heute verwenden, und setzt den Supportzeitraum neu in Gang. Wenn Sie wegen dieses Wechsels über Point Releases nachdenken, beschreibt Upgrade von 24.04 auf 26.04 das Vorgehen. Bis dahin beim GA-Kernel zu bleiben, ist für einen gemieteten Server eine normale und vertretbare Entscheidung.

FAQ

Ändert ein Point-Release den Kernel auf einem bereits installierten Server?

Nicht im GA-Zweig. Ein Point-Release ist primär ein aktualisiertes Installationsabbild; es bestimmt also, was eine neu aufgesetzte Maschine erhält. Ein bestehender Server behält den Zweig bei, den seine installierten Metapakete vorgeben. Wenn ein linux-...-hwe-...-Paket installiert ist, erreicht Sie der Aktivierungsschritt als reguläres Kernel-Update, das vor dem Point-Release veröffentlicht wird, zu dem es gehört, und Ihr nächstes apt upgrade installiert es. Der neue Kernel wird beim nächsten Neustart aktiv, nicht in dem Moment, in dem apt den Vorgang abschließt.

Wie stelle ich fest, ob ich den HWE- oder den GA-Kernel verwende?

Führen Sie apt-cache policy linux-generic linux-generic-hwe-24.04 aus und ersetzen Sie dabei die Versionsnummer durch 24.04. Das Paket mit einer tatsächlichen Version in der Installed:-Zeile entspricht dem Zweig, dem Ihre Updates folgen. Dies beweist nicht, welcher Kernel aktuell läuft; vergleichen Sie daher uname -r mit den Namen der apt-cache depends linux-image-generic-hwe-24.04-Abbilder. Versuchen Sie nicht, den Zweig allein aus uname -r abzulesen, da der Name des laufenden Kernels in beiden Zweigen auf -generic endet und niemals hwe enthält. Falls keines der Pakete installiert ist, führen Sie apt-mark showmanual | grep '^linux-' aus, da einige Anbieter-Abbilder stattdessen die linux-image-virtual-Familie verwenden.

Ist der HWE-Kernel weniger stabil als der GA-Kernel?

Jeder Aktivierungs-Kernel ist ein unterstützter Ubuntu-Kernel; es handelt sich also nicht um eine Frage der Qualität. Es ist eine Frage der Veränderung. Der GA-Kernel behält eine Upstream-Version über Jahre bei, sodass das Verhalten, gegen das Sie getestet haben, konstant bleibt. Der Aktivierungs-Kernel wechselt etwa alle sechs Monate auf eine neuere Upstream-Version, bis er den Kernel des nächsten LTS erreicht. Jeder dieser Schritte bietet die Möglichkeit, dass sich ein Treiber-Standard oder ein sysctl unter Ihrer Arbeitslast ändert. Auf einem Server, den Sie selten warten, sind weniger bewegliche Teile wertvoller als neuere Treiber.

Sollte mein VPS den HWE-Kernel verwenden?

Normalerweise nein. Eine virtuelle Maschine sieht einen festen Satz virtueller Geräte, meist virtio, deren Treiber seit Jahren im Kernel enthalten sind. Die Hardware-Unterstützung, für die der Aktivierungs-Zweig existiert, bringt einem VPS daher keinen Vorteil. Die zusätzlichen Neustarts sind dennoch real. Wechseln Sie aus einem konkreten Grund: wenn ein Gerät vom aktuellen Kernel nicht angesteuert werden kann oder die von Ihnen benötigte Software eine dokumentierte Mindestversion des Kernels voraussetzt.

Was passiert, wenn ich den Aktivierungs-Kernel installiere und nie neu starte?

Das neue Kernel-Abbild wird in /boot geschrieben und dem GRUB-Menü hinzugefügt, während Ihr Server weiterhin den alten Kernel ausführt. uname -r gibt an, was tatsächlich läuft, nicht die Paketliste. Ubuntu erstellt /var/run/reboot-required, wenn ein installiertes Paket einen Neustart erfordert, um wirksam zu werden; ls -l /var/run/reboot-required zeigt Ihnen also an, dass ein Neustart aussteht. Bis dieser Neustart erfolgt, belegen Sie Speicherplatz für den neuen Kernel, ohne von dessen Korrekturen zu profitieren.