0800 71 20000
Kontakt
...
Distributionen & Auswahl

RHEL 9 auf RHEL 10: So planst du dein Upgrade

In-Place mit Leapp funktioniert bei sauber gepflegten Systemen zuverlässig. Bei stark angepassten Hosts mit Fremdrepos und alten Python-Abhängigkeiten ist der Neuaufbau der schnellere Weg. Entscheide das pro Host, nicht pauschal für die ganze Landschaft.

6 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei IT-Fachleute vergleichen Optionen an mehreren Bildschirmen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum das Upgrade mehr Planung braucht als ein dnf update

Ein In-Place-Upgrade auf ein neues Major-Release ist kein Paket-Update, sondern ein Eingriff in Kernel, Bootloader, RPM-Datenbank, SELinux-Policy und sämtliche Konfigurationsdateien gleichzeitig. Red Hat unterstützt den Weg von RHEL 9 nach RHEL 10 offiziell über Leapp, aber nur aus einem aktuellen Minor-Release heraus und nur für Systeme, die bestimmte Voraussetzungen erfüllen. Wer den Sprung von RHEL 8 direkt auf RHEL 10 versucht, läuft ins Leere, denn dieser Pfad existiert nicht und muss über RHEL 9 als Zwischenstation gehen.

RHEL 10 bringt zudem harte Schnitte mit. Die CPU-Baseline liegt bei x86-64-v3, ältere Server ohne AVX2 fallen damit komplett aus dem Raster. Die alten iptables-Werkzeuge sind verschwunden, nftables ist der einzige verbleibende Weg. Der X.org-Server ist entfallen, dnf5 ersetzt den bisherigen Paketmanager, und eine Reihe von Kryptostandards wie SHA-1-Signaturen ist nur noch mit ausdrücklicher Ausnahme nutzbar. Jede dieser Änderungen kann eine Anwendung treffen, die seit Jahren unauffällig läuft.

Schiefgehen tut es an denselben Stellen: Der Preupgrade-Report wird nur überflogen, statt jeden Inhibitor einzeln abzuarbeiten. Eigene und Drittanbieter-Repositories sind nicht auf RHEL 10 gemappt, sodass mitten im Transaktionslauf Pakete fehlen. Kernel-Module von Storage- oder Backup-Herstellern haben noch keine passende Version. Und es gibt kein definiertes Rückfallszenario, weil niemand vorher geklärt hat, ob der Snapshot der virtuellen Maschine oder ein LVM-Snapshot im laufenden Betrieb überhaupt konsistent zurückspielbar wäre.

Miniatur-Szene: drei Server-Podeste nebeneinander, davor eine Waage zum Vergleich zweier Optionen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Sechs Etappen des In-Place-Upgrades

  1. 01 Inventar und Minor-Stand
  2. 02 leapp preupgrade auswerten
  3. 03 Inhibitoren und Repos beheben
  4. 04 Testlauf am Klon
  5. 05 leapp upgrade und Reboot
  6. 06 Nacharbeit und Abnahme
Was du mitnimmst

Der Weg von RHEL 9 nach RHEL 10 in klaren Schritten

Ein Upgrade, das sauber durchläuft, entsteht vor dem eigentlichen Upgrade-Lauf. Der folgende Ablauf hat sich in gewachsenen Umgebungen bewährt und ist auch der rote Faden unseres Seminars RHEL 10: Upgrade Training.

Ausgangsstand herstellen

Bring das System zunächst auf den aktuellen RHEL-9-Minor-Stand, starte es neu und prüfe, ob es danach ohne Handarbeit wieder hochkommt. Ein System, das schon vor dem Upgrade nur mit Nachhelfen bootet, wird den Leapp-Lauf nicht überstehen.

Preupgrade-Report ernst nehmen

leapp preupgrade schreibt einen Bericht nach /var/log/leapp/leapp-report.txt und als JSON. Arbeite ihn nach Risikostufen ab: Inhibitoren blockieren das Upgrade hart, High-Risk-Meldungen brauchen eine bewusste Entscheidung, und erst wenn beides geklärt ist, ist der Lauf realistisch.

Repositories und Dritt-Software klären

Eigene Spiegel, Satellite-Content-Views, EPEL und Herstellerpakete brauchen ein sauberes Mapping auf ihre RHEL-10-Pendants. Für kmod-basierte Treiber, Agenten und Backup-Clients gilt: erst die Freigabe des Herstellers für RHEL 10 einholen, dann terminieren.

Bekannte Grenzfälle prüfen

