Kernel-Versionsupgrade planen: LTS, Rollback und Kompatibilität

1. Warum ein Kernel-Versionsupgrade sorgfältige Planung braucht

Ein Kernel-Versionsupgrade betrifft die Schicht, auf der jeder Prozess, jeder Treiber und jedes Dateisystem aufsetzt. Anders als ein Paket-Update im Userspace kann ein fehlgeschlagenes Kernel-Upgrade dazu führen, dass ein Server nach dem nächsten Neustart gar nicht mehr bootet, weil ein Treiber fehlt oder ein Kernel-Modul nicht mehr kompatibel ist. Wer produktive Systeme betreibt, plant ein Kernel-Versionsupgrade deshalb nie spontan, sondern als eigenen kleinen Change-Prozess mit Bestandsaufnahme, Kompatibilitätsprüfung und Rollback-Plan.

Die gute Nachricht: Linux-Distributionen bieten inzwischen robuste Mechanismen, um ein Kernel-Versionsupgrade risikoarm durchzuführen. GRUB behält alte Kernel-Einträge im Boot-Menü, Paketmanager installieren neue Kernel parallel zum alten, und DKMS baut Drittanbieter-Module bei jedem neuen Kernel automatisch neu. Trotzdem bleibt die Verantwortung beim Administrator, diese Mechanismen aktiv zu nutzen, statt sich blind auf ein automatisches Update zu verlassen. Die folgenden Abschnitte zeigen den kompletten Ablauf von der Versionswahl bis zum überprüften Rollback.

2. LTS gegen Mainline: die richtige Kernel-Linie wählen

Bevor ein Kernel-Versionsupgrade ansteht, muss klar sein, welcher Kernel-Zweig überhaupt sinnvoll ist. Der Long Term Support Kernel (LTS) erhält für mehrere Jahre Sicherheits- und Bugfixes, ohne dass sich das Feature-Set grundlegend ändert. Für Produktivserver mit Magento, Datenbanken oder anderen kritischen Diensten ist ein LTS-Kernel fast immer die richtige Wahl, weil Stabilität wichtiger ist als der neueste Treiber für brandneue Hardware. Mainline-Kernel bringen aktuellere Treiber und Performance-Verbesserungen, aber auch ein höheres Risiko für Regressionen, die auf einem produktiven Server niemand sehen möchte.

Distributionen bilden diese Wahl unterschiedlich ab. Ubuntu LTS pflegt einen Haupt-Kernel für die Laufzeit des Release, bietet aber über das Hardware Enablement Stack (HWE) auch neuere Kernel-Versionen für ältere LTS-Releases an. Debian bleibt bei einer sehr konservativen Kernel-Version pro Stable-Release. RHEL und Rocky Linux pflegen einen eigenen, stark gepatchten Kernel mit langer Update-Garantie. Wer ein Kernel-Versionsupgrade plant, sollte zuerst festlegen, ob innerhalb der aktuellen Distributions-Linie geblieben wird oder ob ein Sprung auf eine neuere HWE- beziehungsweise Mainline-Version nötig ist, etwa wegen neuer NVMe-Controller oder Netzwerkkarten.

3. Den aktuellen Kernel-Zustand dokumentieren

Jedes Kernel-Versionsupgrade beginnt mit einer Bestandsaufnahme des laufenden Systems. Ohne dokumentierten Ausgangszustand lässt sich später nicht beurteilen, ob ein Problem tatsächlich vom neuen Kernel stammt oder schon vorher existierte. Dazu gehören die exakte Kernel-Version, die installierten Kernel-Pakete, geladene Module und die aktuell aktiven Kernel-Parameter aus der Bootzeile.

# Document current kernel state before any upgrade
uname -a
uname -r                          # exact running kernel version

# Installed kernel packages (Debian/Ubuntu)
dpkg -l | grep -E '^ii\s+linux-(image|headers)'

