RHEL 9 vers RHEL 10 avec Leapp — les checks pre-flight et les pièges que nous rencontrons

Les upgrades de version majeure in-place sur RHEL sont maintenant réellement utilisables. Leapp fait l'essentiel du travail lourd : inventaire pre-flight, checks de compatibilité de packages, migration de configuration, et la transaction d'upgrade elle-même. Le chemin réussi est réel et bien documenté.

Le chemin non réussi est aussi bien documenté, et c'est là où l'ingénierie a lieu. Voici le workflow Leapp que nous utilisons sur les flottes clients, et les pièges que nous rencontrons systématiquement en passant de RHEL 9 à RHEL 10.

La séquence pre-flight + upgrade

# Activer + lancer le rapport pre-upgrade
yum install -y leapp-upgrade
leapp preupgrade
 
# LIRE /var/log/leapp/leapp-report.txt
# Résoudre chaque inhibitor avant de continuer
# (cgroups v1 → v2, services deprecated, packages supprimés)
 
# Résoudre des inhibitors spécifiques avec des réponses
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
 
# Lancer l'upgrade réel
leapp upgrade
reboot   # Boote dans un initramfs upgrade-mode et fait le travail

La chose la plus importante : lisez le rapport pre-upgrade. Il vous dira exactement ce qui va casser. Ne lancez pas leapp upgrade tant que chaque inhibitor n'est pas soit résolu, soit explicitement acquitté.

L'article complet couvre :

• L'inventaire pre-flight — ce que Leapp vérifie et ce qu'il rate
• Implications de la transition cgroups v1 → v2 pour les workloads containerisées
• Python 3.9 → 3.12 — ce qui est supprimé et ce que le code applicatif doit mettre à jour
• Le changement de crypto-policies (legacy → DEFAULT ou FUTURE)
• Modules kernel custom qui ne survivent pas à l'upgrade
• Pièges réels post-upgrade (Postgres, Apache, Nginx — shifts de syntaxe de config)
• Quand nous recommandons des fresh installs plutôt que des upgrades in-place

Nous faisons tourner ce playbook sur chaque upgrade de flotte RHEL managée.