Der Kernel von AlmaLinux bleibt während des gesamten Lebenszyklus auf derselben Hauptversion: 6.12 bei AlmaLinux 10 und 5.14 bei AlmaLinux 9. Dieser wird von Red Hat kontinuierlich aktualisiert, wobei ein Teil der Sicherheits- und Hardware-Unterstützungsupdates auch aus neueren Kernel-Versionen übernommen wird. Für einen Server ist dies die beste Wahl: stabil, getestet und automatisch von der Distribution aktualisiert.

In seltenen Fällen kann der neueste Kernel erforderlich sein, beispielsweise aufgrund einer neuen Dateisystem-, Netzwerk- oder Hardwarefunktion oder für ein Programm, das einen neueren Kernel benötigt. Hierfür bietet das Paket „kernel-ml“ (Mainline) aus dem ELRepo-Repository die Möglichkeit: Dabei handelt es sich um den aktuellen stabilen Kernel von kernel.org, der für AlmaLinux kompiliert wurde. Bevor Sie damit beginnen, lesen Sie bitte den Artikel „Was ist der Linux-Kernel?“ sowie unseren Blogbeitrag über die Vor- und Nachteile eines angepassten Kernels.

Wir haben die folgenden Schritte im Oktober 2026 auf den Systemen AlmaLinux 10.2 (x86_64) und AlmaLinux 9.8 in einer virtuellen Maschine getestet. Führen Sie die Befehle als Root-Benutzer oder mit „sudo“ aus.

Bevor Sie die Installation durchführen

• Erstellen Sie ein Backup, auf einem VPS möglichst einen Snapshot. Sollte der neue Kernel nicht starten, können Sie das System innerhalb weniger Minuten aus dem Snapshot wiederherstellen.
• Separat übersetzte Kernel-Module (beispielsweise bestimmte VPN-, Firewall- oder Dateisystem-Module) funktionieren unter Umständen nicht mit dem neuen Kernel.
• Der ELRepo-Kernel wird nicht von AlmaLinux unterstützt. Die Sicherheitsupdates werden von ELRepo veröffentlicht, und Sie müssen diese selbst installieren.
• Bei aktiviertem Secure Boot wird die kernel.ml-Datei nicht geladen. Überprüfen Sie dies mit dem Befehl „mokutil --sb-state“. Der Test mit „pesign -S -i /boot/vmlinuz-…“ ergibt, dass der ELRepo-Kernel überhaupt nicht signiert ist („No signatures found“), während der AlmaLinux-Kernel mit dem Schlüssel „AlmaLinux Secure Boot Signing“ signiert wurde. Die Registrierung des mit dem Paket „elrepo-release“ gelieferten ELRepo-Secure-Boot-Schlüssels (/etc/pki/elrepo/SECURE-BOOT-KEY-elrepo.org.der) hilft hier nicht weiter, da der Kernel nicht damit signiert wurde. Wenn Secure Boot auf Ihrem Rechner aktiviert ist, sollten Sie beim werkseitigen Kernel bleiben. Auf dem Testrechner war es nicht aktiviert („This system doesn’t support Secure Boot“).
• Bei einem Managed VPS sollten Sie sich bitte vorab mit uns abstimmen, da ein Kernel-Wechsel den Betrieb des Servers beeinträchtigt.

Was steht zur Verfügung?

	kernel-ml (Mainline)	kernel-lt (mit langfristigem Support)
AlmaLinux 10, x86_64	Ja, 7.2.13	keine
AlmaLinux 10, aarch64 (ARM)	keine	keine
AlmaLinux 9	Ja, 7.2.13	Ja, 6.1.190

Die Versionsangaben entsprechen dem Stand zum Zeitpunkt des Tests. Für AlmaLinux 10 stellt ELRepo den Mainline-Kernel nur für x86_64-Prozessoren bereit; auf ARM-basierten Rechnern ist das Repository leer.

1. Installation des ELRepo-Repositorys

Importieren Sie den Signaturschlüssel von ELRepo und installieren Sie anschließend das Repository-Paket.

AlmaLinux 10:

sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-v2-elrepo.org
sudo dnf install https://www.elrepo.org/elrepo-release-10.el10.elrepo.noarch.rpm

AlmaLinux 9:

sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-v2-elrepo.org
sudo dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm

Auf beiden Systemen wird der Schlüssel „RPM-GPG-KEY-v2-elrepo.org“ verwendet. Der ältere ELRepo-Schlüssel mit dem Namen „RPM-GPG-KEY-elrepo.org“ wird von AlmaLinux 10 abgelehnt, da er mit SHA1 erstellt wurde: „Policy rejects 309BC305BAADAE52 … because SHA1 is not considered secure“, „key 1 import failed“.

Das Paket richtet vier Repositories ein: „elrepo“ (Treiber) ist aktiviert, „elrepo-kernel“, „elrepo-testing“ und „elrepo-extras“ sind deaktiviert. Die Kernel befinden sich im Repository „elrepo-kernel“; dieses wird nur für die Dauer der Installation aktiviert.

Die verfügbaren Kernel:

dnf --disablerepo='*' --enablerepo=elrepo-kernel list --available

2. Installation von kernel-ml

sudo dnf --enablerepo=elrepo-kernel install kernel-ml

Es werden drei Pakete installiert: „kernel-ml“, „kernel-ml-core“ und „kernel-ml-modules“. Der alte Kernel verbleibt auf dem Rechner, sodass Sie jederzeit wieder darauf zurückgreifen können.

Wenn Sie separat kompilierte Kernelmodule verwenden (mit DKMS installierte Treiber), benötigen Sie für den neuen Kernel auch das Entwicklerpaket, da die Module sonst nicht geladen werden:

