In this tutorial, you’ll learn how to upgrade RHEL 8 to RHEL 9 using the LEAPP tool with Red Hat Satellite Server integration. Staying up to date with the latest RHEL version ensures your systems benefit from enhanced security, improved performance, and access to new enterprise-grade features.
Table of Contents
Upgrade RHEL 8 to RHEL 9 using LEAPP
Prerequisites for Upgrading RHEL OS
- Backup Your Data: Always start with a full backup of your system to prevent data loss in case of any issues during the upgrade. This can even include taking a snapshot of the current system state. Anything can go wrong with the upgrade (refer to Murphy’s law) and you should be able to recover your system.
- Subscription Access: Verify that your Red Hat subscription is active and provides access to required RHEL repositories.
- System Requirements : Confirm you have enough free storage space for both the root filesystem and boot partition. Remember, enough is used relatively here. But ideally you should have at least 2-4 GB of free disk space available on your primary partition. The preupgrade report may show the requirements.
- Ensure correct paths for critical shared libraries before an OS upgrade. Before upgrading an OS, it is critical to verify system-managed shared libraries paths are correct. Misconfigured paths, especially for fundamental libraries like OpenSSL, glibc, and ld.so, can lead to severe failures, including a kernel panic.
What is LEAPP on RHEL?
Leapp is the official Red Hat Enterprise Linux (RHEL) upgrade framework designed to automate in-place upgrades from one major version of RHEL to another (e.g. RHEL 8 to RHEL 9). Leapp helps administrators migrate their systems safely while minimizing downtime and reducing the risk of breaking critical applications.
You maybe asking yourself, but what does LEAPP stands for? Well, as per Vinzenz:
Understanding System Updates vs Upgrades
Before diving into the process, it’s essential to understand the difference between updates and upgrades:
- Update : An update refers to applying patches, bug fixes, or minor improvements within the same major version. For example, updating RHEL 8.8 to RHEL 8.10.
- Upgrade : An upgrade involves moving to a newer major version of the operating system. In this case, we are upgrading from RHEL 8.8 to RHEL 9.6.
Upgrades often include significant changes that may affect system configurations, software compatibility, and hardware support. Therefore, proper planning and testing are crucial before proceeding.
Types of RHEL OS Upgrade
There are two primary methods for performing an OS upgrade:
- In-Place Upgrade (recommended) : This method upgrades the existing installation without erasing data or requiring a fresh setup. It retains user settings, applications, and configurations while replacing core components with those of the new version. Leapp facilitates in-place upgrades by analyzing dependencies and resolving conflicts automatically.
- Clean Install : A clean install involves wiping out the current OS and installing the new version from scratch. While this approach ensures a pristine environment free of legacy issues, it requires reconfiguring the system and reinstalling all necessary software.
For most users, especially in production environments, an in-place upgrade is preferred due to minimal downtime and preserved configurations.
Supported RHEL In-Place Upgrade Paths
Red Hat officially supports in-place upgrades between specific RHEL versions using Leapp. The screenshot chart below shows the currently supported planned upgrade paths for RHEL 8.x to RHEL 9.x:
In-place upgrades with Leapp allow you to move from one major RHEL version (e.g., 8 to 9) without a full reinstall. However, upgrades are only supported between specific minor version pairs that Red Hat has tested and certified. This means you can’t upgrade from just any RHEL 8.x to any RHEL 9.x, only certain combinations are supported.
The chart above illustrates these valid upgrade paths, each represented as a row linking an RHEL 8 minor version (like 8.8, 8.9, or 8.10) to a supported RHEL 9 target (such as 9.2, 9.3, etc.). Alongside each pair, the chart includes:
- Minor Release (Blue Bar): The date when support for the upgrade path was introduced, with each RHEL minor version typically supported as a source for approximately 6 months until the next minor release. This includes odd-numbered releases (e.g., 8.1, 8.3, 8.5, 8.7, 8.9; 9.1, 9.3, 9.5, 9.7), which are fully supported during this initial period.
- Extended Update Support (Light Blue Bar): The support period for the target RHEL version (e.g., RHEL 9 in this chart), lasting up to 24 months (or 48 months with Enhanced EUS for select versions) from its release date, during which required packages and repositories are maintained. This extended support applies to even-numbered releases (e.g., 8.2, 8.4, 8.6, 8.8, 8.10; 9.0, 9.2, 9.4, 9.6), which are eligible for Extended Update Support (EUS), while odd-numbered releases are not, affecting their longevity as upgrade sources.
The chart reflects Red Hat’s release strategy since 2023. Over time, newer RHEL 8 versions support newer RHEL 9 targets and offer longer support windows, a pattern that resembles a staircase as support builds upward. As of August 2025, earlier paths (like 8.8 to 9.2) have expired, and Red Hat’s policy now supports upgrades only from the latest 8.x release (currently 8.10).
If you’re on an older minor version (e.g., 8.8), you must first patch it to RHEL 8.10 using dnf update. This step doesn’t require Leapp. Only then can you perform the major version upgrade.
As of mid-2025, the supported Leapp upgrade paths include:
- RHEL 8.10 to RHEL 9.4 (with Extended Update Support)
- RHEL 8.10 to RHEL 9.6 (latest general release as of May 2025)
While it is technically possible to perform an in-place upgrade from RHEL 8.8 to 9.2 using the Leapp utility as of late August 2025, this path is not officially supported by Red Hat. Although the upgrade may succeed under certain conditions (e.g., aligned package dependencies and no major conflicts), Red Hat ended Extended Update Support (EUS) for both 8.8 and 9.2 on May 31, 2025. As a result, official support, including assistance with issues, patches, or updates, is not available for this combination.
For the most current supported paths, always refer to Red Hat’s official documentation.
Determine your Content Access Mechanism
Before starting the upgrade process, you need to decide how your system will access the required content for the upgrade. This decision determines whether you’ll pull content directly from Red Hat’s Content Delivery Network (CDN) or use a Red Hat Satellite server for centralized management.
Using Red Hat CDN Repositories:
- This mechanism is ideal for standalone systems or smaller environments with direct internet access. To proceed with this method;
- Register your system directly with the Red Hat CDN.
- Enable the necessary repositories.
Register your system:
sudo subscription-manager registerProvide your Red Hat account username and password when prompted.
Check status of your subscription:
sudo subscription-manager status+-------------------------------------------+
System Status Details
+-------------------------------------------+
Overall Status: Disabled
Content Access Mode is set to Simple Content Access. This host has access to content, regardless of subscription status.
System Purpose Status: Disabled
As shown, the content access mode is configured as Simple Content Access (SCA), allowing systems to retrieve Red Hat repositories without requiring individual system subscriptions.
Check enabled repos;
sudo subscription-manager repos --list-enabled+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: rhel-8-for-x86_64-appstream-rpms
Repo Name: Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/appstream/os
Enabled: 1
Repo ID: rhel-8-for-x86_64-baseos-rpms
Repo Name: Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/baseos/os
Enabled: 1
From the command output above, only the RHEL 8 BaseOS and AppStream repositories are enabled, which is sufficient to perform updates and upgrades when connecting directly to Red Hat CDN repositories. To manually enable these repositories, use the following command::
sudo subscription-manager repos \
--enable rhel-8-for-x86_64-baseos-rpms \
--enable rhel-8-for-x86_64-appstream-rpms
Using Red Hat Satellite:
- Best suited for enterprise environments where content is managed centrally.
- Enable required repositories for source and target OS versions in Satellite.
- Sync repositories to download and store packages/content in Satellite.
- Create Content Views (CVs/CCVs) with the synced repos and publish them.
- Create activation keys linked to the appropriate Content Views and lifecycle environments.
- Register systems to Satellite using the activation key.
In this guide, we’ll use Red Hat Satellite to manage repositories and updates rather than connecting directly to the Red Hat CDN.
Create Content Views and Activation Keys
To run the LEAPP upgrade via the Satellite, navigate to Satellite, create content view and the associated activation key for the LEAPP upgrade.
Refer to the above Note and check the next links on how to create content views and associated activation keys:
- Enable Required Red Hat Repositories
- Create Red Hat Repositories Sync Plans
- Application Lifecycle Management
- Creating Content Views in Red Hat Satellite
- Create Satellite Activation Keys
Sample activation key with relevant repositories:
Register RHEL OS to Satellite
Next, register the RHEL system to Satellite server. Read more on how to register the host on Satellite by following the link below.
Register RHEL Hosts to Satellite Server
Note that registration is two way depending on the task:
- For initial updates (e.g., patching RHEL 8): Subscribe with an Activation Key (AK) that includes only the RHEL 8 repositories (e.g., RHEL 8 BaseOS and AppStream for the specific minor version like 8.8 or 8.10). This ensures the system receives the latest updates within its current major version.
- For the Leapp in-place upgrade (e.g., from 8.10 to 9.6 or 8.8 to 9.2): Use an Activation Key configured with a Content View like rhel8_leapp, which contains both RHEL 8.x (source) and RHEL 9.x (target) minor version repositories (e.g., 8.10 BaseOS/AppStream and 9.6 BaseOS/AppStream, or 8.8 and 9.2). This provides the necessary packages for the upgrade.
Upgrade RHEL 8 to RHEL 9 Using Leapp
Before starting the upgrade process, ensure all necessary prerequisites are met!
Remove Explicit OS Release Version Lock
If you had previously explicitly lock your system to a specific minor version of RHEL, you need to unlock it so that it is able to receive updates or upgrades to the latest available version.
You can check if the lock is defined;
sudo subscription-manager release --showThen empty the contents of the release version variable file using the command:
> /etc/yum/vars/releaserver> /etc/dnf/vars/releaseverOr:
sudo subscription-manager release --unsetStop Critical Applications/Services
If there is any critical applications/services running on you host, stop them and disable them from starting on system boot. Replace <SERVICE-NAME> accordingly.
sudo systemctl disable --now <SERVICE-NAME>Clear DNF Version Locks Before Upgrade
If you use the dnf versionlock plugin to lock packages to specific versions, clear these locks to prevent conflicts during the OS upgrade:
sudo dnf versionlock clearThis ensures all packages can be updated freely to newer versions as required by the upgrade process.
Unmount and Comment Out Non-System File Systems
Before performing an OS upgrade, it’s best practice to unmount and temporarily disable non-system file systems that aren’t required for the upgrade. This helps:
- Reduce upgrade time
- Prevent delays caused by network-related mounts
- Avoid issues with third-party or custom-mounted storage
Examples of Non-System File Systems:
- Network file systems:
NFS,CIFS/SMB,SSHFS,GlusterFS,CephFS - External or secondary drives mounted for data
- Custom mount points unrelated to the OS (e.g.,
/mnt/storage,/data,/backup,/media/nas)
Run the command below to check mounted filesystem:
df -hTIf you have an NFS mount at /mnt/teamdata for example:
sudo umount /mnt/teamdataIf you get a “device is busy” error:
sudo umount -l /mnt/teamdata-l performs a lazy unmount, detaching the filesystem immediately and cleaning up after it’s no longer in use.
Next, to prevent the filesystem from auto-mounting on reboot during the upgrade, comment out the entry in FSTAB:
sudo sed -i '/nfs/s/^/#/' /etc/fstabThis command comments out all lines in /etc/fstab that include “nfs”. Adjust the keyword (e.g., cifs, sshfs) as needed for other types.
Do I Need to Disable SELinux for a Leapp Upgrade?
No, you do not need to disable SELinux manually when performing a Leapp-based OS upgrade. The Leapp utility is designed to handle SELinux automatically:
- During the upgrade, Leapp temporarily switches SELinux to permissive mode to prevent enforcement-related issues.
- This change is made dynamically and does not require manual intervention.
- Post-upgrade, manually switch SELinux back to enforcing mode and persist that setting across reboots
Verify Subscription and Repository Configuration
Ensure your system is properly subscribed and has the correct repositories enabled.
sudo subscription-manager statusThis confirms whether your system has a valid Red Hat subscription.
+-------------------------------------------+
System Status Details
+-------------------------------------------+
Overall Status: Registered
Content Access Mode is set to Simple Content Access. This host has access to content, regardless of subscription status.Make sure the correct repositories for your current RHEL version (e.g., RHEL 8) are enabled;
sudo dnf repolistUpdating Subscription Management repositories.
repo id repo name
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)If repos are not enabled, counter check your registration steps.
Update RHEL OS to the Required Minor Version
Before initiating the RHEL 8 upgrade to RHEL 9, it’s crucial to update your RHEL 8 system to the appropriate minor version. See upgrade path section above.
For example, my node is currently on minor version of RHEL 8 (8.8);
cat /etc/redhat-releaseRed Hat Enterprise Linux release 8.8 (Ootpa)So, for me to upgrade to 9.x, the OS minor version must be 8.10.
Hence, update your system to the latest minor version.
sudo dnf update -yReboot the OS after the update.
sudo rebootVerify the updated version:
cat /etc/redhat-releaseRed Hat Enterprise Linux release 8.10 (Ootpa)Once your system is updated to the appropriate minor version, proceed to the next step.
Install RHEL LEAPP Utility on RHEL 8
Run the command below to install LEAPP utility.
sudo dnf install leapp-upgrade -yRe-Subscribe the System Using the Leapp Activation Key
Re-subscribe it using the appropriate Leapp activation key.
sudo subscription-manager register --org "ORG_LABEL" --activationkey <AK> --forceE.g.
sudo subscription-manager register --org "Kifarunix IT" --activationkey rhel8_leapp --forceRun Pre-upgrade Analysis
Run the Leapp preupgrade tool to analyze your system and identify potential issues:
sudo su -leapp preupgradeThe command will target the latest release version of RHEL 9.
If you want to go to a specific RHEL 9 minor release version, then specify. For example to go to RHEL 9.4 instead of the latest RHEL 9.6;
leapp preupgrade --target 9.4Watch the values of inhibitors and errors on the report.
Sample output report;
Debug output written to /var/log/leapp/leapp-preupgrade.log
============================================================
REPORT OVERVIEW
============================================================
Upgrade has been inhibited due to the following problems:
1. Firewalld Configuration AllowZoneDrifting Is Unsupported
2. Possible problems with remote login using root account
HIGH and MEDIUM severity reports:
1. GRUB2 core will be automatically updated during the upgrade
2. Remote root logins globally allowed using password
3. Leapp detected loaded kernel drivers which are no longer maintained in RHEL 9.
Reports summary:
Errors: 0
Inhibitors: 2
HIGH severity reports: 3
MEDIUM severity reports: 0
LOW severity reports: 0
INFO severity reports: 3
Before continuing, review the full report below for details about discovered problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
From the report, 2 inhibitors which is critical issues that must be resolved before proceeding, were found.
The report is written to, /var/log/leapp/leapp-report.txt.
You can open the report file to check suggested remediations to identified issues
Sample remediations:
Risk Factor: high (inhibitor)
Title: Firewalld Configuration AllowZoneDrifting Is Unsupported
Summary: Firewalld has enabled configuration option "AllowZoneDrifiting" which has been removed in RHEL-9. New behavior is as if "AllowZoneDrifiting" was set to "no".
Related links:
- Changes in firewalld related to Zone Drifting: https://access.redhat.com/articles/4855631
- Leapp Preupgrade check fails with error - "Inhibitor: Firewalld Configuration AllowZoneDrifting Is Unsupported".: https://access.redhat.com/solutions/6969130
Remediation: [hint] Set AllowZoneDrifting=no in /etc/firewalld/firewalld.conf
[command] sed -i s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/ /etc/firewalld/firewalld.conf
Key: 5b1cf050e1a877b0358b6e8c612277c591d40c13
----------------------------------------
Risk Factor: high (inhibitor)
Title: Possible problems with remote login using root account
Summary: OpenSSH configuration file will get updated to RHEL9 version, no longer allowing root login with password. It is a good practice to use non-root administrative user and non-password authentications, but if you rely on the remote root login, this change can lock you out of this system.
Related links:
- Why Leapp Preupgrade for RHEL 8 to 9 getting "Possible problems with remote login using root account" ?: https://access.redhat.com/solutions/7003083
Remediation: [hint] If you depend on remote root logins using passwords, consider setting up a different user for remote administration or adding a comment into the sshd_config next to the "PermitRootLogin yes" directive to prevent rpm replacing it during the upgrade.
Key: 3d21e8cc9e1c09dc60429de7716165787e99515f
----------------------------------------
So, to fix the inhibitor “Firewalld Configuration AllowZoneDrifting Is Unsupported“, run the provided command.
sed -i s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/ /etc/firewalld/firewalld.confTo fix the inhibitor “Possible problems with remote login using root account“. Just disable root login on SSHD_CONFIG file. If you do not have any other user for login, just add the user into the system and give it sudo privileges.
sed -i '/^PermitRootLogin/s/yes/no/' /etc/ssh/sshd_configsystemctl reload sshdReports will vary. As such, fix your identified issues and rerun the preupgrade check.
leapp preupgradeYou can only proceed with upgrade when you have 0 errors and 0 inhibitors.
Sample output finally;
Debug output written to /var/log/leapp/leapp-preupgrade.log
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. GRUB2 core will be automatically updated during the upgrade
2. Leapp detected loaded kernel drivers which are no longer maintained in RHEL 9.
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 0
LOW severity reports: 2
INFO severity reports: 4
Before continuing, review the full report below for details about discovered problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
Upgrade from RHEL 8 to RHEL 9
Once all inhibitors from the pre-upgrade analysis are resolved, you’re ready to upgrade.
sudo leapp upgradeThis will take the OS to the latest minor release version, e.g RHEL 9.6.
To specify the target:
sudo leapp upgrade --target 9.4If all goes well and there is no error/inhibitor detected, you should get an output confirming the same;
====> * add_upgrade_boot_entry
Add new boot entry for Leapp provided initramfs.
A reboot is required to continue. Please reboot your system.
Debug output written to /var/log/leapp/leapp-upgrade.log
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. GRUB2 core will be automatically updated during the upgrade
2. Leapp detected loaded kernel drivers which are no longer maintained in RHEL 9.
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 0
LOW severity reports: 2
INFO severity reports: 4
Before continuing, review the full report below for details about discovered problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
Reboot the system to continue with the upgrade. This might take a while depending on the system configuration.
Make sure you have console access to view the actual upgrade process.
You will also see a message asking you to reboot the OS:
Reboot the system to continue with the upgrade. This might take a while depending on the system configuration.
Make sure you have console access to view the actual upgrade process.Before you can proceed, access the VM/Server console and then issue a reboot.
sudo rebootYou can alternatively run the leapp upgrade command with the --reboot option to skip this manual step.
From the console, you will see that the system boots into a RHEL 9-based initial RAM disk image, initramfs.
Leapp will then upgrades all the packages and automatically reboots to the RHEL 9 system.
Post-Upgrade Verification for RHEL 9
After completing the in-place upgrade and logging into RHEL 9, verify the system is in the expected state:
Basic System Checks
Confirm OS version:
cat /etc/redhat-releaseExample output:
Red Hat Enterprise Linux release 9.6 (Plow)Check kernel version:
uname -r5.14.0-570.37.1.el9_6.x86_64Ensure it includes .el9 and is 5.14.0 or newer.
Subscription Validation
Check installed product:
sudo subscription-manager list --installedConfirm it’s RHEL 9.
+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Enterprise Linux for x86_64
Product ID: 479
Version: 9.6
Arch: x86_64
Verify release version:
sudo subscription-manager releaseOutput should match the target version (e.g., 9.6).
You can unset the release version:
sudo subscription-manager release --unsetNetwork and Application Status
Confirm network services are working (e.g., test SSH connectivity).
Check applications and services some may require manual migration or reconfiguration post-upgrade.
Remove Excluded Packages from DNF Configuration
Clear any remaining excluded packages that were set during the upgrade process:
sudo dnf config-manager --save --setopt exclude=''Remove Legacy RHEL 7/8 Packages
Check for any remaining .el7 or .el8 packages:
rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sortSample output;
iptstate-2.2.6-6.el8.x86_64
jimtcl-0.77-6.el8.x86_64
kernel-4.18.0-477.27.1.el8_8.x86_64
kernel-4.18.0-553.71.1.el8_10.x86_64
kernel-core-4.18.0-477.27.1.el8_8.x86_64
kernel-core-4.18.0-553.71.1.el8_10.x86_64
kernel-modules-4.18.0-477.27.1.el8_8.x86_64
kernel-modules-4.18.0-553.71.1.el8_10.x86_64
leapp-0.19.0-1.el8_10.noarch
leapp-upgrade-el8toel9-0.22.0-1.el8_10.noarch
libmodman-2.0.1-17.el8.x86_64
python3-leapp-0.19.0-1.el8_10.noarch
If the list looks clean and safe to remove, proceed:
sudo dnf remove $(rpm -qa | grep \.el[78] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')Otherwise, if you want to keep a specific package, simply add them to the exclusion list in the grep -vE pattern.
Remove Leapp-Specific Packages and Temporary Data
Clean up Leapp tools and temporary files:
sudo dnf remove leapp-deps-el9 leapp-repository-deps-el9 -ysudo rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leappRebuild the Rescue Kernel for RHEL 9
Remove outdated rescue kernels:
sudo rm -rf /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*Recreate the rescue kernel for the current RHEL 9 kernel:
sudo /usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"Verify the rescue images:
sudo ls -1 /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*/boot/initramfs-0-rescue-9827a8a19c2e4726956984510292fbe8.img
/boot/vmlinuz-0-rescue-9827a8a19c2e4726956984510292fbe8sudo lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"- If the output is
OK, then the rescue initramfs image includes the current kernel and is correctly set up for recovery. - If the output is
FAIL, then the rescue image does not include the current kernel. In this case, you should recreate the rescue image.
Confirm and Clean Bootloader Entries
Check the rescue boot entry and make sure it points to the correct kernel:
sudo grubby --info $(ls /boot/vmlinuz-*rescue*)Sample output;
index=1
kernel="/boot/vmlinuz-0-rescue-9827a8a19c2e4726956984510292fbe8"
args="ro resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M $tuned_params net.naming-scheme=rhel-8.0"
root="/dev/mapper/rhel-root"
initrd="/boot/initramfs-0-rescue-9827a8a19c2e4726956984510292fbe8.img $tuned_initrd"
title="Red Hat Enterprise Linux (0-rescue-9827a8a19c2e4726956984510292fbe8) 9.6 (Plow)"
id="9827a8a19c2e4726956984510292fbe8-0-rescue"
Verify no RHEL 7 or RHEL 8 kernels remain:
sudo grubby --info=ALL | grep -E "\.el7|\.el8" || echo "Old kernels are not present in the boot loader."Sample output when no old kernels are available:
Old kernels are not present in the boot loader.If any old entries exist (e.g., from RHEL 7 or 8), remove them. Replace the path accordingly:
sudo grubby --remove-kernel=/boot/vmlinuz-3.10.0-1160.114.2.el7.x86_64Confirm cleanup:
sudo grep -rE ".el7|.el8" "/boot/loader/entries/" || echo "Everything seems ok."Re-enable SELinux After the Upgrade
During the in-place upgrade, Leapp sets SELinux to permissive mode. After the upgrade completes, you should manually restore it to enforcing for full security enforcement.
sudo sed -i 's/^SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/configThis command updates the SELinux config file to set enforcing mode.
Apply the Change Immediately (Without Reboot):
sudo setenforce 1Reboot the OS to Apply the Changes:
sudo rebootFrom here, you can now continue to test your applications, monitor system behavior, and validate that all services are functioning as expected on RHEL 9. If any issues arise that cannot be resolved, you may choose to revert to your pre-upgrade snapshot or backup.
Once you’re confident the system is stable and compliant, you can proceed with rolling out the upgrade process to other systems.
Conclusion
That marks the end of our tutorial on how to upgrade RHEL 8 to RHEL 9 using Leapp with Satellite Server integration. The system is now updated, cleaned, and configured for use on RHEL 9.
Thorough testing and validation of applications and services are essential to ensure full compatibility and stability in the new environment. If issues arise that cannot be resolved, consider reverting to your pre-upgrade snapshot or backup.