Verschlüsselte Root-Dateisysteme mit LUKS, Boot über SAN mit Multipath, iSCSI-Root, Software-RAID und ungewöhnliche Bootloader-Konstellationen gelten weiterhin als heikel. Solche Systeme prüfst du gezielt am Klon, statt auf ein glattes Ergebnis zu hoffen.

Testlauf und Rollback-Fenster

Zieh einen Klon der Maschine, spiel das Upgrade dort komplett durch und dokumentiere jeden manuellen Eingriff. Für die Produktion definierst du vorher, wie du zurückkommst, in der Regel über einen konsistenten Snapshot bei heruntergefahrenem System oder ein Restore aus dem Backup.

Nacharbeit nach dem Reboot

Nach dem Upgrade folgen SELinux-Relabel und Kontrolle der Denials, Abgleich der .rpmnew- und .rpmsave-Dateien, Umstellung verbliebener iptables-Regeln auf nftables sowie eine Prüfung von systemd-Units, Crypto-Policies und Monitoring-Checks.

Tutorial

Vom Ist-Stand über den Leapp-Report bis zur Nacharbeit

Der Ablauf hier entspricht der Reihenfolge, in der du das Upgrade im Betrieb wirklich abarbeitest: Bestandsaufnahme, Rückweg bauen, Preupgrade-Report auswerten, Hänger auflösen, umschalten, nacharbeiten. Alle Befehle laufen auf einem registrierten RHEL 9. Für Rocky Linux und AlmaLinux ist der Ablauf identisch, dort kommt Leapp aber aus dem ELevate-Projekt statt aus dem Red-Hat-Repo.

01

Bestandsaufnahme: Was läuft auf dem Host wirklich?

Leapp entscheidet anhand der installierten Pakete, ob es das Upgrade zulässt. Deshalb schaust du dir zuerst an, was überhaupt installiert ist und woher es kommt.

Ausgangsstand einsammeln
cat /etc/redhat-release
subscription-manager status
subscription-manager release --unset      # Release-Lock loesen, sonst haengt dnf auf 9.x fest
dnf repolist enabled

# Alles, was nicht von Red Hat kommt: die wichtigste Liste des Projekts
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -vi 'red hat' | sort

# Platz pruefen, Leapp laedt saemtliche Zielpakete vor
df -h / /boot /var

Die Vendor-Abfrage ist die Zeile, die über Aufwand oder Neuinstallation entscheidet. Alles, was dort auftaucht, brauchst du entweder als EL10-Version, als Ersatz oder gar nicht mehr. Backup-Agenten, Monitoring-Agenten und Datenbanktreiber aus Herstellerrepos sind die üblichen Verdächtigen.

Hardware-Baseline prüfen
# Welche x86-64-Level unterstuetzt die CPU?
/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[0-9]'

# Gegenprobe ueber die CPU-Flags
lscpu | tr ' ' '\n' | grep -x -E 'avx2|bmi2|fma'

RHEL 10 hebt die Mindestanforderung auf das Microarchitecture-Level x86-64-v3 an. Nur Zeilen, die als supported markiert sind, zählen. Ältere Server-Generationen ohne AVX2 fallen damit raus. Das ist kein Fehler, den du im Report reparieren kannst, sondern eine Hardware-Entscheidung, die vor allem anderen fällt.

Vor dem ersten Leapp-Lauf

PrüfpunktBefehlWas ein schlechtes Ergebnis bedeutet
Minor-Standdnf check-update; dnf updateLeapp verlangt den letzten RHEL-9-Minor-Stand, sonst bricht es sofort ab
Registrierungsubscription-manager statusOhne gültige Subscription bekommt Leapp keine Zielrepos
Fremdpaketerpm -qa --qf '%{NAME} %{VENDOR}\n'Jedes Paket ohne EL10-Nachfolger wird zur Nacharbeit oder zum Blocker
CPU-Levelld-linux-x86-64.so.2 --helpOhne x86-64-v3 ist In-Place ausgeschlossen
KonsolenzugangiDRAC, iLO, virsh consoleOhne Out-of-Band-Zugang darfst du das Upgrade nicht starten
02

Den Rückweg bauen, bevor du Leapp installierst

Ein In-Place-Upgrade hat keinen eingebauten Undo-Knopf. Der Rückweg muss stehen, bevor das erste Paket ersetzt wird, und er muss getestet sein.

