CentOS-Alternativen 2026: AlmaLinux vs Rocky Linux (und wie Sie migrieren)

CentOS ist tot: die Kurzversion

CentOS Linux wurde eingestellt. CentOS 8 wurde vorzeitig beendet und erreichte am 31. Dezember 2021 das End of Life; CentOS 7 erreichte am 30. Juni 2024 das End of Life. Eines von beiden heute zu betreiben bedeutet keine Sicherheitsupdates. Und CentOS Stream ist nicht der Ersatz, den die meisten wollen: seit dem Kurswechsel 2020 sitzt es upstream von Red Hat Enterprise Linux (eine Rolling-Vorschau auf das nächste RHEL, kein downstream stabiler Rebuild davon).

Die zwei echten Nachfolger sind AlmaLinux und Rocky Linux. Beide sind kostenlos, beide sind RHEL-kompatibel, beide sind legitime Ersatzlösungen für CentOS Linux. Hier die bedingungsbasierte Antwort, die dieser Leitfaden begründet:

• Wählen Sie AlmaLinux, wenn Sie einen Hosting-Stack betreiben (cPanel, CloudLinux), schnellere Sicherheitspatches wollen oder eine Distribution mit eigener FIPS-140-3-Validierung brauchen.
• Wählen Sie Rocky Linux, wenn Sie speziell strikte 1:1-Binärparität mit RHEL benötigen, bug-für-bug, weil ein Anbieter oder eine interne Zertifizierung den identischen Build verlangt.
• Wählen Sie RHEL selbst, wenn Compliance ein bezahltes Support-SLA und eine Hersteller-Zertifizierung erfordert und Sie sich das Abonnement leisten können.
• Wählen Sie CentOS Stream nicht als stabile Produktivbasis. Es ist exzellent, um RHEL vorauszusehen und für die Entwicklung; es ist kein festes Point-Release-Ziel.

Der Rest dieses Artikels erklärt warum, und (denn das ist der Teil, den jeder andere Leitfaden auslässt) genau, wie Sie migrieren, mit benannten Schwachstellen.

Was jetzt wirklich unterscheidet: ABI vs 1:1 binär

Vor Juni 2023 machten die beiden Projekte dasselbe: die von Red Hat veröffentlichten RHEL-Quellen zu einer kostenlosen, identischen Distribution nachbauen. Dann beschränkte Red Hat die Verteilung der RHEL-Quellen auf sein Kundenportal, sodass CentOS Stream als einzige öffentliche Quelle übrig blieb. AlmaLinux und Rocky reagierten unterschiedlich, und dieser Unterschied ist die ganze Entscheidung.

Rocky Linux entschied sich, 1:1 zu bleiben. Es baut weiterhin aus den exakten RHEL-Source-RPMs, die über Wege beschafft werden, für die Red Hats Abonnementbedingungen nicht akzeptiert werden müssen. In Rockys eigenen Worten aus Keeping Open Source Open: Ein Weg ist "die Nutzung von UBI-Container-Images, die auf RHEL basieren," ein anderer sind "Pay-per-Use-Public-Cloud-Instanzen… jeder kann RHEL-Images in der Cloud starten und so den Quellcode für alle Pakete und Errata erhalten," alles "ohne unser Engagement für Open-Source-Software zu kompromittieren oder ToS- oder EULA-Beschränkungen zu akzeptieren." Das Ergebnis ist eine Distribution, die darauf ausgelegt ist, bug-für-bug identisch mit RHEL zu sein.

AlmaLinux entschied sich stattdessen für ABI-Kompatibilität. Statt byte-identischen Paketen hinterherzujagen, ließ AlmaLinux das 1:1-Ziel fallen und baut jetzt vor allem aus CentOS Stream, mit dem Ziel der Application-Binary-Interface-Kompatibilität: "Software, die auf RHEL läuft, läuft genauso auf AlmaLinux." In ihrer eigenen Fußnote bedeutet ABI-Kompatibilität "daran zu arbeiten sicherzustellen, dass Anwendungen, die für RHEL (oder RHEL-Klone) gebaut wurden, ohne Probleme auf AlmaLinux laufen können." Da es aus Stream baut, statt auf veröffentlichte RHEL-Quellen zu warten, kann AlmaLinux zudem manche Fixes vor dem Downstream-Rhythmus ausliefern.

