Bookmark this page

Chapter 2.  Performing In-place Upgrades of Red Hat Enterprise Linux

Abstract

Goal

Upgrade an existing Red Hat Enterprise Linux server to run a newer major version of the operating system distribution.

Sections
  • Plan an In-place Upgrade of Red Hat Enterprise Linux (and Quiz)

  • Prepare a Server for an In-place Upgrade (and Guided Exercise)

  • Create and Review a Pre-upgrade Report (and Guided Exercise)

  • Upgrade Red Hat Enterprise Linux (and Guided Exercise)

  • Perform Post-upgrade Tasks and Verification (and Guided Exercise)

Plan an In-place Upgrade of Red Hat Enterprise Linux

Objectives

  • Explain when to perform an in-place upgrade of Red Hat Enterprise Linux, what upgrade paths are supported, and what to consider when planning an upgrade.

Reasons to Upgrade

The Red Hat Enterprise Linux (RHEL) ecosystem provides a lifecycle plan that delivers different phases of support and maintenance for each major release version. RHEL 7, RHEL 8, and RHEL 9 are examples of Red Enterprise Linux major release versions.

Every major release of RHEL improves and introduces features that might change core software and system tools. Red Hat delivers bug fixes and other improvements to major releases through minor release updates. These minor release updates improve the functionality of the initial major release. RHEL 8.6, RHEL 9.1, and RHEL 9.2 are examples of Red Enterprise Linux minor release versions.

The Maintenance Support 2 phase for Red Hat Enterprise Linux 7 ends on June 30, 2024. To extend limited subscription and support services beyond that date, customers can buy annual Add-On subscriptions to Extended Life Cycle Support (ELS). Eligibility might be limited based on your subscriptions and the systems that you want to support. More information is available on the Red Hat Enterprise Linux Life Cycle page. Limited extended support is one reason why you might elect to upgrade earlier major versions of Red Hat Enterprise Linux to newer ones.

Choosing a Clean Installation or an In-place Upgrade

After you decide to upgrade a system, you must plan ahead to improve the chances of a successful operation. You must first choose a method for the system upgrade: a clean installation or an in-place upgrade.

The upgrade method that you choose might depend on several circumstances. You might choose a clean installation method if you plan to change the underlying hardware. Or, you might choose an in-place upgrade to avoid backing up and restoring data and configuration, and to potentially save time in the upgrade process.

Clean Installation

The clean installation (or re-installation) method installs a new operating system that replaces the existing system. This method removes custom configuration, user and application data, and subscription information. You must back up all data that you want to preserve before you start the clean installation process. After you finish the clean installation, you must reinstall applications, restore all data, and subscribe the system.

In-place Upgrade

The in-place upgrade method replaces the existing operating system with the target version and preserves custom configuration, data, and subscription information. Depending on the target version for the upgrade, some system tools and software might be removed or replaced. For example, a kernel module might not be supported in the upgrade path and you must adjust the system to prepare the upgrade.

Red Hat provides the Leapp tool to support in-place upgrades from one major version of Red Hat Enterprise Linux to another.

This section focuses on the in-place upgrade method.

Important

Red Hat recommends opening a support case before performing an upgrade to improve the upgrade success rate. Open a support case with Red Hat by following the instructions in the Knowledgebase: "How do I Open and Manage a Support Case on the Customer Portal?" article.

Planning an In-place Upgrade

Red Hat supports specific upgrade paths that depend on the minor release version of the system. Create an inventory that includes the full operating system version and the system architecture of the machines that you plan to upgrade.

You can review the full operating system version and architecture by using the hostnamectl command.

In general, an in-place upgrade is performed from the most recent minor release of the version of RHEL that your server is running, to the most recent minor release of the next major version of RHEL. Updates are performed one major version at a time. It is possible to upgrade from RHEL 7 to RHEL 9, for example, but you must upgrade from RHEL 7 to RHEL 8 first, and then upgrade to RHEL 9.

In-place Upgrade Paths for RHEL 7

Red Hat only supports the upgrade of RHEL 7 systems that are running the RHEL 7.9 minor release. You must update your RHEL 7 servers to RHEL 7.9 before attempting to upgrade to RHEL 8.

The following table shows the upgrade paths for RHEL 7 systems:

Table 2.1. In-place Upgrade Paths for RHEL 7

SystemSource OS versionSupported target OS version
RHEL with 64-bit Intel, IBM POWER 8 (little endian), or 64-bit IBM ZRHEL 7.9RHEL 8.6
RHEL 8.8
RHEL 8.9 (default)
RHEL with SAP HANARHEL 7.9RHEL 8.6
RHEL 8.8 (default)

In-place Upgrade Paths for RHEL 8

Red Hat only supports the upgrade of RHEL 8 systems that are running the RHEL 8.6, RHEL 8.8, or RHEL 8.9 minor release. If your RHEL 8 system is not running one of the specified versions, then include a task in your upgrade plan to update the system to an appropriate minor version of RHEL before performing the in-place upgrade to a new major version.

The following table shows the upgrade paths for RHEL 8 systems:

Table 2.2. In-place Upgrade Paths for RHEL 8

SystemSource OS versionSupported target OS version
RHELRHEL 8.6RHEL 9.0
RHEL 8.8RHEL 9.2
RHEL 8.9RHEL 9.3
RHEL with SAP HANARHEL 8.6RHEL 9.0
RHEL 8.8RHEL 9.2

Adjusting Applications for Multiple Major Upgrades

Some applications might require that you perform additional tasks when you update between major or minor releases of Red Hat Enterprise Linux. An application might require tasks that range from updating a configuration file to installing a different driver.

