Master the Migration: Upgrading Your RHEL Workload - Part 2

Upgrading Red Hat Enterprise Linux 9 to 10: A Practical Guide Using Leapp

Introduction

In Part 1, we upgraded RHEL 8 to RHEL 9 using Leapp. In this part, we will take it a step further: RHEL 9 to RHEL 10.

If your RHEL 9 system is working perfectly well, the obvious question will be why touch it? In this article I will cover why and when an upgrade matters, how to prepare, the exact commands I ran, and the problems I hit along the way and some best practice on doing upgrades of this sort.

A system that works today may not meet tomorrow’s security, hardware, software-vendor, or compliance requirements. An upgrade can bring a newer platform and keep an organization on a supported path. But upgrading a major operating system version is a planned change—not routine patching. It can affect applications, drivers, authentication, storage, and networking.

There is no need to upgrade just because a new major version exists. Consider moving to RHEL 10 when a vendor requires it, a needed capability is available only there, your hardware or platform roadmap depends on it, or support and compliance requirements make it necessary. If RHEL 9 continues to meet your needs, keep it patched and plan the move according to your organization’s lifecycle requirements.

Why Upgrade from RHEL 9 to RHEL 10?

"It is brand new and works" is a good reason to be careful. It is not a lifecycle strategy. RHEL 9 is not going away tonight, but the cost of staying put grows quietly.

Lifecycle runway. RHEL 9 is well supported today, but it moves from full support into maintenance support earlier than RHEL 10 does. Moving on your own schedule is cheaper than doing it in a hurry. Always confirm current dates on the Red Hat lifecycle page.

Security and cryptography. RHEL 10 ships newer defaults and a stricter crypto baseline, including groundwork for post-quantum cryptography. Adopting this once is easier than retrofitting later. An upgrade alone does not make you compliant, so review your policies afterwards.

Newer kernel, toolchain and hardware support. A newer kernel, compilers and language runtimes, plus better support for current hardware.

Vendor alignment. ISVs and hardware vendors certify the newest release first and eventually stop testing on the oldest.

A path to image mode. RHEL 10 continues the move toward image-based operating systems with bootc, which we will explore in the Part 3 of this series.

When is upgrading important?

• A vendor or ISV application requires RHEL 10.
• New hardware or drivers are only supported on RHEL 10.
• A compliance or audit requirement demands a newer cryptographic baseline.
• Your RHEL 9 system is approaching the end of full support and you want to avoid a rushed migration.
• You are skipping a generation of drift. Moving one major version at a time is far safer than waiting until you are two behind.

If none of these apply, staying on RHEL 9 is a legitimate decision. Upgrade where you gain something concrete.

Understanding the Risks Before Upgrading

The principles from Part 1 still apply: test on a staging system, take a verified backup, keep console access, and involve application owners. Two things are specific to RHEL 10:

CPU baseline. RHEL 10 requires an x86-64-v3 capable CPU (roughly Haswell or newer). On older hardware, or VMs with a restrictive CPU model, RHEL 10 will not run. Check before anything else.

/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[234]'

Look for x86-64-v3 (supported, searched).

Removed and changed features. 32-bit support is gone, some legacy components have been removed, and the crypto defaults are stricter. Test old integrations (legacy TLS, SHA-1, older SSH clients) before you upgrade production.

Confirm the Supported Upgrade Path

Leapp supports specific source and target minor releases. In my case the target was RHEL 10.2 from RHEL 9.8. Ensure you Update the source system to the latest RHEL 9 minor release supported for that target, and check Red Hat's documentation for the current supported paths before you start.

Also confirm architecture (this exercise is x86_64), a valid subscription or repository source, free space in /var, /var/lib/leapp, /boot, / and /usr, console access (iDRAC, iLO or hypervisor), and a backup you have tested.

Pre-Upgrade Planning Checklist

Before: As discussed in the first part of this series, test in staging, notify application owners, validate compatibility, get change approval, take and verify a backup or snapshot, update to the latest RHEL 9 supported version for migration, check subscription and repositories, review third-party repos and packages, and document services, mounts for sufficient space, nfs mount-points and special security settings on the /var directory etc and network settings.

