RHEL 9 zu RHEL 10 mit Leapp — die Pre-Flight-Checks und die Stolperfallen, die wir treffen

In-Place-Major-Version-Upgrades auf RHEL sind jetzt echt nutzbar. Leapp übernimmt das meiste der schweren Arbeit: Pre-Flight-Inventar, Paket-Kompatibilitäts-Checks, Konfigurations-Migration, und die eigentliche Upgrade-Transaktion. Der erfolgreiche Pfad ist real und gut dokumentiert.

Der nicht-erfolgreiche Pfad ist ebenfalls gut dokumentiert, und das ist, wo das Engineering passiert. Dies ist der Leapp-Workflow, den wir auf Kunden-Flotten nutzen, und die Stolperfallen, die wir konsistent beim Wechsel von RHEL 9 zu RHEL 10 treffen.

Die Pre-Flight- + Upgrade-Sequenz

# Den Pre-Upgrade-Report aktivieren + ausführen
yum install -y leapp-upgrade
leapp preupgrade
 
# LESEN SIE /var/log/leapp/leapp-report.txt
# Jeden Inhibitor lösen, bevor Sie fortfahren
# (cgroups v1 → v2, deprecated Services, entfernte Pakete)
 
# Spezifische Inhibitors mit Antworten lösen
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
 
# Das eigentliche Upgrade ausführen
leapp upgrade
reboot   # Bootet in ein Upgrade-Mode-Initramfs und macht die Arbeit

Das Wichtigste: Lesen Sie den Pre-Upgrade-Report. Er sagt Ihnen genau, was brechen wird. Führen Sie leapp upgrade nicht aus, bis jeder Inhibitor entweder gelöst oder explizit anerkannt ist.

Der vollständige Beitrag behandelt:

• Das Pre-Flight-Inventar — was Leapp prüft und was es verpasst
• cgroups-v1- → -v2-Übergangs-Implikationen für containerisierte Workloads
• Python 3.9 → 3.12 — was entfernt wird und welcher Anwendungs-Code Updates braucht
• Die crypto-policies-Änderung (legacy → DEFAULT oder FUTURE)
• Custom-Kernel-Module, die das Upgrade nicht überleben
• Echte Post-Upgrade-Stolperfallen (Postgres, Apache, Nginx — Config-Syntax-Shifts)
• Wann wir Fresh-Installs über In-Place-Upgrades empfehlen

Wir fahren dieses Playbook bei jedem gemanagten RHEL-Flotten-Upgrade.