Ohne diese sechs Punkte startest du nicht

  • Snapshot der kompletten VM auf Hypervisor-EbeneDer schnellste und zuverlässigste Rückweg für virtuelle Maschinen. Er bringt Platten, Firmware-Einstellungen und Bootreihenfolge in einem Rutsch zurück.
  • Bei Blech: LVM-Snapshot plus Boot-Eintrag über boomOhne Hypervisor bleibt nur der Weg über das Dateisystem. Der Boot-Eintrag ist dabei der entscheidende Teil, ein Snapshot ohne startbaren Eintrag hilft dir nachts um drei nicht.
  • Restore aus dem Backup einmal wirklich durchgespieltEin Backupjob mit grünem Haken beweist nur, dass geschrieben wurde. Ob du daraus einen lauffähigen Host bekommst, weißt du erst nach dem Rückspielen.
  • Konfiguration und Paketliste in Git abgelegtNach dem Upgrade willst du Diffs sehen können. rpm -qa | sort und ein Tarball von /etc vor dem Start kosten zwei Minuten und beantworten später jede Frage.
  • Out-of-Band-Zugang getestet, nicht nur vorhandenZwischen den Reboots gibt es kein SSH. Ein iDRAC, dessen Passwort niemand kennt, ist im Ernstfall kein Zugang.
  • Wartungsfenster mit Puffer für den RückwegDas Upgrade selbst dauert oft weniger lang als der Rückbau. Plane das Fenster so, dass der Rollback noch hineinpasst.
LVM-Snapshot mit startbarem Eintrag
lvs
sudo lvcreate -s -n root_pre10 -L 20G /dev/vg_sys/root

sudo dnf install -y boom-boot
sudo boom create --title "RHEL 9 vor Upgrade" --rootlv vg_sys/root_pre10
sudo boom list

# Zurueck: im GRUB den boom-Eintrag waehlen, danach im laufenden System
#   sudo lvconvert --merge /dev/vg_sys/root_pre10
#   sudo reboot

boom legt einen zusätzlichen GRUB-Eintrag an, der direkt vom Snapshot startet. Erst danach entscheidest du in Ruhe, ob du den Snapshot zurückmergst oder verwirfst.

03

Preupgrade laufen lassen und den Report lesen

leapp preupgrade verändert am System nichts. Es simuliert den Umbau und schreibt auf, was dagegenspricht. Der Report ist das eigentliche Arbeitsdokument des Projekts.

Leapp installieren und analysieren
sudo dnf -y update && sudo reboot          # auf den letzten RHEL-9-Minor-Stand
sudo dnf -y install leapp-upgrade
sudo leapp preupgrade --target 10.0

less /var/log/leapp/leapp-report.txt
jq '.entries[] | select(.severity=="high") | .title' /var/log/leapp/leapp-report.json

Der Lauf lädt Metadaten und Pakete vor, plane Bandbreite und Plattenplatz ein. Die JSON-Variante des Reports ist die bessere Grundlage, wenn du über viele Hosts hinweg auswerten willst, statt jeden Textreport einzeln zu lesen.

Die vier Kategorien im Leapp-Report

Eintrag im ReportBedeutungWas du damit machst
inhibitorBlockiert das Upgrade hartZwingend auflösen, sonst startet leapp upgrade gar nicht
highHohe Wahrscheinlichkeit, dass etwas kaputtgehtVor dem Upgrade klären und die Entscheidung dokumentieren
medium / lowVerhaltensänderung ohne AusfallNach dem Upgrade gezielt testen, nicht vorher blockieren
Dialog / FrageLeapp braucht eine Entscheidung von dirMit leapp answer beantworten, sonst bleibt es ein Inhibitor
Offene Fragen beantworten
grep -n -i 'question' /var/log/leapp/leapp-report.txt
sudo cat /var/log/leapp/answerfile

# Schema: leapp answer --section <dialog>.<feld>=<wert>
sudo leapp answer --section <dialog>.confirm=True

sudo leapp preupgrade --target 10.0        # nach jeder Aenderung neu laufen lassen

Die Antworten landen in /var/log/leapp/answerfile und überleben weitere Läufe. Der Report ist immer nur so aktuell wie der letzte preupgrade, arbeite nie mit einem Report von gestern und einem System von heute.

04

Die Klassiker: Fremdrepos, Module, Python, Krypto

Vier Themen erzeugen den Großteil aller Inhibitoren. Wenn du sie vorab abräumst, ist der zweite Preupgrade-Lauf meistens sauber.