During: run the pre-upgrade assessment, resolve every inhibitor, review warnings and resolve them, monitor from the console, keep the recovery plan open.

After: verify release and kernel, SELinux mode, networking, DNS, authentication, services, applications, monitoring and logging.

Prepare the RHEL 9 System

Confirm the current release and inspect the subscription:

cat /etc/redhat-release
subscription-manager status

If the system is not registered, register it according to your organization’s subscription process. Do not register a Satellite-managed system against a different content source without coordinating with the Satellite administrator.

subscription-manager register 

Note: Red Hat offers a no-cost Developer Subscription for individuals that lets you register up to 16 systems for development, testing and learning. Organizations can use same for Teams, which covers up to 25 systems per subscription. Neither subscription may be used for production workloads. Check Red Hat's current terms before relying on these limits.

Update the system and reboot into the latest kernel:

dnf update -y
reboot

After it comes back, confirm the release, running kernel, and service health before continuing.

If you have done a previous upgrade from RHEL 8 to 9, remove the old Leapp packages from the earlier upgrade:

dnf remove leapp-upgrade-el8toel9 leapp-data-rhel-el8toel9 -y

Clean up leftovers from the previous upgrade

This is the part that is easy to miss. My server had already been upgraded from RHEL 8, and old packages and files can stay behind and confuse Leapp. Remove the leftover EL8 kernels and any remaining EL7/EL8 packages. Leaving some of these behind might not allow your upgrade proceed. Also remove the /etc/leapp/repos.d/system_upgrade/el8toel9/ folder which contains some files leapp might wrongly reference:

dnf remove $(rpm -qa 'kernel*' | grep '\.el8')
sudo dnf remove -y $(rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)')
rm -rf /etc/leapp/repos.d/system_upgrade/el8toel9/

⚠️ Be careful with these.

• rm -rf /etc/leapp/repos.d/system_upgrade/el8toel9/ is relative, so run it only from the directory that actually holds the leftover, or use the full path.
• The two dnf remove commands remove every installed package matching .el7 or .el8. Review the list first with rpm -qa | grep -e '\.el[78]' | sort, and check rpm -qa 'kernel*' | grep '\.el8' before removing kernels. Never remove the kernel you are running.

Install the Latest Leapp

First, check whether any dnf excludes would block the Leapp packages:

dnf config-manager --dump | grep -i exclude

Install the Leapp packages available from the configured and supported repositories:

dnf install 'leapp-*'

On my system, the framework package required by the upgrade repository was hidden by DNF’s exclude configuration. The install reported that python3-leapp was filtered out. Disabling exclusions allowed DNF to see the required provider:

dnf install 'leapp-*' --disableexcludes=all

Use --disableexcludes=all only after reviewing the exclusions and the transaction. It overrides exclusions for that command; it does not remove the exclusion from the DNF configuration.

Fix stale Leapp repository files (my biggest surprise)

On my server, leapp preupgrade failed before it analysed anything, with these errors:

Error: Undefined Model "MultipathConfFacts8to9Reference"

The cause was stale, unowned files left in /usr/share/leapp-repository from an earlier Leapp version. dnf reinstall only overwrites the files an RPM ships. It never deletes extras, so old actors kept loading next to the new ones. You can spot them with rpm -qf /usr/share/leapp-repository, which reports "not owned by any package". The fix is to move the whole directory aside and let the RPMs rebuild it:

mv /usr/share/leapp-repository /root/leapp-repository.bak
dnf reinstall -y leapp-upgrade-el9toel10 leapp-upgrade-el9toel10-deps leapp-upgrade-el9toel10-fapolicyd

If your server has no stale files, you will not see these errors. It is still a cheap, safe step on any system that has been through a previous Leapp upgrade, because the backup stays in /root.

Run the Pre-Upgrade Assessment

leapp preupgrade

Then read the report:

less /var/log/leapp/leapp-report.txt

Fix every inhibitor, then run leapp preupgrade again until none remain. Here are the findings I hit.