For example, an upgrade plan for a system might include the following tasks:

  • Updating to a specific minor release

  • Upgrading to the next major release

  • Adjusting the application to the new major release

  • Upgrading again

Because of these unique requirements, your upgrade plan might include separate plans for different systems, depending on the application that runs on each system.

Contact your application provider to verify whether any special tasks are required to adjust the application to work with a new version of Red Hat Enterprise Linux.

Bulk Upgrades with Red Hat Satellite

From the command line, the Leapp tool enables you to analyze and upgrade one host at a time. To upgrade multiple hosts simultaneously, you can use Red Hat Satellite. You must enable the Leapp tool plug-in on the Red Hat Satellite Server that manages the target hosts.

More information is available in the Upgrading Hosts to Next Major Red Hat Enterprise Linux Release chapter in the Managing Hosts guide for Red Hat Satellite 6.14.

Requirements and Considerations for In-place Upgrades

The upgrade strategy of your organization might include creating a different plan for each system. Creating multiple upgrade plans for your systems is a common approach because you must consider the geographical location, underlying infrastructure or platform, application type, system release version, and the naming conventions of each system. Also, depending on the system type, you might need to perform additional tasks or choose a clean installation process.

Hardware Requirements

RHEL 7, RHEL 8, and RHEL 9 operating systems have different hardware requirements. Make sure that the hardware properties of your system support the new release version. In particular, review the release notes for newer operating systems to confirm that your CPU and the drivers that your hardware requires are still supported.

See the reference section for more information about the hardware requirements for RHEL 8 and RHEL 9 systems.

Security Requirements

When planning the upgrade of your systems, make sure to understand the security requirements of each major release version. Assess your systems and include relevant information about the systems that require additional configuration. See the reference section for more information about security requirements for RHEL 8 and RHEL 9 systems.

The Leapp tool sets SELinux to permissive mode during the upgrade process. Make sure to set SELinux to enforcing mode after you finish the upgrade.

Upgrading systems with Federal Information Processing Standard (FIPS) mode enabled is not fully automated with the Leapp tool. Red Hat recommends planning a clean installation for systems that use FIPS mode. However, if your organization's security policy allows in-place upgrades for systems with FIPS mode enabled, then disable FIPS mode, use the Leapp tool to upgrade the system, enable FIPS mode, and regenerate cryptographic keys on your system.

Operational Considerations

Include a backup plan for the upgrade process of your systems. Your organization might already use a backup system or snapshot technology. Make sure that the backups are current and that the backups include all required data or disks before you start the upgrade.

The upgrade process might take several minutes to several hours to complete, depending on the installed software, hardware, and network bandwidth. Make sure that you create a plan to continue standard operations if the system takes more time than expected to upgrade.

RHEL systems that use the High Availability Add-On might require a special upgrade plan. See the reference section for more information about upgrading RHEL systems that use the High Availability Add-On.

The in-place upgrade process does not support changes to the boot loader tool from BIOS to UEFI. To change the boot loader of the system from BIOS to UEFI, you must perform a clean installation instead of an in-place upgrade.

Platform Support

The Leapp tool supports the in-place upgrade of the following systems:

  • Red Hat Enterprise Linux for Real Time systems

  • Real Time for Network Functions Virtualization (NFV) in Red Hat OpenStack Platform

  • Red Hat OpenStack Platform for Real-Time Applications

  • On-demand pay-as-you-go (PAYG) instances on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform with Red Hat Update Infrastructure (RHUI)

  • Bring-your-own-subscription (BYOS) instances on all public clouds that use Red Hat Subscription Manager (RHSM) for a RHEL subscription

Known Limitations

You cannot perform in-place upgrades with the Leapp tool in the following situations:

  • Systems with encryption of the whole disk, a partition, or a file system.

  • Network-based multipath and network storage that use Ethernet or InfiniBand™. This limitation includes storage area network (SAN) devices that use Fibre Channel over Ethernet (FCoE) and systems booting from SAN by using Fibre Channel (FC).

  • On-demand PAYG instances on the public cloud services that use Red Hat Update Infrastructure, but not RHSM, for a RHEL subscription.

  • Systems with any Ansible products installed (including Red Hat Ansible Tower).

References

hostnamectl(1) and leapp(1) man pages

For more information about the Red Hat Enterprise Linux lifecycle, refer to Red Hat Enterprise Linux Life Cycle at https://access.redhat.com/support/policy/updates/errata

For more information about the hardware requirements for installing RHEL 8, refer to the System Requirements Reference section in the Performing a Standard RHEL 8 Installation guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_a_standard_rhel_8_installation/index#system-requirements-reference_installing-RHEL

For more information about the hardware requirements for installing RHEL 9, refer to the System Requirements Reference section in the Performing a Standard RHEL 9 Installation guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/performing_a_standard_rhel_9_installation/index#system-requirements-reference_installing-RHEL

For more information about RHEL 8 security requirements, refer to the Security chapter in the Considerations in Adopting RHEL 8 guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index#security_considerations-in-adopting-RHEL-8

For more information about RHEL 9 security requirements, refer to the Security chapter in the Considerations in Adopting RHEL 9 guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#assembly_security_considerations-in-adopting-RHEL-9

For more information about updating RHEL system with the High Availability Add-On, refer to Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster at https://access.redhat.com/articles/2059253

For more information about upgrading RHEL hosts in Red Hat Satellite, refer to the Upgrading Hosts to Next Major Red Hat Enterprise Linux Release chapter in the Managing Hosts guide at https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html-single/managing_hosts/index#Upgrading_Hosts_to_Next_Major_RHEL_Release_managing-hosts

Revision: rh174-7.9-0acf85c