Die vier häufigsten Blocker

  • Fremdrepos: Leapp kennt nur Repos, die es zugeordnet bekommt. Entweder du entfernst die Pakete, oder du hinterlegst das EL10-Repo des Herstellers, damit Leapp sie mit übernehmen kann.
  • Module Streams: Aktivierte Streams ohne Entsprechung unter RHEL 10 musst du vorher zurücksetzen, sonst bleibt der Paketstand hängen.
  • Python: Der System-Interpreter wechselt die Version. Jeder fest verdrahtete Shebang auf die RHEL-9-Version bricht, egal ob im eigenen Skript oder in einem Herstelleragenten.
  • Kryptorichtlinie: Systeme, die nur mit LEGACY laufen, laufen mit jedem Release schlechter. Prüfe vorher, welcher Dienst die Ausnahme braucht und warum.
Blocker gezielt suchen
sudo dnf module list --enabled
sudo dnf module reset <modulname>          # nur fuer Streams ohne Nachfolger

sudo update-crypto-policies --show
grep -rn '^#!.*python3\.9' /usr/local/bin /opt /srv /etc 2>/dev/null

# Fremd-Repos fuer den Upgradelauf bekannt machen
sudoedit /etc/leapp/files/leapp_upgrade_repositories.repo

In /etc/leapp/files/leapp_upgrade_repositories.repo trägst du die Zielrepos ein, die Leapp während des Upgrades zusätzlich verwenden soll. Ohne diesen Eintrag kennt Leapp die Herstellerpakete nicht und lässt sie entweder liegen oder blockiert.

05

Das Upgrade fahren

Der eigentliche Umbau passiert nicht im laufenden System, sondern nach dem Reboot in einem eigenen Upgrade-Initramfs. Genau deshalb ist der Konsolenzugang keine Empfehlung, sondern Voraussetzung.

Umschalten
sudo leapp upgrade --target 10.0
sudo reboot

# Der Host bootet in das Upgrade-Initramfs, tauscht dort die Pakete
# und startet danach ein zweites Mal neu. Verfolge das ueber die Konsole.

# Nach dem Hochkommen unter RHEL 10:
sudo tail -n 200 /var/log/leapp/leapp-upgrade.log

Zwischen den beiden Reboots gibt es keinen Netzwerkzugriff und keine Dienste. Wenn im Initramfs etwas hängt, siehst du das ausschließlich auf der Konsole.

06

Nacharbeit: erst prüfen, dann abhaken

Ein Host, der wieder pingt, ist noch kein fertiges Upgrade. Diese Prüfungen laufen direkt nach dem ersten Login unter RHEL 10.

Kontrolllauf nach dem Upgrade
cat /etc/redhat-release
uname -r
sestatus                                   # Enforcing, Relabel durchgelaufen?
sudo ausearch -m AVC -ts boot              # neue SELinux-Denials seit dem Start
systemctl --failed
rpm -qa | grep -E '\.el[89]\.' | sort     # Reste aus der alten Version
sudo dnf repolist enabled
sudo nft list ruleset | head -40

Die Zeile mit den el8- und el9-Resten ist die aussagekräftigste. Jedes Paket dort hat Leapp nicht ersetzen können, meistens sind es genau die Fremdpakete aus der Bestandsaufnahme. Entscheide pro Paket: ersetzen, entfernen oder bewusst behalten.

Abnahme

  • Jeden Dienst fachlich testen, nicht nur systemctl is-activeEin Dienst kann laufen und trotzdem falsch antworten, etwa weil eine TLS-Ciphersuite weggefallen ist. Ein echter Aufruf über den vorgesehenen Weg deckt das auf.
  • Backup- und Monitoring-Agenten neu verifizierenBeide gehören zu den Fremdpaketen und melden Ausfälle typischerweise still. Erst der nächste Restore-Versuch würde es sonst zeigen.
  • Zeit und Zertifikate prüfenchronyc tracking und ein Blick auf die Kryptorichtlinie fangen die Fälle ab, in denen Verbindungen nach dem Upgrade an der Signaturprüfung scheitern.
  • Inventar und Automatisierung nachziehenAnsible-Facts, CMDB und Patchgruppen zeigen sonst weiter RHEL 9. Falsche Inventardaten führen später zu falschen Wartungsplänen.
  • Snapshot erst nach der Freigabe löschenSolange der Rückweg steht, ist jede Überraschung beherrschbar. Nach der Freigabe muss er weg, weil er sonst dauerhaft I/O kostet.
Passende Kurse

Kurse zu Upgrade auf RHEL 10 bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

RHEL 10: Upgrade Training 3 Tage Präsenz nächster Termin 21.10.2026 Zum Kurs RH134 Red Hat System Administration II 5 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs RH199 Red Hat Certified System Administrator Rapid Track Course 5 Tage Live-Online nächster Termin 14.09.2026 Zum Kurs AU294 Red Hat Enterprise Linux Automation with Ansible 4 Tage Präsenz oder Live-Online nächster Termin 28.09.2026 Zum Kurs Linux Troubleshooting Training: Kritische Probleme beheben 3 Tage Präsenz nächster Termin 09.12.2026 Zum Kurs
Unverbindlich beraten lassen Alle Red-Hat-Kurse ansehen
Gut zu wissen