A. Legacy network configuration

Leapp flagged the old ifcfg network scripts. As in Part 1, NetworkManager can migrate them. Replace ifcfg-ens160 with your own profile, and keep console access open:

nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-ens160

B. GRUB2 core will be updated (informational)

On BIOS systems, Leapp reports that it will run grub2-install after the RPM transaction. This is a warning, not an inhibitor. It is still wise to back up /boot/grub2 and the MBR gap first, and to check the GRUB configuration after the upgrade, especially on a hardened system. Backup your /boot drive if you feel unsafe.

Execute the In-Place Upgrade

When the report shows no inhibitors, the backup is verified and console access is ready, start the upgrade:

leapp upgrade --reboot

The --reboot option reboots the system automatically into the upgrade environment once the preparation phase is done. The server then boots, performs the package migration, and reboots again into the RHEL 10 kernel. Run it in tmux or screen to ensure you regain connectivity assuming you loose it.

What happens during the upgrade

1. Transaction preparation: Leapp calculates the packages required for the target release.
2. Upgrade environment preparation: a dedicated boot environment is built.
3. Package migration: the system packages are replaced by their RHEL 10 versions.
4. Reboot and finalization: the system boots into RHEL 10 kernel. On BIOS systems this includes the grub2-install step.

In some of the upgrades I did, I ran into a situation where even though the upgrade went thru, the system went into grub rescue mode. Which required me to reinstall grub with a rescue disk and things came back alright.

If the upgrade does not complete, start with the logs:

less /var/log/leapp/leapp-upgrade.log
less /run/initramfs/rdsosreport.txt
journalctl -b -1

Verify the Upgraded System

cat /etc/redhat-release
uname -r
systemctl --failed
journalctl -p err -b
grubby --default-kernel
cat /proc/cmdline

Validate the parts of the system the workload depends on:

• Network interfaces, routes, DNS, and remote access
• Storage mounts and multipath, where applicable, remount them
• Authentication and authorization
• SELinux mode and security policy
• Application services, databases, and scheduled jobs
• Monitoring, logging, backups, and security agents
• Monitoring, logging, backups, and security agents
• Run compliance reports on the server to be sure it meets your organisational needs

Work with the application owners to confirm that the business service functions correctly. A successful boot is not, by itself, proof that the workload is healthy.

Post-Upgrade Cleanup

As in Part 1, remove the old kernels and leftovers once the new system is validated, this time for RHEL 9:

uname -r
rpm -qa 'kernel*' | grep '\.el9'
rpm -qa | grep -e '\.el[789]' | sort

Review the output carefully before removing anything with dnf remove. Also restore anything you changed temporarily (crypto policy, disabled services, monitoring), and remove the backup directories such as /root/leapp-repository.bak once you are satisfied.

Rollback

Leapp has no built-in uninstall as discussed earlier. Your rollback is the backup or snapshot you prepared: revert the VM snapshot or restore the ReaR or backup image. Decide in advance what your "point of no return" is, for example "if the application is not healthy within 60 minutes of the reboot, revert".

Final Lessons and Recommendations

1. Check the hardware first. The x86-64-v3 requirement is a hard stop on older CPUs.
2. Clean up previous upgrades. Leftover packages and Leapp files from an earlier migration are a real source of errors.
3. dnf reinstall does not delete extras. If Leapp fails with model or dependency errors, look for unowned files with rpm -qfand remove them
4. Keep console access and a tested backup. Always do these. You also want to use screen if you are working remotely.
5. Follow the official RedHat documentation for your exact source release, target release and architecture.

Conclusion

Upgrading from RHEL 9 to RHEL 10 is worth doing where there is a real reason: vendor support, new hardware, a stronger crypto baseline, or avoiding a rushed migration later. It is not worth doing just because a new release exists. Leapp makes the in-place path manageable, but the preparation, the pre-upgrade report and the cleanup of earlier upgrades decide whether it goes smoothly.

Next in this series: we move beyond in-place upgrades and look at fresh installs and Image Mode with bootc.