Planning an in-place major upgrade of RHEL with Leapp

Goal

Move a RHEL 8 host to RHEL 9, or a RHEL 9 host to RHEL 10, in place with Leapp, resolving everything that blocks it first.

Prerequisites

A full backup or a hypervisor/storage snapshot taken before running the actual upgrade step — Leapp modifies the running system's core packages, and a failed upgrade is not reliably reversible. The leapp-upgrade package for the target major version, registered repositories for both the current and target releases, and the target release's list of removed or deprecated components read in advance.

Steps

1. Run the assessment only, with nothing changed yet:

leapp preupgrade

This is Leapp's own dedicated subcommand for generating a preupgrade report, distinct from actually upgrading. 2. Read /var/log/leapp/leapp-report.txt. Findings are grouped by severity; Leapp's reporting model defines a dedicated inhibitor group specifically to mark findings that block the upgrade outright, separate from lower-severity warnings. 3. Where a finding asks for a decision — for example, confirming a third-party repository will be disabled during the upgrade — record the answer so it is not asked again on retry:

leapp answer --section <section>.confirm=True

Leapp persists recorded choices in its answerfile. 4. Resolve every inhibitor: remove or replace unsupported packages, drop incompatible kernel modules, fix repository conflicts. Re-run leapp preupgrade until the report shows none remaining. 5. Only then run the upgrade itself:

leapp upgrade

This stages an upgrade initramfs and reboots the host into it; expect at least one automatic reboot during the process. 6. After it returns, confirm the new major version and re-run your own service checks:

cat /etc/redhat-release

Expected result

The host boots on the target major version with installed packages migrated; the leapp-report.txt from the final preupgrade run and the upgrade log are retained for audit.

Limits and test basis

Leapp does not support every configuration — custom kernels, some layered products and certain storage or network layouts can produce an inhibitor whose correct response is to re-image rather than force past it. This is confirmed from the leapp and leapp-repository projects' own source (command definitions and the reporting API); no field success-rate is claimed, and the backup taken before step 5 is the actual rollback path if the upgrade fails partway.