0800 71 20000
Kontakt
...
Distributionen & Auswahl

RHEL 9 auf RHEL 10: Leapp-Report, Inhibitoren und Rollback

In-Place mit Leapp funktioniert bei sauber gepflegten Systemen zuverlässig, bei Hosts mit Fremdrepos und alten Python-Abhängigkeiten ist der Neuaufbau schneller. Entscheide das pro Host, nicht pauschal.

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 auf festgelegten Pfaden, Stand Oktober 2026 von RHEL 9.8 nach 10.2 oder von 9.6 mit EUS nach 10.0, 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. Modularität gibt es nicht mehr, Module Streams aus RHEL 9 haben keine direkte Entsprechung. Der X.org-Server ist entfallen, Python springt von 3.9 auf 3.12, und wer unter RHEL 9 noch mit iptables-Regeln oder SHA-1-Ausnahmen gearbeitet hat, muss spätestens jetzt auf nftables und aktuelle Kryptoverfahren umstellen. 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 unterstützt Leapp nur mit LUKS2 und Clevis-TPM-2.0-Token, netzwerkbasiertes Multipath und Storage über Ethernet oder InfiniBand gar nicht. Software-RAID und ungewöhnliche Bootloader-Konstellationen gelten ebenfalls 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 lösen, sonst hängt 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 prüfen, Leapp lädt sämtliche 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 unterstützt die CPU?
/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[0-9]'

# Gegenprobe über 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 unterstützt nur festgelegte Pfade, aktuell 9.8 nach 10.2 oder 9.6 mit EUS nach 10.0
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

# Zurück: im GRUB den boom-Eintrag wählen, 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 RHEL 9.8 (oder 9.6 mit EUS)
sudo dnf -y install leapp-upgrade
sudo leapp preupgrade --target 10.2         # von 9.6 EUS aus: --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.2        # nach jeder Änderung 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: RHEL 10 liefert keine modularen Inhalte mehr. Hast du unter RHEL 9 einen Stream wie nodejs:20 oder postgresql:16 aktiviert, prüf vorher, welche Version RHEL 10 als normales Paket mitbringt, und ob deine Anwendung damit läuft.
  • 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>          # RHEL 10 kennt keine Module mehr

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

# Fremd-Repos für 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.2
sudo reboot

# Der Host bootet in das Upgrade-Initramfs, tauscht dort die Pakete
# und startet danach ein zweites Mal neu. Verfolge das über 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. Du buchst sie in Präsenz oder Live-Online, auf Wunsch kommen sie auch als Inhouse-Schulung zu deinem Team.

RHEL 10: Upgrade Training 3 Tage Präsenz nächster Termin 13.01.2027 Zum Kurs RH134 Red Hat System Administration II 5 Tage Präsenz nächster Termin 30.11.2026 Zum Kurs RH199 Red Hat Certified System Administrator Rapid Track Course 5 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs AU294 Red Hat Enterprise Linux Automation with Ansible 4 Tage Präsenz oder Live-Online nächster Termin 23.11.2026 Zum Kurs Linux Troubleshooting Training: Kritische Probleme beheben 3 Tage Präsenz nächster Termin 09.12.2026 Zum Kurs

Weitere Kurse aus diesem Bereich

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle Linux-Schulungen mit Terminen.

Unverbindlich beraten lassen Alle Red-Hat-Kurse ansehen
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest LPI Essentials Quiz Teste dein Wissen zu Linux-Grundlagen mit unserem LPI Essentials Quiz. Finde heraus, welche Schulungen zu dir passen. Quiz starten Wissenstest LPIC-1 Quiz Teste dein Wissen für die LPIC-1 Prüfungen 101 und 102: Shell, Prozesse, Dateisysteme, Netzwerk und Sicherheit. Quiz starten
Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Gut zu wissen

Häufige Fragen zu Upgrade auf RHEL 10

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

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 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Distributionen & Auswahl SUSE oder Red Hat als Hausstandard für Enterprise Linux Weiterlesen Distributionen & Auswahl Ubuntu LTS oder Debian: Release-Zyklus, ESM und Paketalter Weiterlesen Distributionen & Auswahl Wie lange dein Linux noch Sicherheitsupdates bekommt Weiterlesen Distributionen & Auswahl RHEL, Rocky Linux oder AlmaLinux: was Binärkompatibilität heißt Weiterlesen

Passt thematisch dazu

Liegt auf dem Host eine Datenbank, wechselt mit dem Release auch deren Hauptversion, und dann kommt zum Leapp-Lauf noch der eigene Weg für das Datenverzeichnis einer PostgreSQL-Instanz .

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 AU294 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