Was ändert "ABI-kompatibel versus 1:1 binär" nun wirklich für einen laufenden Server? Weniger, als die Debatte vermuten lässt, an drei konkreten Stellen:

• RPMs von Drittanbietern und ISVs: Kein praktischer Unterschied. Beide erfüllen die RHEL-ABI, also installiert und läuft alles, was für RHEL gebaut wurde (ein Hersteller-Agent, ein Datenbank-RPM, ein Monitoring-Paket), auf beiden. Das ist der Fall, der für fast jeden zählt, und er ist kein Problem.
• Kernelmodule (kmods): Beide folgen dem RHEL-Kernel und seiner kABI, sodass vorgefertigte Out-of-Tree-Module in der Regel auf beiden laden. Der theoretische Vorteil liegt bei Rocky: Ein byte-identischer Kernel ist eine stärkere Garantie für ein binäres kmod als eine ABI-Garantie. In der Praxis hält AlmaLinux kABI-Parität ein, und es gibt keinen dokumentierten, reproduzierbaren Bruch. Betrachten Sie das als Rockys Positionierung, nicht als beobachteten Fehler bei AlmaLinux.
• FIPS 140-3: Das ist die eine Stelle, an der die Trennung materiell sichtbar wird. AlmaLinux hat eine eigene FIPS-140-3-Validierung: Die kryptografischen Module von AlmaLinux 9.2 wurden validiert (finanziert und eingereicht von CloudLinux), spätere Releases durchlaufen weiter die NIST-Pipeline. Rocky Linux besitzt kein eigenes NIST-validiertes Zertifikat; seine Module standen auf NISTs Modules-in-Process-Liste, und FIPS-Compliance für Rocky wird kommerziell von CIQ/TuxCare angeboten. Der Krypto-Code ist bei beiden funktional identisch mit dem von RHEL; der Unterschied ist das Zertifikat, und wenn eine Beschaffungsvorgabe "FIPS 140-3 validiert" verlangt, ist genau das der springende Punkt.

Noch eine Achse hinter den beiden Projekten: wer sie finanziert und steuert. AlmaLinux wird unterstützt von CloudLinux, einem Gründungssponsor der Platin-Stufe mit einer Zusage von rund $1M/year, und wird von der gemeinnützigen AlmaLinux OS Foundation verwaltet. Rocky Linux wird von der Rocky Enterprise Software Foundation (RESF) betrieben, mit kommerziellem Support von CIQ. Keines von beiden verschwindet; beide liefern seit Jahren planmäßig. Das ist nicht mehr das Drama, das es 2023 war.

CentOS Stream: nützlich, aber keine Produktivbasis

Es lohnt sich, bei Stream genau zu sein, denn der Name führt in die Irre. Red Hat entwickelt RHEL inzwischen in CentOS Stream: Stream wird "kontinuierlich ausgeliefert" und "läuft der RHEL-Entwicklung knapp voraus." Das bedeutet, Stream erhält Änderungen, bevor sie in einem veröffentlichten RHEL-Point-Release landen, das Gegenteil des alten CentOS Linux, das RHEL hinterherlief.

Stream ist wirklich gut für zwei Dinge: einen Vorausblick auf das, was in der nächsten RHEL kommt, und CI/Development gegen die RHEL, die es in ein paar Monaten geben wird. Als feste Produktivbasis passt es schlecht, weil es ein bewegliches Ziel ohne stabile Point-Releases zum Festlegen ist. Ist Ihr erster Gedanke "CentOS Stream ist die natürliche Fortsetzung von CentOS," korrigieren Sie ihn; die Fortsetzung, die Sie suchen, ist AlmaLinux oder Rocky. Für den Kontext, wo das alles neben Ubuntu und Debian steht, siehe unseren Übersichtsleitfaden zur Wahl einer Linux-Distribution für einen Dedicated Server.

