RHEL 9 to RHEL 10 with Leapp — the pre-flight checks and the gotchas we hit

In-place major version upgrades on RHEL are now genuinely usable. Leapp does most of the heavy lifting: pre-flight inventory, package compatibility checks, configuration migration, and the actual upgrade transaction. The successful path is real and well-documented.

The unsuccessful path is also well-documented, and it's where the engineering happens. This is the Leapp workflow we use on customer fleets, and the gotchas we hit consistently going from RHEL 9 to RHEL 10.

The pre-flight + upgrade sequence

# Enable + run the pre-upgrade report
yum install -y leapp-upgrade
leapp preupgrade
 
# READ /var/log/leapp/leapp-report.txt
# Resolve every inhibitor before proceeding
# (cgroups v1 → v2, deprecated services, removed packages)
 
# Resolve specific inhibitors with answers
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
 
# Run the actual upgrade
leapp upgrade
reboot   # Boots into upgrade-mode initramfs and does the work

The single most important thing: read the pre-upgrade report. It will tell you exactly what's going to break. Don't run leapp upgrade until every inhibitor is either resolved or explicitly acknowledged.

The full write-up covers:

• The pre-flight inventory — what Leapp checks and what it misses
• cgroups v1 → v2 transition implications for containerized workloads
• Python 3.9 → 3.12 — what's removed and what application code needs updating
• The crypto-policies change (legacy → DEFAULT or FUTURE)
• Custom kernel modules that don't survive the upgrade
• Real post-upgrade gotchas (Postgres, Apache, Nginx config syntax shifts)
• When we recommend fresh installs over in-place upgrades

We run this playbook on every managed RHEL fleet upgrade.