Chapter 2. Planning an upgrade to RHEL 9
Before beginning your upgrade from RHEL 8 to RHEL 9, review system requirements, limitations, and other considerations.
2.1. Planning an upgrade from RHEL 8.10 to RHEL 9.4
An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.
You should consider the following before upgrading to RHEL 9:
Operating system - The operating system is upgradable by the
Leapputility under the following conditions:The source OS version is installed on a system with one of the following supported architectures:
- 64-bit Intel, AMD, and ARM
- IBM POWER (little endian)
64-bit IBM Z
For more information, see Red Hat certified hardware.
- Minimum hardware requirements for RHEL 9 are met.
- You have access to up-to-date content for the selected source and target OS versions. See Preparing a RHEL 8 system for the upgrade for more information.
Applications - You can migrate applications installed on your system using
Leapp. However, in certain cases, you have to create custom actors, which specify actions to be performed byLeappduring the upgrade, for example, reconfiguring an application or installing a specific hardware driver. For more information, see Handling the migration of your custom and third-party applications. Note that custom actors are unsupported by Red Hat.ImportantThe SHA-1 algorithm has been deprecated in RHEL 9. If your system contains any packages with RSA/SHA-1 signatures, the upgrade is inhibited. Before upgrading, either remove these packages or contact the vendor for packages with RSA/SHA-256 signatures. For more information, see SHA-1 deprecation in Red Hat Enterprise Linux 9.
Security - You should evaluate this aspect before the upgrade and take additional steps when the upgrade process completes. Consider especially the following:
- Before the upgrade, define the security standard your system has to comply with and understand the security changes in RHEL 9.
-
During the upgrade process, the
Leapputility sets SELinux mode to permissive. -
Leappsupports in-place upgrades of RHEL 8.8 and later systems in Federal Information Processing Standard (FIPS) 140 mode to RHEL 9 FIPS-mode-enabled systems. FIPS mode stays enabled during the complete upgrade process. - After the upgrade is finished, re-evaluate and re-apply your security policies. For information about applying and updating security policies, see Applying security policies.
Storage and file systems - You should always back up your system prior to upgrading. For example, you can use the Relax-and-Recover (ReaR) utility, LVM snapshots, RAID splitting, or a virtual machine snapshot.
NoteFile systems formats are intact. As a consequence, file systems have the same limitations as when they were originally created.
- High Availability - If you are using the High Availability add-on, follow the Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster Knowledgebase article.
- Downtime - The upgrade process can take from several minutes to several hours.
- Satellite - If you manage your hosts through Satellite, you can upgrade multiple hosts simultaneously from RHEL 8 to RHEL 9 using the Satellite web UI. For more information, see Upgrading Hosts to Next Major Red Hat Enterprise Linux Release.
- SAP HANA - If you are using SAP HANA, follow the Upgrading SAP environments from RHEL 8 to RHEL 9 guide instead. Note that the upgrade path for RHEL with SAP HANA might differ.
- RHEL for Real Time - Upgrades on real-time systems are supported.
- Real Time for Network Functions Virtualization (NFV) in Red Hat OpenStack Platform - Upgrades on real-time systems are supported.
- * Red Hat JBoss Enterprise Application Platform (EAP) - JBoss EAP is not supported for the upgrade to RHEL 9. You must manually install and configure JBoss EAP on your system after the upgrade. For more information, see In-place Migrating of Jboss EAP and websphere servers along with Linux using leapp utility.
- Public clouds - The in-place upgrade is supported for on-demand Pay-As-You-Go (PAYG) instances using Red Hat Update Infrastructure (RHUI) only on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. The in-place upgrade is also supported for Bring Your Own Subscription instances on all public clouds that use RHSM for a RHEL subscription.
-
Language - All
Leappreports, logs, and other generated documentation are in English, regardless of the language configuration. - Bootloader - It is not possible to switch the bootloader from BIOS to UEFI on RHEL 8 or RHEL 9. If your RHEL 8 system uses BIOS and you want your RHEL 9 system to use UEFI, perform a fresh install of RHEL 9 instead of an in-place upgrade. For more information, see Is it possible to switch the BIOS boot to UEFI boot on preinstalled Red Hat Enterprise Linux machine?
Known limitations - Notable known limitations of
Leappcurrently include:- Encryption of the whole disk or a partition, or file-system encryption currently cannot be used on a system targeted for an in-place upgrade.
- Network based multipath and network storage that use Ethernet or Infiniband are not supported for the upgrade. This includes SAN using FCoE and booting from SAN using FC. Note that SAN using FC are supported.
- The in-place upgrade is currently unsupported for on-demand PAYG instances on the remaining Public Clouds that use Red Hat Update Infrastructure but not Red Hat Subscription Manager (RHSM) for a RHEL subscription.
- The in-place upgrade is not supported for systems with any Ansible products, including Ansible Tower, installed. To use a RHEL 8 Ansible Tower installation on RHEL 9, see the How do I migrate my Ansible Automation Platform installation from one environment to another? Knowledgebase solution.
See also Known Issues.
You can use Red Hat Insights to determine which of the systems you have registered to Insights is on a supported upgrade path to RHEL 9. To do so, navigate to the respective Advisor recommendation in Insights, enable the recommendation under the Actions drop-down menu, and inspect the list under the Affected systems heading. Note that the Advisor recommendation considers only the RHEL 8 minor version and does not perform a pre-upgrade assessment of the system. See also Advisor-service recommendations overview.
2.2. Planning an upgrade from RHEL 8.8 to RHEL 9.2
An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.
You should consider the following before upgrading to RHEL 9.2:
Operating system - The operating system is upgradable by the
Leapputility under the following conditions:The source OS version is installed on a system with one of the following supported architectures:
- 64-bit Intel, AMD, and ARM
- IBM POWER (little endian)
64-bit IBM Z
For more information, see Red Hat certified hardware.
- Minimum hardware requirements for RHEL 9 are met.
- You have access to up-to-date content for the selected source and target OS versions. See Preparing a RHEL 8 system for the upgrade for more information.
Applications - You can migrate applications installed on your system using
Leapp. However, in certain cases, you have to create custom actors, which specify actions to be performed byLeappduring the upgrade, for example, reconfiguring an application or installing a specific hardware driver. For more information, see Handling the migration of your custom and third-party applications. Note that custom actors are unsupported by Red Hat.ImportantThe SHA-1 algorithm has been deprecated in RHEL 9. If your system contains any packages with RSA/SHA-1 signatures, the upgrade is inhibited. Before upgrading, either remove these packages or contact the vendor for packages with RSA/SHA-256 signatures. For more information, see SHA-1 deprecation in Red Hat Enterprise Linux 9.
Security - You should evaluate this aspect before the upgrade and take additional steps when the upgrade process completes. Consider especially the following:
- Before the upgrade, define the security standard your system has to comply with and understand the security changes in RHEL 9.
-
During the upgrade process, the
Leapputility sets SELinux mode to permissive. -
Leappsupports in-place upgrades of RHEL 8.8 and later systems in Federal Information Processing Standard (FIPS) 140 mode to RHEL 9 FIPS-mode-enabled systems. FIPS mode stays enabled during the complete upgrade process. - After the upgrade is finished, re-evaluate and re-apply your security policies. For information about applying and updating security policies, see Applying security policies.
Storage and file systems - You should always back up your system prior to upgrading. For example, you can use the Relax-and-Recover (ReaR) utility, LVM snapshots, RAID splitting, or a virtual machine snapshot.
NoteFile systems formats are intact. As a consequence, file systems have the same limitations as when they were originally created.
- High Availability - If you are using the High Availability add-on, follow the Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster Knowledgebase article.
- Downtime - The upgrade process can take from several minutes to several hours.
- Satellite - If you manage your hosts through Satellite, you can upgrade multiple hosts simultaneously from RHEL 8 to RHEL 9 using the Satellite web UI. For more information, see Upgrading Hosts to Next Major Red Hat Enterprise Linux Release.
- SAP HANA - If you are using SAP HANA, follow the Upgrading SAP environments from RHEL 8 to RHEL 9 guide instead. Note that the upgrade path for RHEL with SAP HANA might differ.
- Red Hat JBoss Enterprise Application Platform (EAP) - JBoss EAP is not supported for the upgrade to RHEL 9. You must manually install and configure JBoss EAP on your system after the upgrade. For more information, see In-place Migrating of Jboss EAP and websphere servers along with Linux using leapp utility.
- Public clouds - The in-place upgrade is supported for on-demand Pay-As-You-Go (PAYG) instances using Red Hat Update Infrastructure (RHUI) only on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. The in-place upgrade is also supported for Bring Your Own Subscription instances on all public clouds that use RHSM for a RHEL subscription.
-
Language - All
Leappreports, logs, and other generated documentation are in English, regardless of the language configuration. - Bootloader - It is not possible to switch the bootloader from BIOS to UEFI on RHEL 8 or RHEL 9. If your RHEL 8 system uses BIOS and you want your RHEL 9 system to use UEFI, perform a fresh install of RHEL 9 instead of an in-place upgrade. For more information, see Is it possible to switch the BIOS boot to UEFI boot on preinstalled Red Hat Enterprise Linux machine?
Known limitations - Notable known limitations of
Leappcurrently include:- Encryption of the whole disk or a partition, or file-system encryption currently cannot be used on a system targeted for an in-place upgrade.
- Network based multipath and network storage that use Ethernet or Infiniband are not supported for the upgrade. This includes SAN using FCoE and booting from SAN using FC. Note that SAN using FC are supported.
- The in-place upgrade is currently unsupported for on-demand PAYG instances on the remaining Public Clouds that use Red Hat Update Infrastructure but not Red Hat Subscription Manager (RHSM) for a RHEL subscription.
- The in-place upgrade is not supported for systems with any Ansible products, including Ansible Tower, installed. To use a RHEL 8 Ansible Tower installation on RHEL 9, see the How do I migrate my Ansible Automation Platform installation from one environment to another? Knowledgebase solution.
See also Known Issues.
You can use Red Hat Insights to determine which of the systems you have registered to Insights is on a supported upgrade path to RHEL 9. To do so, navigate to the respective Advisor recommendation in Insights, enable the recommendation under the Actions drop-down menu, and inspect the list under the Affected systems heading. Note that the Advisor recommendation considers only the RHEL 8 minor version and does not perform a pre-upgrade assessment of the system. See also Advisor-service recommendations overview.