Nebeneinander: die Dimensionen, an denen Sie wirklich entscheiden

Zwei Zeilen darin verdienen besondere Erwähnung, weil sie sich kürzlich geändert haben und reale Fälle entscheiden:

cPanel strich Rocky Linux in Version 134. Seit cPanel & WHM Version 134 (veröffentlicht im Januar 2026) lässt sich ein Rocky-Linux-Server nicht mehr auf das aktuelle cPanel upgraden; die unterstützte OS-Liste ist AlmaLinux 8/9/10, CloudLinux 8/9/10 und Ubuntu 24.04 LTS, und cPanel empfiehlt ausdrücklich, Rocky-Server zu AlmaLinux zu konvertieren. Wer cPanel betreibt, für den entscheidet allein das die AlmaLinux-versus-Rocky-Frage. (Prüfen Sie dies anhand der aktuellen Release Notes von cPanel, bevor Sie handeln; das ändert sich derzeit schnell.)

Rocky setzt die vorherige Minor-Version auf EOL, sobald eine neue erscheint. Anders als bei RHELs Extended Update Support gilt bei Rocky: Sobald etwa 9.7 erscheint, ist 9.6 sofort End of Life. Müssen Sie für ein längeres Qualifizierungsfenster auf einer bestimmten Minor-Version bleiben, spricht das für RHEL, nicht für Rocky.

Das Urteil, ohne Wenn und Aber

Jeder andere Vergleich endet mit "beide sind exzellent, kommt darauf an." Hier die Version, die sich tatsächlich festlegt:

• Sie betreiben cPanel oder einen CloudLinux-Stack? → AlmaLinux. cPanel strich Rocky, CloudLinux ist das Unternehmen hinter Alma, und das CloudLinux/Immunify/Hardened-Kernel-Ökosystem ist darum herum gebaut. Das ist nicht mal knapp.
• Sie wollen die frischesten Sicherheitspatches auf einem kostenlosen EL? → AlmaLinux. Da es aus Stream baut, kann es manche Fixes vor dem strikten Downstream-Rhythmus ausliefern.
• Sie brauchen ein validiertes FIPS-140-3-Modul auf einer kostenlosen Distribution? → AlmaLinux, das ein eigenes Zertifikat besitzt. Rocky braucht dafür ein kommerzielles Add-on.
• Sie haben eine Hersteller- oder interne Regel, die byte-identische RHEL-Builds verlangt? → Rocky Linux. Verlangt eine Zertifizierung wörtlich "dieselbe Binary wie RHEL," ist Rockys 1:1-Modell die sichere Antwort.
• Sie sind durch Compliance an ein unterstütztes, zertifiziertes OS mit SLA gebunden? → RHEL, samt Abonnement. Mit unseren RHEL Dedicated Servern bringen Sie Ihre eigene Entitlement mit.

Für die meisten, die CentOS 2026 verlassen, besonders alle im Hosting, ist die pragmatische Standardwahl AlmaLinux. Rocky ist die richtige Wahl für die engere Anforderung "ich brauche bit-für-bit RHEL." Beide schlagen das Verharren auf einem EOL-CentOS um eine unendliche Marge, denn "keine Sicherheitsupdates" ist keine Strategie.

Von CentOS migrieren, Schritt für Schritt

Es gibt zwei sehr unterschiedliche Situationen, und sie zu vermischen ist, wo es wehtut:

1. Sie sind auf CentOS 8 (oder einem anderen EL8/EL9-Rebuild) und wollen seitwärts zu Rocky oder Alma wechseln, bei derselben Major-Version. Das ist eine gut unterstützte, skriptgesteuerte In-Place-Konvertierung.
2. Sie sind auf CentOS 7 und müssen eine Major-Version überspringen (7 → 8 → 9). Das ist ein Leapp-basiertes Upgrade, es ist wirklich schwieriger, und es wirft Ihnen eine Mauer aus Pre-Flight-Inhibitors entgegen. Diese Mauer ist der eigentliche Inhalt. Jede Umgebung stößt darauf.