Häufige Fragen zu Upgrade auf RHEL 10

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Kann ich direkt von RHEL 8 auf RHEL 10 upgraden?
Nein, einen direkten Pfad von RHEL 8 auf RHEL 10 gibt es nicht. Du musst zuerst mit Leapp auf RHEL 9 wechseln, das System dort stabilisieren und aktualisieren und danach den zweiten Leapp-Lauf auf RHEL 10 fahren. Bei sehr alten, stark verbastelten Systemen ist ein Neuaufsetzen auf RHEL 10 mit anschließendem Ausrollen der Konfiguration über Ansible oft der schnellere und sauberere Weg.
Was ist der Unterschied zwischen leapp preupgrade und leapp upgrade?
leapp preupgrade analysiert das System nur und verändert nichts an der Installation. Es erzeugt einen Bericht mit Inhibitoren, Warnungen und Hinweisen, die du vorab abarbeiten kannst. Erst leapp upgrade lädt die neuen Pakete herunter und führt die eigentliche Transaktion aus, die nach einem Neustart in einer speziellen Upgrade-Initramfs abläuft.
Läuft meine Hardware überhaupt noch unter RHEL 10?
RHEL 10 setzt auf x86-64 eine CPU voraus, die dem Level x86-64-v3 entspricht, also unter anderem AVX2 beherrscht. Server mit älteren Prozessoren scheiden damit aus, unabhängig davon, wie gut sie unter RHEL 9 laufen. Leapp weist auf diese Voraussetzung hin, deshalb solltest du den Preupgrade-Lauf früh auch auf Altsystemen starten, um den Hardware-Bedarf für die Planung zu kennen.
Wie komme ich zurück, wenn das Upgrade schiefgeht?
Leapp selbst bietet keinen automatischen Rückweg, sobald die Transaktion durchgelaufen ist. Der Rückfall erfolgt über einen vorher gezogenen Snapshot der virtuellen Maschine oder des Storage-Systems, idealerweise bei heruntergefahrenem Gast, oder über ein vollständiges Restore aus dem Backup. Bei physischen Servern ohne Snapshot-Möglichkeit brauchst du ein getestetes Bare-Metal-Restore, sonst ist das Upgrade eine Einbahnstraße.
In-Place-Upgrade oder lieber neu installieren?
Ein In-Place-Upgrade lohnt sich bei Systemen mit viel lokalem Zustand, langer Historie und aufwendiger Anwendungskonfiguration. Neu installieren ist die bessere Wahl, wenn die Maschine ohnehin per Ansible oder Image reproduzierbar ist, wenn Altlasten aus mehreren Major-Versionen mitgeschleppt werden oder wenn du die Gelegenheit für ein sauberes Partitionslayout nutzen willst. In gemischten Landschaften fahren viele Teams beide Wege parallel und entscheiden pro Systemklasse.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Distributionen & Auswahl SUSE oder Red Hat: So legst du deinen Enterprise-Linux-Standard fest Ansehen Distributionen & Auswahl Ubuntu oder Debian auf dem Server: Was passt zu deiner Umgebung? Ansehen Distributionen & Auswahl Wie lange bekommt dein Linux noch Updates? Ansehen Distributionen & Auswahl RHEL, Rocky Linux oder AlmaLinux: Was trägt deine Serverlandschaft? Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
Guter Einstieg, der alle wichtigen Vokabeln aus dem Themenbereich erklärt, um "Fachchinesisch" zu verstehen und gleichzeitig Lust auf mehr Linux macht.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

Upgrade gemeinsam durchspielen statt im Wartungsfenster improvisieren

Im Seminar RHEL 10: Upgrade Training gehst du den kompletten Leapp-Ablauf an eigenen Systemen durch, vom Preupgrade-Report über typische Inhibitoren bis zur Nacharbeit nach dem Reboot. Wenn du deine Red-Hat-Basis vorher festigen willst, passen RH134 Red Hat System Administration II oder RH199 als Rapid-Track-Kurs, für das automatisierte Ausrollen danach RH294 Red Hat Enterprise Linux Automation with Ansible. Alle Kurse gibt es als Präsenz- und Live-Online-Termin, und wenn du unsicher bist, welcher Weg zu deiner Umgebung passt, sprich uns einfach an.

Beratung anfragen 0800 71 20000