sudo dnf --enablerepo=elrepo-kernel install kernel-ml-devel

Der neue Kernel wird automatisch als Standard festgelegt. Überprüfung:

sudo grubby --default-kernel

/boot/vmlinuz-7.2.13-1.el10.elrepo.x86_64

3. Neustart und Überprüfung

sudo systemctl reboot

Nach dem Neustart:

uname -r
sudo grubby --info=ALL | grep -E '^(index|title)'

Im Test starteten beide Systeme problemlos mit dem neuen Kernel, das Netzwerk und die Dienste funktionierten (systemctl --failed war leer). Sehen Sie sich auch das Protokoll an (sudo journalctl -b -p err), siehe: Protokoll-Dateien lesen.

Achtung: Das Kernel-Update von AlmaLinux setzt die Standardeinstellungen zurück

Unter AlmaLinux wird aufgrund der Einstellung „UPDATEDEFAULT=yes“ in der Datei „/etc/sysconfig/kernel“ jeder neu installierte Kernel zum Standardkernel. Im Test führte die Aktualisierung des Systems nach der Installation des ELRepo-Kernels zu einem neuen AlmaLinux-Kernel (6.12.0-211.69.1), woraufhin der Befehl „grubby --default-kernel“ bereits anzeigte, dass der nächste Neustart mit dem werkseitigen Kernel erfolgt wäre.

Überprüfen Sie daher nach jedem Update die Einstellungen und setzen Sie sie gegebenenfalls zurück:

sudo grubby --default-kernel
sudo grubby --set-default /boot/vmlinuz-7.2.13-1.el10.elrepo.x86_64

In der Datei „/etc/sysconfig/kernel“ verhindert die Einstellung „DEFAULTKERNEL=kernel-ml“, dass bei einer Aktualisierung der AlmaLinux-Kernel die Standardeinstellung überschrieben wird. Im Test wurden jedoch auch die neuen kernel-ml-Versionen dadurch nicht automatisch als Standard festgelegt, sodass die Einstellung auch nach einer Aktualisierung von kernel-ml manuell vorgenommen werden muss. Unabhängig davon, für welche Lösung Sie sich entscheiden, überprüfen Sie nach der Aktualisierung bitte die Ausgabe von „grubby --default-kernel“.

Aktualisierung von kernel-ml

Da das Repository „elrepo-kernel“ deaktiviert ist, aktualisiert „dnf upgrade“ den „kernel-ml“-Zweig nicht. Dies muss separat angefordert werden:

sudo dnf --enablerepo=elrepo-kernel upgrade kernel-ml

Wenn Sie möchten, dass das System-Update automatisch auch den neuen Mainline-Kernel installiert, aktivieren Sie diese Option dauerhaft: sudo dnf config-manager --set-enabled elrepo-kernel. Da Mainline-Kernel häufig eine neue Hauptversion erhalten, sollten Sie dies nur tun, wenn Sie den Rechner nach jedem Update überprüfen.

Auf dem Rechner bleiben maximal drei Kernel gleichzeitig erhalten (installonly_limit=3 in der Datei /etc/dnf/dnf.conf); der älteste wird bei der vierten Installation gelöscht.

Rückkehr zum Standard-Kernel

Auf VPS-Servern, die aus Cloud-Images installiert wurden, wird das GRUB-Menü häufig nicht angezeigt (GRUB_TIMEOUT=0 in der Datei /etc/default/grub; dies war auch im Test der Fall), weshalb beim Systemstart kein Kernel ausgewählt werden kann. Die Wiederherstellung ist dennoch einfach, solange der Server startet:

sudo grubby --info=ALL | grep -E '^(index|kernel)'
sudo grubby --set-default /boot/vmlinuz-5.14.0-687.53.1.el9_8.aarch64
sudo systemctl reboot

Geben Sie nach dem Befehl „--set-default“ den Pfad zum werkseitigen Kernel an, wie in der Liste angegeben. Das obige Beispiel stammt vom Testrechner Nr. 9. Falls der Rechner gerade mit dem Kernel läuft, den Sie als Standard festlegen möchten, kann der Pfad wie folgt ersetzt werden: „sudo grubby --set-default "/boot/vmlinuz-$(uname -r)"“. Falls der Rechner mit dem werkseitigen Kernel gestartet ist und der ELRepo-Kernel nicht mehr benötigt wird:

sudo dnf remove 'kernel-ml*'

Entfernen Sie den ELRepo-Kernel nicht, während er gerade läuft (uname -r darf in der Ausgabe nicht „elrepo“ enthalten). Im Test listete „grubby“ nach der Entfernung nur noch den werkseitigen Kernel auf, der somit zum Standard wurde. Falls Sie das ELRepo-Repository nicht mehr benötigen: sudo dnf remove elrepo-release.

Sollte der Rechner mit dem neuen Kernel gar nicht erst starten, stellen Sie den VPS bitte anhand des Snapshots wieder her oder wenden Sie sich an unseren Support.

Anstelle eines System-Updates

Wenn Sie keine bestimmte Kernel-Funktion benötigen, sondern einfach nur ein neueres System wünschen, empfiehlt es sich, statt eines Kernel-Wechsels auf die nächste Hauptversion von AlmaLinux umzusteigen, da dort alle Pakete gemeinsam getestet wurden. Die einzelnen Schritte dazu werden im Artikel „Aktualisierung von AlmaLinux und Rocky Linux mit ELevate“ beschrieben. Unsere KVM-VPS bieten vollständigen Root-Zugriff, sodass Sie den Kernel selbst auswählen können.