Lets Upgrade From RHEL7 To RHEL8

It has been quite some time since RHEL8 was released. Red Hat has officially announced the upgrade support from RHEL6 → RHEL7 & RHEL7 → RHEL8. This is with certain conditions and limitations. One has to read the complete document from Red Hat to understand the caveats about it. As per the official documentation from Red Hat, only Server variant is supported. So, let’s first understand certain important limitations before we could plan the upgrade. 

What is the supported upgrade path?

- An in-place upgrade is currently supported only from RHEL7.6 to RHEL8.1 release (likewise from RHEL6.10 to RHEL7.6)*. As per the recent update the upgrade from RHEL7.8 to RHEL8.2 is supported and for details check the UPDATE section at the bottom.

- Only Server variant with 64-bit Intel, 64-bit ARM, IBM POWER (little endian), IBM Z architectures are supported.

Known Limitations

→ A rollback to the last known good state has not been implemented in the Leapp utility. A complete system backup prior to the upgrade is recommended.

→ Only packages of the group “Base” & “Minimal” are supported.

→ Any encrypted file systems or files are not supported. 

→ No Multipath or any kind of network storage mount can be used as a system partition (for example, iSCSI, FCoE or NFS).

→ In-place upgrade for instances running on public cloud such as Amazon, Google Cloud etc, are currently not supported.

Demo System Setup 

This is the system (RHEL7.6) which is being used to perform the upgrade to RHEL8.1 release and the details are provided below:

System Type: Virtual system running on Oracle VirtualBox.

System Release: RHEL7.6

The system is configured with basic httpd service, and I've created a simple index file as shown below:

System native firewalld has been configured to allow httpd service:

SELinux is in default "Enforcing" mode and there are 2 network interfaces configured, one with static IP and other one in DHCP mode:

Let’s Upgrade to RHEL8

Phase 1: Preparing a RHEL 7 system for the upgrade

There are certain pre-checks to be performed before we could actually trigger the upgrade. Let’s see what are those steps:

1. Make sure that the system is successfully registered with Red Hat using Subscription Manager (with Red Hat Content Delivery Network). Otherwise, with a centralized package management system such as Red Hat Satellite. Verify if subscription is current:

2. Enable EUS (Extended Update Support) repos if available.

The following command needs to be executed to get this done:

3. Lock the release to 7.6 release.

# subscription-manager release --set 7.6

4. Ensure you've the system locale set to en_US.UTF-8.

# cat /etc/locale.conf

5. Run update to get the latest packages of 7.6 release.

# yum update -y && reboot

Verify if the kernel is updated and release is still 7.6:

6. Install leapp utility.

# yum install leapp -y

Make sure that the leapp-deps package is "leapp-deps-0.9.0-1.el7.noarch" or later version.

7. Download additional required data files:

https://access.redhat.com/articles/3664871

Refer the steps in the article, download and extract the file. There should be two files under “/etc/leapp/files” folder as shown below:

Since these two files are owned by redhat user, I changed them to root since the parent directory was owned by root:

8. Make sure to disable any configuration management agents or tools installed.

9. If network interface names are based on legacy ‘ethx’ conventions then need to get them converted to newer way, otherwise, follow the article: https://access.redhat.com/solutions/4067471

10. Make a full system backup or a virtual machine snapshot (if system is virtual) as a final precaution before proceeding. 

Phase 2: Let’s run pre-upgrade check

During this phase, the preupgrade leapp utility would collect data about the system, assesses upgradability, and produces a pre-upgrade report in the “/var/log/leapp/leapp-report.txt” file and in the console. This report would show potential problems and any fixes if available. 

1. Run the ‘leapp preupgrade’ command.

This would validate the system to check if it meets the minimum requirement to perform an upgrade. It would take some time to get this done. When ran on my demo system it failed with two major errors as shown below:

When checked the file ‘/var/log/leapp/leapp-report.txt’ file, these were the two major areas of failure:

Step 2: Fix any errors and re-run the “leapp preupgrade” command.

- Enabled “PermitRootLogin” parameter in ‘/etc/ssh/sshd_config’ and restarted the “sshd” service (since I've used to root to connect to my system, this may not be an issue otherwise, where normally root direct login is disabled).

- Removed the “e1000” network driver module and used a different network driver module for the system.

After fixing those errors, I ran the "leapp preupgrade" command and found that though there were no "errors" reported, but there were 2 "Risk Factor: High" events found as shown below:

I ran a package check on those and found they are not installed as shown above, so I presume that there is no such major risk. Hence, ready to do an upgrade.

Phase 3: Let’s do the upgrade now

Run the ‘leapp upgrade’ command.

When I first ran 'leapp upgrade' it was not successful and there were 2 high risk notifications which were pointing to the packages as explained before. So, I checked and found that the EUS repos were not enabled, hence enabled EUS repos again:

NOTE: Since system gets rebooted after update, it is highly advisable to check this once before running upgrade. 

Leapp upgrade started → 

It has installed/updated many packages as shown below:

Finally got the screen which says that it has completed the task and system needs a reboot now:

NOTE: Please don’t forget to set SELinux to ‘Enforcing’ mode since we had set it to ‘Permissive’ earlier. 

# setenforce 1 && reboot 

Phase 4: Post Upgrade State

Step 1: Inspect & validate.

After the reboot, I noticed that system has not yet completely updated initramfs and other kernel image files since I could see the boot entry as ‘RHEL-Upgrade-Initramfs’ as shown :

After the reboot, the system did several updates again:

After installing the updates, the system dropped into shell mode and I've to reboot the system.

Yes, finally the RHEL8 GRUB screen came up:

Step 2: Let's login and check.

I was unable to login using both root and user account as well. Both failed and I have to break & reset the root user account password to login.

Finally, I made successful login to root user account.

Success……….!

Let me check if the basic http service that I had configured is still working. The curl command didn't work though the httpd daemon was up. When checked there was no network interface found. Following errors were there in log messages:

I found out it was because I had disabled "Intel PRO/1000 Network Driver" (e1000) since it was a risk component in the "leapp upgrade" process. I had enabled it and after which the httpd service started working (don't forget to attach RHEL8 subscriptions):

That’s it!

*at the time of writing

Reference: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index

------------------------------------------------------------------------------------------------

UPDATES

Yes, the "leapp upgrade" from RHEL7.8 to RHEL8.2 is also supported*. I had tried this upgrade and it worked. I'd say that the process/workflow of "leapp upgrade" is good and straightforward compared to earlier flow which was from RHEL7.6 to RHEL8.1 release.

Important pre-checks in addition to those mentioned above before the upgrade from RHEL7.8 to RHEL8.2:

- Required repos are "rhel-7-server-rpms" & "rhel-7-server-extras-rpms" only.

- There is no need to lock the release using subscription-manager. But need to unset the release using "subscription-manager release --unset" command. 

My overall observation from the "leapp upgrade" is that Red Hat has made a very good process/workflow in getting the supported upgrade paths from RHEL7.x to RHEL8.x releases.