Die folgenden Befehle sind die echten Tools, Flags und Repositories. Die gezeigte Konsolenausgabe ist repräsentativ für das, was jedes Tool ausgibt, um die Form eines Durchlaufs zu illustrieren. Setzen Sie Ihre eigenen Hostnamen ein und erwarten Sie Ihre eigenen Paketzahlen. Führen Sie dies immer zuerst gegen einen Snapshot oder einen Wegwerf-Klon aus, niemals gegen eine Produktivmaschine, die Sie nicht zurückrollen können.

Bevor Sie irgendetwas anfassen: die Pre-Flight-Checkliste

Gleich für alle drei Pfade:

• Erstellen Sie einen vollständigen Snapshot oder ein Backup auf Image-Ebene. Diese Konvertierungen sind faktisch eine Einbahnstraße; es gibt kein sauberes "Undo"-Skript. Ihr Rollback-Plan ist der Snapshot (siehe unten).
• Inventarisieren Sie Repositories von Drittanbietern (dnf repolist / yum repolist). EPEL ist unproblematisch; Hersteller-Repos (eine Datenbank, ein Monitoring-Agent, ein Panel) können Pakete festpinnen, die der Konvertierung entgegenwirken. Notieren Sie sie.
• Listen Sie Out-of-Tree-Kernelmodule auf (lsmod, DKMS-Pakete): Storage-/NIC-Treiber, ZFS, proprietäre Agents. Das sind die üblichen Bruchstellen.
• Erfassen Sie Ihr Panel/Ihre Control-Plane (cPanel, Plesk, CloudPanel) und prüfen Sie dessen unterstützte-OS-Matrix für das Ziel, bevor Sie beginnen.
• Bestätigen Sie freien Festplattenspeicher für einen vollständigen erneuten Paket-Download und den Swap, sowie dass die Maschine die Ziel-Repos erreichen kann.

Pfad A: CentOS/EL8 oder EL9 → Rocky Linux (migrate2rocky)

Rocky liefert migrate2rocky im rocky-tools-Repository. Es gibt zwei Skripte: migrate2rocky.sh konvertiert ein EL8-System zu Rocky 8, und migrate2rocky9.sh konvertiert EL9 zu Rocky 9. Holen Sie sich das zu Ihrer Major-Version passende Skript und führen Sie es mit -r aus, um die Konvertierung durchzuführen:

# On an EL8 system (CentOS 8 / other EL8 rebuild)
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -r

Das Skript entfernt die Identitätspakete der alten Distro, installiert die Rocky-Release- und GPG-Pakete, richtet jedes Repo auf Rocky aus und installiert das Basissystem von Rocky-Mirrors neu. Eine veröffentlichte CentOS 8 → Rocky 8 Walkthrough hält die Form eines echten Durchlaufs fest; sie bildet jedes Repo ab, listet die CentOS-Pakete auf, die gegen Rocky-Äquivalente getauscht werden (centos-linux-release → rocky-release, centos-gpg-keys → rocky-gpg-keys, centos-linux-repos → rocky-repos), und endet bei Complete! / Done, please reboot your system. Repräsentative Ausgabe:

migrate2rocky - Begin logging at Tue Jul  7 09:14:02 2026.

Removing dnf modules that are not compatible with Rocky Linux...
Identifying repositories to be replaced...
Determining repository names for Rocky Linux...
Repository baseos matched by repository id baseos.
Repository appstream matched by repository id appstream.
Removing distribution packages: centos-linux-release centos-gpg-keys ...
Installing Rocky Linux release package: rocky-release rocky-gpg-keys ...
Switching old release to Rocky Linux release.
Distro-syncing to Rocky Linux ...
...
Complete!
Done, please reboot your system.

Starten Sie neu und bestätigen Sie, dass Sie bei Rocky gelandet sind:

$ cat /etc/redhat-release
Rocky Linux release 8.10 (Green Obsidian)
$ rpm -q rocky-release
rocky-release-8.10-1.5.el8.noarch

Zwei Vorbehalte, bevor Sie dies auf etwas ausführen, das Ihnen wichtig ist. CIQ, das Unternehmen hinter Rocky, warnt, dass custom-kompilierte Kernelmodule zu Fehlern führen können, "die Ihre Maschine unbrauchbar machen könnten," testen Sie also zuerst im Labor; und auf einer UEFI-Maschine müssen Sie beim ersten Neustart möglicherweise den Rocky-Booteintrag manuell in GRUB auswählen. Es gibt keine verlässlich veröffentlichte Dauer für die Konvertierung; es ist ein Pakettausch plus ein distro-sync, begrenzt durch Download- und dnf-Zeit, typischerweise Minuten bis zu einigen Dutzend Minuten auf einer bescheidenen Maschine. Stoppen Sie die Zeit bei Ihrem eigenen Snapshot-Durchlauf, um einen verlässlichen Wert zu erhalten.

Pfad B: CentOS/EL8 oder EL9 → AlmaLinux (almalinux-deploy)

AlmaLinux liefert almalinux-deploy, ein einzelnes Skript, das ein EL-System derselben Major-Version (8.4+, 9 oder 10) zu AlmaLinux konvertiert. Es führt zuerst eine Pre-Flight-Kompatibilitätsprüfung durch, tauscht dann Release-Pakete und installiert von AlmaLinux-Repos neu:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh

Die Statuszeilen, die das almalinux-deploy.sh-Skript ausgibt (jeweils gefolgt von OK oder ERROR), laufen in etwa dieser Reihenfolge ab:

Check root privileges                                               OK
Check Secure Boot disabled                                          OK
Check centos-8.x86_64 is supported                                  OK
Your OS is supported
Download the AlmaLinux GPG public key                               OK
Install almalinux-release package                                   OK
Run dnf distro-sync -y                                              OK
Enabled AlmaLinux repositories that were before the migration       OK
Migration to AlmaLinux is completed

Neu starten und verifizieren:

$ cat /etc/almalinux-release
AlmaLinux release 8.10 (Cerulean Leopard)

Der AlmaLinux-Migrationsleitfaden legt die Voraussetzungen fest: Die Quelle muss EL 8.4 oder neuer sein, Secure Boot deaktiviert (die Zeile Check Secure Boot disabled ist genau die Stelle, an der das Skript stoppt, wenn das nicht der Fall ist), eine Boot-Partition mit Platz für drei Kernel, und (wie immer) zuerst ein angelegter Snapshot.

Pfad C: CentOS 7 → 8 → 9 (ELevate, und die Inhibitor-Mauer)

CentOS 7 ist der schwierige Fall, und hier trennt Ehrlichkeit einen nützlichen Leitfaden von einem Befehls-Dump. Sie können CentOS 7 nicht direkt zu einer Version-9-Distribution springen. AlmaLinux' eigener ELevate-Leitfaden ist eindeutig: Leapp führt einstufige Upgrades durch, der Pfad ist also 7 → 8, dann 8 → 9 (und danach 9 → 10, wenn Sie die neueste Version wollen). Jeder Sprung ist ein separater Leapp-Durchlauf mit eigenem Pre-Flight.

ELevate ist das Leapp-basierte Tooling des AlmaLinux-Projekts, das Red Hats Leapp auf Cross-Distro-, Cross-Major-Upgrades erweitert. Der 7 → 8-Durchlauf sieht so aus:

# Install ELevate + the AlmaLinux migration data
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux

# Pre-flight analysis — this is the important part
sudo leapp preupgrade

leapp preupgrade upgradet nichts. Es analysiert das System und schreibt einen Bericht nach /var/log/leapp/leapp-report.txt mit einer Liste von Inhibitors: blockierenden Problemen, die Sie lösen müssen, bevor Leapp fortfährt. Auf einer echten CentOS-7-Maschine sollten Sie mit mehreren rechnen, und dieselbe Handvoll taucht in Bericht nach Bericht wieder auf. Das sind diejenigen, auf die Leute tatsächlich stoßen, zitiert aus echten Berichten, mit der dokumentierten Lösung:

