Leapp pre-upgrade recovery point for RHEL in-place upgrade

Question

The goal is to define a recoverable state before running a Leapp in-place upgrade so the system can return to the previous release if the upgrade fails. Leapp performs an in-place transaction without a built-in rollback mechanism, and passing the pre-upgrade report does not guarantee a successful boot into the new release.

The uncertainty is the scope of the recovery point. A storage or LVM snapshot taken before the upgrade may not capture all runtime state, and Leapp behavior differs between version pairs such as RHEL 7 to 8 and RHEL 8 to 9. Custom kernel modules and third-party drivers may also be lost if they are not present in the target repositories.

Which system components must a pre-upgrade snapshot include to restore the previous RHEL release after a failed Leapp transaction? Is a storage-level snapshot sufficient, or must Leapp working data, bootloader state, and third-party modules be preserved separately? How does the required recovery scope change between RHEL version pairs?

Zoha · Answer

Recovery Point Requirements for Leapp RHEL Upgrades

A storage-level LVM snapshot is typically sufficient as the primary recovery mechanism, but it must explicitly include three critical components: the root filesystem (including /var/lib/leapp), the /boot partition (containing GRUB2 configuration and both old and new kernels), and all logical volumes used for system state. The snapshot does not need to capture /var/log/leapp for rollback purposes, though preserving it aids diagnostics.

Minimum Snapshot Scope

Root filesystem: Must contain /var/lib/leapp where Leapp stores transaction metadata and working data. Without this, package state cannot be restored.
/boot: Contains GRUB2 configuration (/boot/grub2), the previous kernel, initramfs, and bootloader entries. Missing this means the system may attempt to boot the new kernel on rollback.
All LVM logical volumes: If using LVM, the snapshot must cover every LV that contributes to system state, including /var if it contains Leapp data.

Third-Party Modules and Drivers
Custom kernel modules not present in the target release repository must be backed up separately. Copy /lib/modules/<kernel-version>/extra or the entire /lib/modules directory to external storage. These modules are not recoverable from standard package repositories and require manual restoration after rollback.

Version-Pair Differences
RHEL 7 to 8: The snapshot must preserve the legacy /etc/init.d compatibility files and the RHEL 7 kernel initramfs. If the system used SysV init scripts, these are essential for boot recovery.

RHEL 8 to 9: The scope is similar, but ensure compatibility packages for systemd were not removed before the upgrade. The bootloader layout changed between versions, so GRUB2 entries must reference the correct kernel version post-rollback.

Bootloader and Encryption Considerations
If using encrypted LVM or LUKS, the snapshot must capture keyslots and passphrase configuration. A snapshot taken after kernel installation but before first reboot may miss the previous kernel's initramfs if it was auto-removed. Verify both kernel versions exist in /boot before proceeding.

Verification Steps

Create a full LVM snapshot of the root volume and /boot.
From the snapshot environment, confirm GRUB entries point to the old kernel and /var/lib/leapp exists.
Load a custom kernel module from the snapshot to verify third-party drivers are preserved.
On a test system, perform a Leapp upgrade, then boot from the snapshot to confirm rollback success.

One missing diagnostic detail: Are you using encrypted LVM or LUKS on this system?

Leapp pre-upgrade recovery point for RHEL in-place upgrade