Plan maintenance of your Red Hat Enterprise Linux systems using the newly published upgrade schema

Red Hat Enterprise Linux 7 has reached the end of its maintenance support 2 phase. Upgrade to the latest version or take advantage of Extended Lifecycle Support (ELS) for up to 4 additional years of maintenance support for the last minor release (7.9) until June 30, 2028. Act now

This blog post talks about the new RHEL in-place upgrade paths schema. Before we start talking about what is new, let’s take a look at each of these terms separately.

Red Hat Enterprise Linux (RHEL)

RHEL is an open source operating system produced by Red Hat. It serves various customer needs, which often have different lifetime demands.

RHEL follows a predictable release schedule, where a new RHEL major version is released every three years, a new RHEL minor version is released every six months, and a major version is supported for 10 years. As a result, several supported versions of RHEL always exist in parallel.

Refer to an official RHEL life cycle documentation to learn more.

In-place upgrades

The RHEL in-place upgrades allow users to upgrade their RHEL systems to the next major version without requiring a fresh install. The in-place upgrade feature is implemented by the Leapp utility. You can also upgrade across multiple RHEL major versions (for example, from RHEL 7 to RHEL 9) by performing multiple sequential upgrades (in this case, from RHEL 7 to RHEL 8 and then from RHEL 8 to RHEL 9).

Upgrade paths

Upgrade paths define which RHEL versions you can upgrade from and to. An upgrade path is defined as a pair of two RHEL minor versions (RHEL X.Y). If an upgrade path will or will not be supported is defined by the upgrade path schema. 

Old upgrade paths schema

The old schema was based on these two rules:

• Latest RHEL minor version of source system to latest RHEL EUS minor version of the target system (for example, from RHEL 7.9 to RHEL 8.6)
• Latest RHEL minor version of source system to previous RHEL EUS minor version of the target system (for example, from RHEL 7.9 to RHEL 8.4)

The rules evolved over time and tried to meet requirements of both types of users. 

• Users who do regular updates to the latest minor version
• Users who stay on a particular minor version for longer and use EUS

In the end, this didn't work particularly well for anybody, and forced both groups to make compromises.

Users from the first group (not using EUS) had to do one more minor update after the major version in-place upgrade (resulting in the need for another restart).

EUS users in the second group had an even bigger issue. As the source version of the upgrade path had changed every six months with the release of a new minor version, they were unable to benefit from their EUS and potentially gave up to two years of support for doing the upgrade.

It is tempting to say a user from the second group (using EUS) could do one more minor update and get to the supported upgrade path, but the reality is not so simple. One of the reasons for staying on minor versions with two years of support could be because of a third-party application that is only supported on those versions. Having to first do a minor update to a RHEL version uncertified by the third-party application—without 100% certainty that the following major in-place upgrade will be technically possible—was no-go for many customers and led to several support exceptions.

New upgrade paths schema

The new schema mitigates the problems of the old and is much easier to understand.

It takes advantage of RHEL synchronous releases—a workflow where minor versions of active RHEL versions are planned, developed and released at the same time. In other words:

• RHEL 8.6 has the same lifecycle as RHEL 9.0
• RHEL 8.8 has the same lifecycle as RHEL 9.2
• RHEL 8.9 will have the same lifecycle as RHEL 9.3

This path builds around RHEL synchronous releases, and uses the following rules:

• Each RHEL version can be upgraded to the next major version
• Particular combinations of minor versions of the source and target side are defined by the pair of synchronous RHEL releases
• Each upgrade path is supported for the same time as the RHEL versions it connects
• Once the source system reaches the last minor version, it is also used as a source for newer target versions

For better understanding, we can apply the rules on a RHEL 8 to RHEL 9 upgrade and we will get schema like this:

In a nutshell, we can say that the upgrade path is defined by the pair of RHEL synchronous versions.

New features and bug fixes

The Leapp utility continues to get new features and bug fixes. New Leapp versions are released periodically and delivered as part of RHEL.

Like other components, the latest version of the Leapp utility is released to the latest RHEL version. Previous RHEL versions are updated only for critical bug fixes and security updates.

But there is one exception: The last RHEL minor version is regularly updated with new versions of the Leapp utility as long as the target of the upgrade paths changes. For example, the first version of the Leapp utility will get to RHEL 8.10 with its GA and will enable upgrades to RHEL 9.4. After six months it will be updated, and the upgrade paths will extend with RHEL 9.5. After another half year, an even more recent version of the Leapp utility will be available and RHEL 9.6 will replace RHEL 9.5 as a target of the upgrade. This process will repeat every six months until the final upgrade path of RHEL 8.10 to RHEL 9.10. 

Does this address the problems?

It does. We defined two groups of users earlier in this blog post, so let’s take at what their user experience will look like now.

Firstly, let's look at users continuously updating to the latest RHEL minor versions. They can do a major upgrade to the next RHEL major version, and they will land on its latest minor in one step. Upgrade experience improved!

Users from the second group, who are using EUS to stay on a particular minor version for up to two years, can do the major upgrade at any time during this period. And the upgraded system is still a RHEL EUS version. Upgrade experience improved!

In general, all users benefit from the fact that each supported RHEL version can be upgraded to the next RHEL version.

The future is now

We are pleased to announce that the new upgrade path schema, presented in this article, became the current one with RHEL 9.2 and 8.8 GA!

The supported upgrade paths now are:

• RHEL 7.9 to RHEL 8.6
• RHEL 7.9 to RHEL 8.8
• RHEL 8.6 to RHEL 9.0
• RHEL 8.8 to RHEL 9.2

The first of the changes is RHEL 8.6 to RHEL 9.0 on the list and will remain active until the end of its EUS in May 2024. The list will evolve as new RHEL versions are released, and as others reach their end of life.

All the details about the new upgrade path schema can be found in the Supported in-place upgrade paths for Red Hat Enterprise Linux knowledge base article.