• Entfernte Kernel-Treiber. "Detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed." Die üblichen Übeltäter sind pata_acpi und floppy (plus die mpt*-SCSI-Treiber auf VMware-Gästen); entladen Sie sie mit modprobe -r pata_acpi floppy und führen Sie es erneut aus. (Valentin S, Vander Host)
• Die pam_pkcs11-Antwort. "Missing required answers in the answer file" für remove_pam_pkcs11_module_check.confirm. Leapp lässt Sie das explizit bestätigen: leapp answer --section remove_pam_pkcs11_module_check.confirm=True. (CIQ KB)
• Root-Login über SSH. "Possible problems with remote login using root account": Setzen Sie PermitRootLogin yes in /etc/ssh/sshd_config, damit Sie sich nach dem Upgrade nicht aussperren. (Bigstep)
• Ein defektes Drittanbieter-Repo. Fehlerhafte Vendor-Repo-Metadaten können das Pre-Upgrade komplett stoppen; ein Fall stieß auf einen ModelViolationError, der auf das PostgreSQL-PGDG-Repo in /etc/yum.repos.d/ zurückgeführt wurde. Deaktivieren Sie fragwürdige Repos, bevor Sie beginnen. (ApisCP)

Der 8 → 9-Sprung fügt dann zwei hinzu, die bei 7 → 8 noch nicht auftauchten: "Current x86-64 microarchitecture is unsupported in RHEL9" (beheben Sie den CPU-Typ der VM: setzen Sie ihn auf host oder ein v2-fähiges Modell auf dem Hypervisor) und "Detected RPMs with RSA/SHA1 signature" (alte Pakete von Drittanbietern, signiert mit SHA-1). (Vander Host)

Arbeiten Sie den Bericht durch, beheben Sie jeden Inhibitor, und führen Sie leapp preupgrade erneut aus, bis er sauber zurückkommt. Dann erst:

sudo leapp upgrade
sudo reboot   # boots into the upgrade initramfs, applies the transaction, reboots again

Planen Sie die Zeit ein: Das eigentliche Leapp-Upgrade dauert ungefähr 5 bis 10 Minuten plus drei Neustarts von je ~5 Minuten (in die Upgrade-Initramfs, in das SELinux-Relabeling, in das eigentliche OS), und ein Bericht von einem CentOS-7-Hosting-Panel-Konto setzte die ganze Übung bei fast einer Stunde an, Aufräumarbeiten vor und nach dem Upgrade eingeschlossen.

Nachdem 7 → 8 erfolgreich war und das System gesund ist, wiederholen Sie den ELevate-Prozess für 8 → 9. Stapeln Sie die Sprünge nicht, ohne die Maschine dazwischen zu verifizieren.

Der Rollback-Plan (testen Sie ihn, bevor Sie ihn brauchen)

Es gibt kein verlässliches Skript, das ein konvertiertes System zurückmigriert. Ihr Rollback ist der Snapshot, den Sie im Pre-Flight-Schritt erstellt haben:

1. Erstellen Sie vor dem Start einen vollständigen VM-Snapshot oder ein Image auf Blockebene der Boot- und Datenvolumes.
2. Führen Sie die Migration auf dieser Maschine durch.
3. Schlägt sie fehl oder verhält sich die Maschine unerwartet, stellen Sie den Snapshot wieder her; Sie sind exakt dort, wo Sie begonnen haben.