# Installed kernel packages (RHEL/Rocky family)
rpm -qa | grep -E '^kernel(-core|-devel)?-'

# Currently loaded modules as a baseline snapshot
lsmod > /root/kernel-upgrade-baseline-lsmod.txt

# Kernel command line as passed by the bootloader
cat /proc/cmdline

# Save everything into one dated report for the change record
{
  echo "=== Kernel Upgrade Baseline $(date -Iseconds) ==="
  uname -a
  cat /proc/cmdline
} > /root/kernel-upgrade-baseline.txt

Dieser Schritt wirkt banal, ist aber der wichtigste Sicherheitsnetz-Baustein für ein Kernel-Versionsupgrade. Wenn nach dem Upgrade ein Netzwerkinterface einen anderen Namen trägt oder ein Storage-Treiber fehlt, zeigt der Vergleich mit der Baseline sofort, was sich geändert hat. Ohne diese Referenz beginnt die Fehlersuche bei null, und genau das kostet in einer Nacht-Wartung die meiste Zeit.

4. Kompatibilitätsprüfung: Treiber, Module und DKMS

Der kritischste Teil eines Kernel-Versionsupgrades betrifft Kernel-Module, die nicht Teil des Kernel-Baums sind, sondern über Dynamic Kernel Module Support (DKMS) nachgebaut werden. Typische Beispiele sind proprietäre Grafiktreiber, manche RAID-Controller-Treiber oder VirtualBox-Kernel-Module. DKMS merkt sich, für welche Kernel-Versionen ein Modul bereits gebaut wurde, und versucht bei einem neuen Kernel automatisch einen Neubau. Schlägt dieser Build fehl, etwa weil sich eine interne Kernel-API geändert hat, bootet der neue Kernel zwar, aber das betroffene Gerät funktioniert nicht mehr.

Vor jedem Kernel-Versionsupgrade lohnt sich deshalb ein Blick auf den DKMS-Status und auf alle manuell installierten Kernel-Module, die nicht über den Paketmanager gepflegt werden. Auch Treiber, die im Kernel-Log Warnungen bezüglich veralteter Symbole erzeugen, sind ein Warnsignal. Bei Cloud- und virtualisierten Servern ist zusätzlich zu prüfen, ob die Virtio-Treiber und der Cloud-Init-Mechanismus mit der neuen Kernel-Version kompatibel bleiben, da sonst Netzwerk oder Datenträger nach dem Reboot nicht erkannt werden.

# List all DKMS-managed modules and their build status per kernel
dkms status

# Check which kernel versions a specific module was built for
dkms status -m nvidia

# Inspect a module's metadata before trusting it with a new kernel
modinfo -F vermagic virtualbox
# Output looks like: 6.1.0-18-amd64 SMP mod_unload modversions

# Search the kernel log for module or symbol warnings after boot
dmesg | grep -iE 'unknown symbol|disagrees about version|tainted'

# List modules that are not shipped by the distribution kernel package
comm -23 <(lsmod | awk 'NR>1{print $1}' | sort) \
         <(find /lib/modules/$(uname -r)/kernel -name '*.ko*' \
             -printf '%f\n' | sed 's/\.ko.*//' | sort)

5. Der Upgrade-Vorgang unter Debian/Ubuntu und RHEL-Familie

Der eigentliche Installationsschritt eines Kernel-Versionsupgrades ist auf modernen Distributionen unspektakulär, weil Paketmanager neue Kernel-Pakete parallel zu bestehenden installieren, statt sie zu überschreiben. Auf Debian und Ubuntu installiert apt install linux-image-generic beziehungsweise ein konkretes HWE-Metapaket den neuen Kernel, ohne den alten sofort zu entfernen. Auf RHEL, Rocky Linux und AlmaLinux übernimmt dnf mit der Konfiguration installonly_limit dieselbe Aufgabe und hält standardmäßig mehrere Kernel-Versionen parallel vor.