Auf einem Hypervisor ist das ein Rechtsklick und ein paar Minuten; auf Bare Metal bedeutet es ein Image von vor der Migration, das Sie neu ausrollen können. Der Punkt ist derselbe: Führen Sie diese Konvertierungen nie ohne getesteten Wiederherstellungsweg aus. Sowohl AlmaLinux' Migrationsleitfaden als auch CIQ sind eindeutig, dass es kein eingebautes "Undo" gibt (der Snapshot ist das Rollback), und die Foren haben die dazu passenden warnenden Geschichten, darunter ein Betreiber, der mitten in ELevate "so gut wie gebrickt" zurückblieb, mit nur einer frischen Neuinstallation als Rückfalloption. Die "Fix-Forward"-Option bei einem gescheiterten Cross-Major-Upgrade kann eine lange Nacht werden.

Was kaputtgeht (der ehrliche Teil)

Die Konvertierungen selbst sind zuverlässig; die Schäden stecken fast immer in den Dingen, die an das Basissystem angeschraubt sind. Das sind echte, dokumentierte Schwachstellen aus den Issue-Trackern und Foren der Tools:

• Ein veraltetes Kernelmodul eines Drittanbieters bricht das Pre-Flight. Ein migrate2rocky-Durchlauf brach mit einer defekten RPM-Datenbank ab, weil ein altes el7-kmod-kvdo-Modul mit sich selbst kollidierte, was in "Error: Check discovered 95 problem(s)" endete. Räumen Sie Out-of-Tree-Module auf und reparieren Sie die RPM-Datenbank vor der Konvertierung.
• cPanel/Panel-Abhängigkeitskonflikte während distro-sync. Die Konvertierung einer cPanel-Maschine zu AlmaLinux stieß auf Konflikte zwischen libstdc++-devel-...el8.alma und Standardbibliotheken, die den dnf distro-sync scheitern ließen; der Workaround war der erneute Lauf mit --allowerasing/--skip-broken. Schlimmer noch, ein Leapp-8-→-9-Upgrade auf einem cPanel-Host löschte beim Neustart alle WHM/cPanel-Pakete. Prüfen Sie zuerst die unterstützte-OS-Matrix Ihres Panels für das Ziel.
• EFI/GRUB fällt nach der Konvertierung auf einen Grub-Prompt zurück. Eine UEFI-Maschine landete nach migrate2rocky bei einem nackten Grub-Prompt; die Lösung war grub2-mkconfig --output=/boot/efi/EFI/rocky/grub.cfg, und Secure Boot muss vor Beginn deaktiviert sein.
• Ein verirrtes Stream-only-Repo bleibt zurück. Nach der Migration zu AlmaLinux überlebte ein CentOS-Stream-only-Paket epel-next-release und verursachte Konflikte, bis es mit dnf remove epel-next-release entfernt wurde.
• Konfigurationsdrift nach einem Major-Upgrade. Leapp übernimmt die Konfiguration, aber nicht perfekt. Rechnen Sie damit, sshd_config, firewalld und SELinux abgleichen zu müssen (das während des Upgrades auf permissive zurückfällt, also wieder auf enforcing setzen), plus jeden Dienst, dessen Standardwerte sich zwischen den Major-Versionen geändert haben.

Validierung nach der Migration

Welchen Pfad Sie auch genommen haben, verifizieren Sie, bevor Sie es für abgeschlossen erklären:

# Confirm the OS identity
cat /etc/os-release

# Any packages still from the old distro? (should be empty/none)
rpm -qa | grep -Ei 'centos' 

# Reconcile everything against the new repos
sudo dnf distro-sync -y

# Repos point where you expect
dnf repolist

# Core services are up
systemctl --failed

dnf distro-sync ist der wichtige Befehl: Er gleicht jedes installierte Paket mit der Version der Zieldistribution ab und räumt alles auf, was die Konvertierung zwischen zwei Releases hängen ließ. Haben Sie eine RHEL-Maschine (statt CentOS) in einen Rebuild migriert, führen Sie zusätzlich subscription-manager unregister / remove aus und deinstallieren Sie subscription-manager, damit das System nicht mehr versucht, mit Red Hat zu kommunizieren. Schließen Sie mit einem weiteren Neustart und der Bestätigung der Dienste ab, und aktivieren Sie danach alle Drittanbieter-Repos wieder, die Sie im Pre-Flight deaktiviert hatten.