Wichtig ist, das Kernel-Versionsupgrade in einem Wartungsfenster durchzuführen, weil der neue Kernel erst nach einem Neustart aktiv wird. Ein reines apt upgrade ohne Reboot lässt den Server weiter mit dem alten Kernel laufen, auch wenn dpkg bereits einen neuen Kernel als installiert meldet. Live-Patching-Lösungen wie Ubuntu Livepatch oder kpatch für RHEL schließen diese Lücke für kritische Sicherheitsfixes, ersetzen aber kein vollständiges Versionsupgrade auf Dauer.

# Debian/Ubuntu: install the newest kernel metapackage
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04

# Verify which kernel packages are now on disk (old one is kept)
dpkg -l | grep linux-image

# RHEL/Rocky family: install newest kernel, keep old ones
sudo dnf install kernel kernel-devel kernel-headers
grep installonly_limit /etc/dnf/dnf.conf   # e.g. installonly_limit=3

# Confirm the new kernel is registered in the bootloader
sudo update-grub                 # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL family

# Reboot into a maintenance window, not ad-hoc
sudo systemctl reboot

6. GRUB und Rollback: den alten Kernel als Fallback behalten

Der wichtigste Sicherheitsmechanismus bei jedem Kernel-Versionsupgrade ist, den zuvor laufenden Kernel nicht sofort zu entfernen. GRUB listet standardmäßig alle installierten Kernel-Versionen unter "Advanced options" im Boot-Menü auf. Bootet der Server nach dem Upgrade nicht sauber oder fehlt ein kritischer Treiber, lässt sich der alte Kernel manuell im Boot-Menü auswählen oder per grub-reboot für genau einen Start als Default setzen, ohne die dauerhafte GRUB-Konfiguration zu ändern.

Für unbeaufsichtigte Server ohne physischen Zugriff auf die Konsole ist diese Rollback-Fähigkeit besonders wichtig, weil ein manuelles Eingreifen im Boot-Menü über Remote-Konsolen wie IPMI oder eine Cloud-Konsole zwar möglich, aber langsam ist. Ein automatisierter Boot-Test, der nach dem Kernel-Versionsupgrade gezielt prüft, ob kritische Dienste starten, und im Fehlerfall automatisch auf den vorherigen Kernel zurückfällt, reduziert die Ausfallzeit erheblich.

# List all kernel entries known to GRUB, with their menu index
awk -F\' '/menuentry / {print $2}' /boot/grub/grub.cfg

# Boot into the previous kernel exactly once, without changing defaults
sudo grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux 6.1.0-17"
sudo systemctl reboot

# After confirming stability, keep the new kernel as default,
# or roll back permanently by removing the broken package
sudo apt remove --purge linux-image-6.5.0-99-generic
sudo update-grub

# GRUB_DEFAULT=saved lets grub-reboot control the next boot only
grep -E 'GRUB_DEFAULT|GRUB_SAVEDEFAULT' /etc/default/grub

7. Kernel-Module und Drittanbieter-Treiber nach dem Upgrade

Direkt nach dem ersten Boot mit dem neuen Kernel ist eine gezielte Prüfung der Kernel-Module Pflicht, nicht optional. Ein Kernel-Versionsupgrade gilt erst dann als abgeschlossen, wenn alle vorher geladenen Module wieder aktiv sind und keine Fehler im Kernel-Log auftauchen. Der Vergleich mit der zuvor gesicherten Baseline aus Abschnitt drei zeigt sofort, ob ein Modul fehlt, das vor dem Upgrade noch geladen war.

Besonders bei Storage- und Netzwerktreibern kann ein fehlendes Modul dazu führen, dass ein RAID-Array nicht erkannt wird oder eine Netzwerkkarte offline bleibt, ohne dass der Server dabei den Bootvorgang selbst verweigert. Deshalb gehört zur Nachkontrolle eines Kernel-Versionsupgrades immer auch ein Blick auf ip link, lsblk und die Ausgabe von systemctl --failed, um Dienste zu finden, die wegen fehlender Hardware-Erkennung nicht starten konnten.

8. Teststrategie vor dem Produktivrollout

Ein Kernel-Versionsupgrade sollte nie zuerst auf dem Produktivsystem passieren. Ein Staging-Server mit identischer Hardware-Konfiguration, oder zumindest eine virtuelle Maschine mit denselben Kernel-Modulen, deckt die meisten Kompatibilitätsprobleme auf, bevor sie den Live-Betrieb betreffen. Der Testplan sollte neben dem reinen Boot-Erfolg auch funktionale Checks für die kritischen Dienste enthalten, etwa ob PHP-FPM, die Datenbank und der Webserver nach dem Reboot tatsächlich wieder erreichbar sind.

Automatisierte Health-Checks direkt nach dem Neustart machen ein Kernel-Versionsupgrade überprüfbar, statt sich auf ein gefühltes "läuft doch" zu verlassen. Ein einfaches Skript, das kurz nach dem Boot die wichtigsten Endpunkte, Mount-Punkte und Netzwerkinterfaces prüft, liefert innerhalb von Sekunden ein klares Go oder No-Go für das Upgrade.

#!/usr/bin/env bash
# post-kernel-upgrade-check.sh — run right after the first reboot
set -euo pipefail

echo "== Kernel version =="
uname -r

echo "== Failed systemd units =="
systemctl --failed --no-legend || true

echo "== Network interfaces up =="
ip -brief link show

echo "== Mounted filesystems =="
mount | grep -E ' / | /var | /home '

echo "== Critical services responding =="
for svc in php8.4-fpm nginx mariadb; do
  systemctl is-active --quiet "$svc" && echo "OK: $svc" || echo "FAIL: $svc"
done

echo "== Kernel log errors since boot =="
dmesg --level=err,crit,alert,emerg | tail -20

9. Kernel-Upgrade-Strategien im Vergleich

Es gibt mehrere valide Ansätze für ein Kernel-Versionsupgrade, die sich in Risiko, Aufwand und Aktualität deutlich unterscheiden. Die Wahl hängt davon ab, wie kritisch der Server ist und wie viel Kontrolle über Wartungsfenster besteht.

In der Praxis kombinieren die meisten Betreiber mehrere Zeilen dieser Tabelle: ein LTS-Kernel als Basis, Live-Patching für dringende Sicherheitsfixes zwischen den geplanten Wartungsfenstern, und ein vollständiges Kernel-Versionsupgrade nur zwei- bis viermal im Jahr mit vollständigem Testlauf. Diese Kombination hält das Risiko klein, ohne auf wichtige Sicherheitsupdates monatelang zu warten.

10. Zusammenfassung

Ein sicheres Kernel-Versionsupgrade ist kein einzelner Befehl, sondern ein kleiner Prozess aus fünf Schritten: Bestandsaufnahme des laufenden Systems, Kompatibilitätsprüfung von DKMS-Modulen und Treibern, Installation des neuen Kernels parallel zum alten, kontrollierter Neustart mit GRUB-Rollback-Option und abschließende Verifikation aller kritischen Dienste. Wer diese Reihenfolge einhält, reduziert das Risiko eines nicht bootenden oder funktional eingeschränkten Servers erheblich.

Die Wahl zwischen LTS-, HWE- und Mainline-Kernel entscheidet zusätzlich darüber, wie oft ein Kernel-Versionsupgrade überhaupt nötig wird und wie hoch das jeweilige Risiko ausfällt. Für die meisten Produktivserver mit PHP- und Datenbank-Workloads ist ein LTS-Kernel mit gelegentlichem Live-Patching für Sicherheitsfixes die robusteste Kombination, ergänzt durch ein sauber getestetes, vollständiges Upgrade wenige Male im Jahr.

11. FAQ: Kernel-Versionsupgrade planen