Häufig gestellte Fragen

Ist CentOS Stream sicher für den Produktivbetrieb?

Es ist stabil genug für den Betrieb, aber es ist eine Rolling-Distribution, die upstream von RHEL positioniert ist, ohne feste Point-Releases zum Festlegen. Für die meisten Produktivumgebungen, die ein vorhersehbares, gepatchtes Point-Release-Ziel wollen, ist AlmaLinux oder Rocky die bessere Wahl. Stream glänzt beim Vorausblick auf RHEL und für CI/Development gegen das, was RHEL werden wird.

Kann ich CentOS 7 direkt zu AlmaLinux 9 oder 10 migrieren?

Nein. Leapp/ELevate macht eine Major-Version pro Durchlauf, der Pfad ist also CentOS 7 → 8, dann 8 → 9, dann 9 → 10: jeweils ein separater, verifizierter Schritt. Es gibt keinen unterstützten direkten Sprung von 7 zu einer Version-9- oder Version-10-Distribution. Bei vielen CentOS-7-Umgebungen ist das Aufsetzen einer frischen Version-9/10-Maschine und das Übertragen der Daten weniger Aufwand als drei verkettete In-Place-Upgrades.

Ist AlmaLinux noch 1:1 mit RHEL?

Nein, und das ist Absicht. Seit 2023 zielt AlmaLinux auf ABI-Kompatibilität (Anwendungen, die für RHEL gebaut wurden, laufen unverändert auf AlmaLinux) statt auf byte-identische Pakete. Rocky Linux ist derjenige, der weiterhin strikte 1:1-Binärparität verfolgt. Für den Betrieb von Software Dritter ist die ABI-Garantie das, worauf es ankommt, und sie hält.

AlmaLinux vs Rocky Linux: ist eine schneller?

Nein. Beide werden aus denselben Upstream-Quellen mit demselben Kernel neu gebaut, es gibt also keinen reproduzierbaren Leistungsunterschied. Phoronix' EL10-Benchmarks zeigen AlmaLinux, Rocky und RHEL über Dutzende Tests hinweg praktisch gleichauf. Entscheiden Sie nach Kompatibilitätsmodell, Ökosystem, Patch-Rhythmus und FIPS, nicht nach Durchsatz.

Unterstützt cPanel Rocky Linux noch?

Nicht in aktuellen Versionen. cPanel & WHM strich die Unterstützung für Rocky Linux in Version 134; die unterstützte Liste ist AlmaLinux, CloudLinux und Ubuntu 24.04. Wer cPanel betreibt, für den ist AlmaLinux das Migrationsziel. (Prüfen Sie dies anhand der aktuellen Release Notes von cPanel, da sich das kürzlich geändert hat.)

Migration überspringen: frisch auf Serverside deployen

Der sauberste Ausstieg aus CentOS ist oft überhaupt keine In-Place-Konvertierung; es ist eine frische Maschine auf dem gewählten Nachfolger, mit übertragenen Daten und Konfiguration. Jeder Dedicated Server von Serverside spielt AlmaLinux und Rocky Linux (und RHEL, Bring-your-own-Subscription) in unter einer Minute auf Bare Metal auf, sodass Sie das Ziel aufsetzen, Ihren Stack validieren und nach eigenem Zeitplan umschalten können, statt einen Produktivhost auf ein Einwegupgrade zu verwetten.

Die Hardware ist identisch, egal welche Sie wählen, und immer aktive DDoS-Mitigation in unserem ASN-55285-Netzwerk sitzt unabhängig von der Distribution vor der Maschine. Wägen Sie noch die RHEL-Familie gegen Ubuntu oder Debian ab, beginnen Sie mit unserem Linux-Distributions-Leitfaden; haben Sie sich entschieden, installieren unsere CentOS-Nachfolger Dedicated Servers AlmaLinux oder Rocky vorinstalliert, und unsere RHEL Dedicated Servers übernehmen Ihre eigene Entitlement.