Menu Close
Upgrading from RHEL 8 to RHEL 9
Instructions for an in-place upgrade from Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your input on our documentation. Please let us know how we could make it better.
For simple comments on specific passages:
- Make sure you are viewing the documentation in the Multi-page HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document.
- Use your mouse cursor to highlight the part of text that you want to comment on.
- Click the Add Feedback pop-up that appears below the highlighted text.
- Follow the displayed instructions.
For submitting feedback via Bugzilla, create a new ticket:
- Go to the Bugzilla website.
- As the Component, use Documentation.
- Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
- Click Submit Bug.
Key migration terminology
While the following migration terms are commonly used in the software industry, these definitions are specific to Red Hat Enterprise Linux (RHEL).
Update
Sometimes called a software patch, an update is an addition to the current version of the application, operating system, or software that you are running. A software update addresses any issues or bugs to provide a better experience of working with the technology. In RHEL, an update relates to a minor release, for example, updating from RHEL 8.1 to 8.2.
Upgrade
An upgrade is when you replace the application, operating system, or software that you are currently running with a newer version. Typically, you first back up your data according to instructions from Red Hat. When you upgrade RHEL, you have two options:
- In-place upgrade: During an in-place upgrade, you replace the earlier version with the new version without removing the earlier version first. The installed applications and utilities, along with the configurations and preferences, are incorporated into the new version.
- Clean install: A clean install removes all traces of the previously installed operating system, system data, configurations, and applications and installs the latest version of the operating system. A clean install is ideal if you do not need any of the previous data or applications on your systems or if you are developing a new project that does not rely on prior builds.
Operating system conversion
A conversion is when you convert your operating system from a different Linux distribution to Red Hat Enterprise Linux. Typically, you first back up your data according to instructions from Red Hat.
Migration
Typically, a migration indicates a change of platform: software or hardware. Moving from Windows to Linux is a migration. Moving a user from one laptop to another or a company from one server to another is a migration. However, most migrations also involve upgrades, and sometimes the terms are used interchangeably.
- Migration to RHEL: Conversion of an existing operating system to RHEL
- Migration across RHEL: Upgrade from one version of RHEL to another
Chapter 1. Supported upgrade paths
The in-place upgrade replaces the RHEL 8 operating system on your system with a RHEL 9 version.
It is not possible to perform an in-place upgrade directly from RHEL 7 to RHEL 9. However, you can perform an in-place upgrade from RHEL 7 to RHEL 8 and then perform a second in-place upgrade to RHEL 9. For more information, see Upgrading from RHEL 7 to RHEL 8.
Currently, it is possible to perform an in-place upgrade from the following source RHEL 8 minor versions to the following target RHEL 9 minor versions:
Table 1.1. Supported upgrade paths
Product variant | Source OS version | Target OS version |
---|---|---|
RHEL | RHEL 8.6 | RHEL 9.0 |
For more information on supported upgrade paths, see Supported in-place upgrade paths for Red Hat Enterprise Linux.
Chapter 2. Planning an upgrade
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
Leapp
utility 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 met
- Access to up-to-date RHEL 8.6 and RHEL 9.0 content provided; see Preparing a RHEL 8 system for the upgrade, step 1 for details.
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 byLeapp
during 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.ImportantSHA1
has been deprecated in RHEL 9. If your system contains any packages withRSA/SHA1
signatures, the upgrade is inhibited. Before upgrading, either remove these packages or contact the vendor for packages withRSA/SHA256
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
Leapp
utility sets SELinux mode to permissive. - In-place upgrades of systems in FIPS mode are not supported.
- 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.
- High Availability - Upgrades of systems using the High Availability add-on are unsupported.
- 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 from RHEL 7 to RHEL 8.
- Public clouds - The in-place upgrade is supported for on-demand Pay-As-You-Go (PAYG) instances on Amazon Web Services (AWS) with Red Hat Update Infrastructure (RHUI). Note that to use RHUI with AWS instances, you must have an official RHEL Amazon Machine Image (AMI) certified by Red Hat. 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
Leapp
reports, 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 8 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
Leapp
currently 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.
- No network-based multipath and no kind of network storage mount can be used as a system partition (for example, iSCSI, or NFS).
- The in-place upgrade is currently unsupported for on-demand PAYG instances on the remaining Public Clouds (Microsoft Azure, Huawei Cloud, Alibaba Cloud, Google Cloud) that use Red Hat Update Infrastructure but not Red Hat Subscription Manager (RHSM) for a RHEL subscription.
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.
Chapter 3. Preparing for the upgrade
To prevent issues after the upgrade and to ensure that your system is ready to be upgraded to the next major version of RHEL, complete all necessary preparation steps before upgrading.
You must perform the preparation steps described in Preparing a RHEL 8 system for the upgrade on all systems. In addition, on systems that are registered to Satellite Server, you must also perform the preparation steps described in Preparing a Satellite system for the upgrade.
3.1. Preparing a RHEL 8 system for the upgrade
This procedure describes the steps that are necessary before performing an in-place upgrade to RHEL 9 using the Leapp
utility.
If you do not plan to use Red Hat Subscription Manager (RHSM) during the upgrade process, follow instructions in Upgrading to RHEL 9 without Red Hat Subscription Manager.
Prerequisites
- The system meets conditions listed in Planning an upgrade.
Procedure
If you previously performed an in-place upgrade from RHEL 7 to RHEL 8, remove the
/root/tmp_leapp_py3
directory if it is present on your system:# rm -rf /root/tmp_leapp_py3
ImportantIf the
/root/tmp_leapp_py3
directory is present on your system when you perform the upgrade, the system might break following the upgrade.- Ensure your system has been successfully registered to the Red Hat Content Delivery Network (CDN) or Red Hat Satellite using the Red Hat Subscription Manager.
- If your system is registered to Satellite Server, complete the steps in Preparing a Satellite system for the upgrade to ensure that your system meets the requirements for the upgrade.
Verify that you have the Red Hat Enterprise Linux Server subscription attached. For example:
# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux x86_64 Product ID: 479 Version: 8.6 Arch: x86_64 Status: Subscribed
Ensure you have appropriate repositories enabled. The following command enables the Base and Appstream repositories for the 64-bit Intel architecture; for other architectures, see RHEL 8 repositories.
# subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms --enable rhel-8-for-x86_64-appstream-rpms
NoteYou can also have the CodeReady Linux Builder or Supplementary repositories enabled; see their list in RHEL 8 repositories. In such a case,
Leapp
enables the RHEL 8 CodeReady Linux Builder or the RHEL 8 Supplementary repositories, respectively. For more information, see the Package manifest.For systems subscribed using RHSM, lock the system to RHEL 8.6:
# subscription-manager release --set 8.6
- Optional: If you want to use custom repositories, configure them per instructions in Configuring custom repositories.
If you use the
dnf versionlock
plug-in to lock packages to a specific version, clear the lock by running:# dnf versionlock clear
See How to restrict dnf to install or upgrade a package to a fixed specific package version? for more information.
If you are upgrading using Red Hat Update Infrastructure (RHUI) on AWS, enable required RHUI repositories and install required RHUI packages to ensure your system is ready for upgrade:
# dnf config-manager –set-enabled rhui-client-config-server-8 # dnf -y install rh-amazon-rhui-client-ha leapp-rhui-aws
Update all packages to the latest RHEL 8 version:
# dnf update
Reboot the system:
# reboot
Install the
Leapp
utility:# dnf install leapp-upgrade
Note that currently you need version 0.14.0 or later of the
leapp
package and version 0.16.0 or later of theleapp-repository
package.NoteIf your system does not have internet access, you can download the Preupgrade Assistant and Red Hat Upgrade Tool from the Red Hat Customer Portal.
Ensure you have access to the latest version of additional required data files, including RPM package changes, RPM repository mapping, and unsupported drivers and devices.
- If you are using RHSM for the upgrade, the system has access to cloud.redhat.com, and you have not downloaded an earlier version of the required data files, no further action is required from you. The data files are automatically downloaded from cloud.redhat.com. This also applies to developer subscriptions.
Download the data files attached to the Knowledgebase article Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades and place them in the
/etc/leapp/files/
directory. Note that currently you need data files from theleapp-data17.tar.gz
archive or later. This is necessary for a successful upgrade in the following scenarios:- You are upgrading on a public cloud using RHUI. If you do not have a Red Hat subscription or Red Hat Customer Portal account, create a no-cost RHEL developer subscription so that you can access the Knowledgebase article and download required data packages. For more information, see How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it?
- Your system does not have internet access.
- You are using RHSM for the upgrade and you previously downloaded an older version of the required data files but did not perform the upgrade, for example to create automated scripts. You can also delete your older version of the data files to initiate the automatic download of the latest file version.
- Temporarily disable antivirus software to prevent the upgrade from failing.
Ensure that any configuration management system does not interfere with the in-place upgrade process:
-
If you use a configuration management system with a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the
leapp preupgrade
command. Do not enable the configuration management system until after the upgrade is complete to prevent issues during the upgrade. If you use a configuration management system with agentless architecture, such as Ansible, do not execute the configuration and deployment file, such as an Ansible playbook, during the in-place upgrade as described in Performing the upgrade from RHEL 8 to RHEL 9.
Automation of the pre-upgrade and upgrade process using a configuration management system is not supported by Red Hat. For more information, see Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux.
-
If you use a configuration management system with a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the
-
Ensure your system does not use more than one Network Interface Card (NIC) with a name based on the prefix used by the kernel (
eth
). For instructions on how to migrate to another naming scheme before an in-place upgrade to RHEL 9, see How to perform an in-place upgrade to RHEL 8 when using kernel NIC names on RHEL 7. The process for migrating naming schemes is the same for both the RHEL 7 to RHEL 8 upgrade and the RHEL 8 to RHEL 9 upgrade. - If your NSS database was created in RHEL 7 or earlier, verify that the database has been converted from the DBM database format to SQLite. For more information, see Updating NSS databases from DBM to SQLite.
-
RHEL 9 does not support the legacy
network-scripts
package that was deprecated in RHEL 8. Before you can upgrade, move your custom network scripts and write a NetworkManager dispatcher script that executes your existing custom scripts. For more information, see Migrating custom network scripts to NetworkManager dispatcher scripts. - Ensure you have a full system backup or a virtual machine snapshot. You should be able to get your system to the pre-upgrade state if you follow standard disaster recovery procedures within your environment. For example, you can use the Relax-and-Recover (ReaR) utility. For more information, see the ReaR documentation and What is Relax and Recover (ReaR) and how can I use it for disaster recovery?. Alternatively, you can use LVM snapshots, or RAID splitting. In case of upgrading a virtual machine, you can create a snapshot of the whole VM.
3.2. Preparing a Satellite system for the upgrade
This procedure describes the steps that are necessary to prepare a system that is registered to Satellite for the upgrade to RHEL 9. There steps are performed on the Satellite Server.
Users on Satellite systems must complete the preparatory steps described both in this procedure and in Preparing a RHEL 8 system for the upgrade.
Prerequisites
- You have administrative privileges for the Satellite Server.
Procedure
- Verify that Satellite is on a version in full or maintenance support. For more information, see Red Hat Satellite Product Life Cycle.
- Import a subscription manifest with RHEL 9 repositories into Satellite Server. For more information, see the Managing Subscriptions chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.10.
Enable and synchronize all required RHEL 8 and RHEL 9 repositories with the latest updates for RHEL 8.6 and RHEL 9.0.
NoteFor RHEL 9 repositories, make sure to enable version 9.0 of each repository. If you have enabled only the RHEL 9 version of the repositories, the in-place upgrade is inhibited.
For example, for the Intel architecture without an Extended Update Support (EUS) subscription, enable at minimum the following repositories:
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
rhel-8-for-x86_64-appstream-rpms
x86_64 9.0
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
rhel-8-for-x86_64-baseos-rpms
x86_64 9.0
For other architectures, see RHEL 8 repositories and RHEL 9 repositories.
For more information, see the Importing Content chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.10.
Attach the content host to a Content View containing the required RHEL 8 and RHEL 9 repositories.
For more information, see the Managing Content Views chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.10.
Verification
Verify that the latest RHEL 8 repositories have been enabled on Satellite Server. For example, to verify repositories in the Library lifecycle environment:
# hammer repository list --search 'content_label ~ rhel-9' --content-view <content_view_name> --organization <organization> --lifecycle-environment Library
Replace content_view_name with the name of the content view, and organization with the organization.
Chapter 4. Reviewing the pre-upgrade report
To assess upgradability of your system, start the pre-upgrade process by the leapp preupgrade
command. During this phase, the Leapp
utility collects data about the system, assesses upgradability, and generates a pre-upgrade report.
The pre-upgrade report is available both in the /var/log/leapp/leapp-report.txt
file and in the web console. The report summarizes potential problems and proposes recommended solutions. The report also helps you decide whether it is possible or advisable to proceed with the upgrade.
In certain configurations, Leapp
generates true/false questions to determine how to proceed. All questions are stored in /var/log/leapp/answerfile
and in the pre-upgrade report in the Missing required answers in the answer file
message. Leapp
inhibits the upgrade if you do not provide answers to all the questions.
You have two options when assessing upgradability in the pre-upgrade phase:
-
Review the pre-upgrade report in the generated
leapp-report.txt
file and manually resolve reported problems using the command-line interface. - Use the web console to review the report, apply automated remediations where available, and fix remaining problems using the suggested remediation hints.
During the pre-upgrade phase, Leapp
neither simulates the whole in-place upgrade process nor downloads all RPM packages.
Reviewing a pre-upgrade report is useful also if you decide or need to redeploy a RHEL 8 system without the in-place upgrade process.
You can process the pre-upgrade report using your own custom scripts, for example, to compare results from multiple reports across different environments. For more information, see Automating your Red Hat Enterprise Linux pre-upgrade report workflow.
4.1. Assessing upgradability from the command line
Identify potential upgrade problems during the pre-upgrade phase using the command-line interface.
Prerequisites
- The steps listed in Preparing for the upgrade have been completed.
Procedure
On your RHEL 8 system, perform the pre-upgrade phase:
# leapp preupgrade --target 9.0
If you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...
-
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option. -
If you have an Extended Upgrade Support (EUS), Advanced Update Support (AUS), or Update Services for SAP Solutions (E4S) subscription, add the
--channel channel
option. Replace channel with the channel, for exampleeus
,aus
, ore4s
.
Provide answers to each question required by
Leapp
by either of the following methods:Execute the
leapp answer
command, specifying the question you are responding to and your confirmed answer.# leapp answer --section <question_section>.<field_name>=<answer>
For example, to confirm a
True
response to the question Are there no VDO devices on the system?, execute the following command:# leapp answer --section check_vdo.no_vdo_devices=True
-
Manually edit the
/var/log/leapp/answerfile
file, uncomment the last line of the file by deleting the#
symbol, and confirm your answer asTrue
orFalse
; see Leapp answerfile.
-
Examine the report in the
/var/log/leapp/leapp-report.txt
file, and manually resolve all the reported problems before proceeding with the in-place upgrade.
4.2. Assessing upgradability and applying automated remediations through the web console
Identify potential problems in the pre-upgrade phase and how to apply automated remediations using the web console.
Prerequisites
- The steps listed in Preparing for the upgrade have been completed.
Procedure
Install the
cockpit-leapp
plug-in:# dnf install cockpit-leapp
-
Navigate to the web console in your browser and log in as
root
or as a user configured in the/etc/sudoers
file. See Managing systems using the RHEL 8 web console for more information about the web console. On your RHEL 8 system, perform the pre-upgrade phase either from the command-line interface or from the web console terminal:
# leapp preupgrade --target 9.0
If you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp preupgrade --target 9.0 --enablerepo <repository_id1> --enablerepo <repository_id2> ...
-
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option. -
If you have an Extended Upgrade Support (EUS), Advanced Update Support (AUS), or Update Services for SAP Solutions (E4S) subscription, add the
--channel channel
option. Replace channel with the channel, for exampleeus
,aus
, ore4s
.
In the web console, select In-place Upgrade Report from the left menu.
Figure 4.1. In-place upgrade report in the web console
The report table provides an overview of the problems found, their risk assessment, and remediations (if available).
Risk factor:
- High - very likely to result in a deteriorated system state
- Medium - can impact both the system and applications
- Low - should not impact the system but can have an impact on applications
- Info - informational with no expected impact to the system or applications
- Inhibitor - will inhibit (hard stop) the upgrade process, otherwise the system could become unbootable, inaccessible, or dysfunctional
Remediation - an actionable solution to a reported problem:
- Remediation command - can be executed directly through the web console
- Remediation hint - instructions on how to resolve the problem manually
Examine the content of the report. You can sort the table by clicking a header. To open a detail pane, click a selected row.
Figure 4.2. Detail pane
The detail pane displays the following additional information:
- Summary of the problem and links to Knowledgebase articles describing the problem in more detail
- Remediations - you can run or schedule an automated remediation (if available), and see its results when applied
- Affected system resources: packages, repositories, files (configuration, data), disks, volumes
Optionally filter the results. Click the Filters button in the top left corner above the report and apply a filter based on your preferences. Filter categories are applied in conjunction with one another.
Figure 4.3. Filters
Select issues for which you want to apply an automated remediation. You have two options:
- Choose individual items by clicking the Add to Remediation Plan button in the detail pane. Alternatively, you can execute individual remediations directly by clicking Run Remediation in the detail pane.
- Select all items for which a remediation is available by clicking the Add all remediations to plan button in the top right corner above the report.
Review and answer questions required by
Leapp
in the web console. Each unanswered question appears as aMissing required answers in the answer file
title in the Upgrade Report. Select a title to answer the question:-
To confirm the default
True
answer, select Add to Remediation Plan to execute the remediation later or Run Remediation to execute the remediation immediately. To select the non-default answer instead, perform either of the following:
Execute the
leapp answer
command, specifying the question you are responding to and your confirmed answer.# leapp answer --section <question_section>.<field_name>=<answer>
For example, to confirm a
True
response to the question Are there no VDO devices on the system?, execute the following command:# leapp answer --section check_vdo.no_vdo_devices=True
Manually edit the
/var/log/leapp/answerfile
file, uncomment the last line of the file by deleting the#
symbol, and confirm your answer asTrue
orFalse
; see Leapp answerfile example.Figure 4.4. Missing unanswered Leapp question
-
To confirm the default
Open the remediation plan by clicking the Remediation plan link in the top right corner above the report. The remediation plan provides a list of all executed or scheduled remediations.
Figure 4.5. Remediation plan
Process all scheduled remediations by clicking Execute Remediation Plan. The following information is displayed for each remediation entry:
- A unique ID of the remediation
- Exit status of the command
- Elapsed time of the executed remediation
- Standard output
- Standard error
-
After executing selected remediations, generate the pre-upgrade report again by using the
leapp preupgrade
command, examine the new report, and take additional remediation steps if needed.
Chapter 5. Performing the upgrade from RHEL 8 to RHEL 9
This procedure lists steps required to perform the upgradefrom RHEL 8 to RHEL 9 using the Leapp
utility.
Prerequisites
- The steps listed in Preparing for the upgrade have been completed, including a full system backup.
- The steps listed in Reviewing the pre-upgrade report have been completed and all reported issues resolved.
Procedure
On your RHEL 8 system, start the upgrade process:
# leapp upgrade --target 9.0
If you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp upgrade --target 9.0 --enablerepo <repository_id1> --enablerepo <repository_id2> ...
-
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option. -
If you have an Extended Upgrade Support (EUS), Advanced Update Support (AUS), or Update Services for SAP Solutions (E4S) subscription, add the
--channel channel
option. Replace channel with the value you used with theleapp preupgrade
command, for exampleeus
,aus
, ore4s
. Note that you must use the same value with the--channel
option in both theleapp preupgrade
andleapp upgrade
commands.
At the beginning of the upgrade process,
Leapp
performs the pre-upgrade phase described in Reviewing the pre-upgrade report.-
If the system is upgradable,
Leapp
downloads necessary data and prepares an RPM transaction for the upgrade. -
If your system does not meet the parameters for a reliable upgrade,
Leapp
terminates the upgrade process and provides a record describing the issue and a recommended solution in the/var/log/leapp/leapp-report.txt
file. For more information, see Troubleshooting.
-
If the system is upgradable,
Manually reboot the system:
# reboot
In this phase, the system boots into a RHEL 9-based initial RAM disk image, initramfs.
Leapp
upgrades all packages and automatically reboots to the RHEL 9 system.Alternatively, you can run the
leapp upgrade
command with the--reboot
option and skip this manual step.If a failure occurs, investigate logs as described in Troubleshooting.
- Log in to the RHEL 9 system and verify its state as described in Verifying the post-upgrade state of the RHEL 9 system.
- Complete post-upgrade tasks as described in Performing post-upgrade tasks. Especially, re-evaluate and re-apply your security policies.
Chapter 6. Verifying the post-upgrade state of the RHEL 9 system
This procedure lists verification steps recommended to perform after an in-place upgrade to RHEL 9.
Prerequisites
- The system has been upgraded following the steps described in Performing the upgrade from RHEL 8 to RHEL 9 and you have been able to log in to RHEL 9.
Procedure
After the upgrade completes, determine whether the system is in the required state, at least:
Verify that the current OS version is RHEL 9:
# cat /etc/redhat-release Red Hat Enterprise Linux release 9.0 (Plow)
Check the OS kernel version:
# uname -r 5.14.0-70.10.1.el9_0.x86_64
Note that
.el9
is important and the version should not be earlier than 5.14.0.If you are using the Red Hat Subscription Manager:
Verify that the correct product is installed:
# subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: 9.0 Arch: x86_64 Status: Subscribed
Verify that the release version is set to 9.0 immediately after the upgrade:
# subscription-manager release Release: 9.0
- Verify that network services are operational, for example, try to connect to a server using SSH.
- Check the post-upgrade status of your applications. In some cases, you may need to perform migration and configuration changes manually. For example, to migrate your databases, follow instructions in Configuring and using database servers.
Chapter 7. Performing post-upgrade tasks
This procedure lists major tasks recommended to perform after an in-place upgrade to RHEL 9.
Prerequisites
- The system has been upgraded following the steps described in Performing the upgrade from RHEL 8 to RHEL 9 and you have been able to log in to RHEL 9.
- The status of the in-place upgrade has been verified following the steps described in Verifying the post-upgrade status of the RHEL 9 system.
Procedure
After performing the upgrade, complete the following tasks:
Remove any remaining
Leapp
packages from the exclude list in the/etc/dnf/dnf.conf
configuration file, including thesnactor
package, which is a tool for upgrade extension development. During the in-place upgrade,Leapp
packages that were installed with theLeapp
utility are automatically added to the exclude list to prevent critical files from being removed or updated. After the in-place upgrade, theseLeapp
packages must be removed from the exclude list before they can be removed from the system.-
To manually remove packages from the exclude list, edit the
/etc/dnf/dnf.conf
configuration file and remove the desiredLeapp
packages from the exclude list. To remove all packages from the exclude list:
# dnf config-manager --save --setopt exclude=''
-
To manually remove packages from the exclude list, edit the
Remove remaining RHEL 8 packages, including remaining
Leapp
packages.Locate remaining RHEL 8 packages:
# rpm -qa | grep -e '\.el[78]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
- Remove remaining RHEL 8 packages, including the old kernel package, from your RHEL 9 system.
Remove remaining
Leapp
dependency packages:# dnf remove leapp-deps-el9 leapp-repository-deps-el9
- Re-evaluate and re-apply your security policies. Especially, change the SELinux mode to enforcing. For details, see Applying security policies.
Chapter 8. Applying security policies
During the in-place upgrade process, the SELinux policy must be switched to permissive mode. Furthermore, security profiles might contain changes between major releases. This section guides you when securing your upgraded RHEL systems and covers details for pre-upgrade steps of security-related components.
8.1. Changing SELinux mode to enforcing
During the in-place upgrade process, the Leapp
utility sets SELinux mode to permissive. When the system is successfully upgraded, you have to manually change SELinux mode to enforcing.
Prerequisites
- The system has been upgraded and you have performed the verification steps described in Verifying the post-upgrade state of the RHEL 9 system.
Procedure
Ensure that there are no SELinux denials, for example, by using the
ausearch
utility:# ausearch -m AVC,USER_AVC -ts boot
Note that the previous step covers only the most common scenario. To check for all possible SELinux denials, see the Identifying SELinux denials section in the Using SELinux title, which provides a complete procedure.
Open the
/etc/selinux/config
file in a text editor of your choice, for example:# vi /etc/selinux/config
Configure the
SELINUX=enforcing
option:# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Save the change, and restart the system:
# reboot
Verification
After the system restarts, confirm that the
getenforce
command returnsEnforcing
:$ getenforce Enforcing
Additional resources
8.2. System-wide cryptographic policies
The system-wide cryptographic policies is a system component that configures the core cryptographic subsystems, covering the TLS, IPSec, SSH, DNSSec, and Kerberos protocols.
The in-place upgrade process preserves the cryptographic policy you used in RHEL 8. For example, if you used the DEFAULT
cryptographic policy in RHEL 8, your system upgraded to RHEL 9 also uses DEFAULT
. Note that specific settings in predefined policies differ, and RHEL 9 cryptographic policies contain more strict and more secure default values. For example, the RHEL 9 DEFAULT
cryptographic policy restricts SHA-1 usage for signatures and the LEGACY
policy no longer allows DH and RSA ciphers with less than 2048 bits. See the Strong crypto defaults section in the Security hardening document for more information. Custom cryptographic policies are preserved across the in-place upgrade.
To view or change the current system-wide cryptographic policy, use the update-crypto-policies tool:
$ update-crypto-policies --show
DEFAULT
For example, the following command switches the system-wide crypto policy level to FUTURE
, which should withstand any near-term future attacks:
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
If your scenario requires the use of SHA-1 for verifying existing or third-party cryptographic signatures, you can enable it by entering the following command:
# update-crypto-policies --set DEFAULT:SHA1
Alternatively, you can switch the system-wide crypto policies to the LEGACY
policy. However, LEGACY
also enables many other algorithms that are not secure.
Enabling the SHA
subpolicy makes your system more vulnerable than the default RHEL 9 settings. Switching to the LEGACY
policy is even less secure, and you should use it with caution.
You can also customize system-wide cryptographic policies. For details, see the Customizing system-wide cryptographic policies with policy modifiers and Creating and setting a custom system-wide cryptographic policy sections. If you use a custom cryptographic policy, consider reviewing and updating the policy to mitigate threats brought by advances in cryptography and computer hardware.
Additional resources
- Using system-wide cryptographic policies
-
update-crypto-policies(8)
man page.
8.3. Upgrading a system hardened to a security baseline
To get a fully hardened system after a successful upgrade to RHEL 9, you can use automated remediation provided by the OpenSCAP suite. OpenSCAP remediations align your system with security baselines, such as PCI-DSS, OSPP, or ACSC Essential Eight. The configuration compliance recommendations differ among major versions of RHEL due to the evolution of the security offering.
When upgrading a hardened RHEL 8 system, the Leapp tool does not provide direct means to retain the full hardening. Depending on the changes in the component configuration, the system might diverge from the recommendations for the RHEL 9 during the upgrade.
You cannot use the same SCAP content for scanning RHEL 8 and RHEL 9. Update the management platforms if the compliance of the system is managed by tools such as Red Hat Satellite or Red Hat Insights.
As an alternative to automated remediations, you can make the changes manually by following an OpenSCAP-generated report. For information on generating a compliance report, see Scanning the system for security compliance and vulnerabilities.
Automated remediations support RHEL systems in the default configuration. Because the system configuration has been altered after the upgrade, running automated remediations might not make the system fully compliant with the required security profile. You might need to fix some requirements manually.
The following example procedure hardens your system settings according to the PCI-DSS profile.
Prerequisites
-
The
scap-security-guide
package is installed on your RHEL 9 system.
Procedure
Find the appropriate security compliance data stream
.xml
file:$ ls /usr/share/xml/scap/ssg/content/ ... ssg-rhel9-ds.xml ...
See the Viewing compliance profiles section for more information.
Remediate the system according to the selected profile from the appropriate data stream:
# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
You can replace the
pci-dss
value in the--profile
argument with the ID of the profile according to which you want to harden your system. For a full list of profiles supported in RHEL 9, see SCAP security profiles supported in RHEL.WarningIf not used carefully, running the system evaluation with the
--remediate
option enabled might render the system non-functional. Red Hat does not provide any automated method to revert changes made by security-hardening remediations. Remediations are supported on RHEL systems in the default configuration. If your system has been altered after the installation, running remediation might not make it compliant with the required security profile.Restart your system:
# reboot
Verification
Verify that the system is compliant with the profile, and save the results in an HTML file:
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Additional resources
-
scap-security-guide(8)
andoscap(8)
man pages - Scanning the system for security compliance and vulnerabilities
- Red Hat Insights Security Policy
- Red Hat Satellite Security Policy
8.4. Verifying USBGuard policies
With the USBGuard software framework, you can protect your systems against intrusive USB devices by using lists of permitted and forbidden devices based on the USB device authorization feature in the kernel.
Prerequisites
- You have created a rule set for USB devices that reflected the requirements of your scenario before the upgrade.
-
The
usbguard
service is installed and running on your RHEL 9 system.
Procedure
-
Back up your *.conf files stored in the
/etc/usbguard/
directory. -
Use the
usbguard generate-policy
to generate a new policy file. Note that the command generates rules for the currently present USB devices only. Compare the newly generated rules against the rules in the previous policy:
- If you identify differences in the rules for the devices that were present when you generated the new policy and the pre-upgrade rules for the same devices, modify the original rules correspondingly also for devices that might be inserted later.
- If there are no differences between the newly generated and the pre-upgrade rules, you can use the policy files created in RHEL 8 without any modification.
Additional resources
8.5. Updating fapolicyd databases
The fapolicyd
software framework controls the execution of applications based on a user-defined policy.
In rare cases, a problem with the fapolicyd
trust database format can occur. To rebuild the database:
Stop the service:
# systemctl stop fapolicyd
Delete the database:
# fapolicyd-cli –delete-db
Start the service:
# systemctl start fapolicyd
If you added custom trust files to the trust database, update them either individually by using the fapolicyd-cli -f update <FILE>
command or altogether by using fapolicyd-cli -f update
. To apply the changes, use either the fapolicyd-cli –update
command or restart the fapolicyd
service.
Additionally, custom binaries might require a rebuild for the new RHEL version. Perform any such updates before you update the fapolicyd database.
Additional resources
8.6. Updating NSS databases from DBM to SQLite
Many applications automatically convert the NSS database format from DBM to SQLite after you set the NSS_DEFAULT_DB_TYPE
environment variable to the sql
value on the system. You can ensure that all databases are converted by using the certutil
tool.
Convert your NSS databases stored in the DBM format before you upgrade to RHEL 9. In other words, perform the following steps on RHEL systems (6, 7, and 8) from which you want to upgrade to RHEL 9.
Prerequisites
-
The
nss-utils
package is installed on your system.
Procedure
Set
NSS_DEFAULT_DB_TYPE
tosql
on the system:# export NSS_DEFAULT_DB_TYPE=sql
Use the conversion command in every directory[1] that contains NSS database files in the DBM format, for example:
# certutil -K -X -d /etc/ipsec.d/
Note that you have to provide a password or a path to a password file as a value of the
-f
option if your database file is password-protected, for example:# certutil -K -X -f /etc/ipsec.d/nsspassword -d /etc/ipsec.d/
Additional resources
-
certutil(1)
man page.
/etc/pki/nssdb
directory. Other locations depend on applications you use. For example, Libreswan stores its database in the /etc/ipsec.d/
directory and Firefox uses the /home/<username>/.mozilla/firefox/
directory.
8.7. Migrating Cyrus SASL databases from the Berkeley DB format to GDBM
The RHEL 9 cyrus-sasl
package is built without the libdb
dependency, and the sasldb
plugin uses the GDBM database format instead of Berkeley DB.
Prerequisites
-
The
cyrus-sasl-lib
package is installed on your system.
Procedure
To migrate your existing Simple Authentication and Security Layer (SASL) databases stored in the old Berkeley DB format, use the
cyrusbdb2current
tool with the following syntax:# cyrusbdb2current <sasldb_path> <new_path>
Additional resources
-
cyrusbdb2current(1)
man page
Chapter 9. Troubleshooting
You can refer to the following tips to troubleshoot upgrading from RHEL 8 to RHEL 9.
9.1. Troubleshooting resources
You can refer to the following troubleshooting resources.
Console output
By default, only error and critical log level messages are printed to the console output by the Leapp
utility. To change the log level, use the --verbose
or --debug
options with the leapp upgrade
command.
-
In verbose mode,
Leapp
prints info, warning, error, and critical messages. -
In debug mode,
Leapp
prints debug, info, warning, error, and critical messages.
Logs
-
The
/var/log/leapp/leapp-upgrade.log
file lists issues found during the initramfs phase. -
The
/var/log/leapp/dnf-debugdata/
directory contains transaction debug data. This directory is present only if theleapp upgrade
command is executed with the--debug
option. -
The
/var/log/leapp/answerfile
contains questions required to be answered byLeapp
. -
The
journalctl
utility provides complete logs.
Reports
-
The
/var/log/leapp/leapp-report.txt
file lists issues found during the pre-upgrade phase. The report is also available in the web console, see Assessing upgradability and applying automated remediations through the web console. -
The
/var/log/leapp/leapp-report.json
file lists issues found during the pre-upgrade phase in a machine-readable format, which enables you to process the report using custom scripts. For more information, see Automating your Red Hat Enterprise Linux pre-upgrade report workflow.
9.2. Troubleshooting tips
You can refer to the following troubleshooting tips.
Pre-upgrade phase
- Verify that your system meets all conditions listed in Planning an upgrade.
-
Make sure you have followed all steps described in Preparing for the upgrade for example, your system does not use more than one Network Interface Card (NIC) with a name based on the prefix used by the kernel (
eth
). Make sure you have answered all questions required by
Leapp
in the/var/log/leapp/answerfile
file. If any answers are missing,Leapp
inhibits the upgrade. For example:- Are there no VDO devices on the system?
-
Make sure you have resolved all problems identified in the pre-upgrade report, located at
/var/log/leapp/leapp-report.txt
. To achieve this, you can also use the web console, as described in Assessing upgradability and applying automated remediations through the web console.
Example 9.1. Leapp answerfile
The following is an example of an unedited /var/log/leapp/answerfile
file that has one unanswered question:
[check_vdo] # Title: None # Reason: Confirmation # ========================== check_vdo.no_vdo_devices ========================= # Label: Are there no VDO devices on the system? # Description: Enter True if there are no VDO devices on the system and False continue the upgrade. If the system has no VDO devices, then it is safe to continue the upgrade. If there are VDO devices they must all be converted to LVM management before the upgrade can proceed. # Reason: Based on installed packages it is possible that VDO devices exist on the system. All VDO devices must be converted to being managed by LVM before the upgrade occurs. Because the 'vdo' package is not installed, Leapp cannot determine whether any VDO devices exist that have not yet been converted. If the devices are not converted and the upgrade proceeds the data on unconverted VDO devices will be inaccessible. If you have any doubts you should choose to install the 'vdo' package and re-run the upgrade process to check for unconverted VDO devices. If you are certain that the system has no VDO devices or that all VDO devices have been converted to LVM management you may opt to allow the upgrade to proceed. # Type: bool # Default: None # Available choices: True/False # Unanswered question. Uncomment the following line with your answer # no_vdo_devices =
The Label
field specifies the question that requires an answer. In this example, the question is Are there no VDO devices on the system?
To answer the question, uncomment the last line and enter an answer of True
or False
. In this example, the selected answer is True
:
[check_vdo]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
no_vdo_devices = True
Download phase
-
If a problem occurs during downloading RPM packages, examine transaction debug data located in the
/var/log/leapp/dnf-debugdata/
directory.
Initramfs phase
During this phase, potential failures redirect you to the Dracut shell. Check the Journal log:
# journalctl
Alternatively, restart the system from the Dracut shell using the
reboot
command and check the/var/log/leapp/leapp-upgrade.log
file.
Post-upgrade phase
- If your system seems to be successfully upgraded but booted with the old RHEL 8 kernel, restart the system and check the kernel version of the default entry in GRUB.
- Make sure you have followed the recommended steps in Verifying the post-upgrade state of the RHEL 9 system.
If your application or a service stops working or behaves incorrectly after you have switched SELinux to enforcing mode, search for denials using the ausearch, journalctl, or dmesg utilities:
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
The most common problems are caused by incorrect labeling. See Troubleshooting problems related to SELinux for more details.
9.3. Known issues
The following are Known Issues you may encounter when upgrading from RHEL 8 to RHEL 9.
- Network teaming currently does not work when the in-place upgrade is performed while Network Manager is disabled or not installed.
-
If you use an HTTP proxy, Red Hat Subscription Manager must be configured to use such a proxy, or the
subscription-manager
command must be executed with the--proxy <hostname>
option. Otherwise, an execution of thesubscription-manager
command fails. If you use the--proxy
option instead of the configuration change, the upgrade process fails becauseLeapp
is unable to detect the proxy. To prevent this problem from occurring, manually edit therhsm.conf
file as described in How to configure HTTP Proxy for Red Hat Subscription Management. (BZ#1689294) -
If your RHEL 8 system uses a device driver that is provided by Red Hat but is not available in RHEL 9,
Leapp
inhibits the upgrade. However, if the RHEL 8 system uses a third-party device driver thatLeapp
does not have data for in the/etc/leapp/files/device_driver_deprecation_data.json
file,Leapp
does not detect such a driver and proceeds with the upgrade. Consequently, the system might fail to boot after the upgrade. If the name of a third-party package (not signed by Red Hat) installed on your system is the same as the name of a package provided by Red Hat, the in-place upgrade fails. To work around this problem, choose one of the following options prior to upgrading:
- Remove the third-party package
- Replace the third-party package with the package provided by Red Hat
In RHEL 8, it is possible to manage Virtual Data Optimizer (VDO) volumes using either the VDO manager or the Logical Volume Manager (LVM). In RHEL 9, it is only possible to manage VDO volumes using LVM. To continue using VDO-managed volumes after the upgrade, import those volumes to LVM-managed VDO volumes:
- Verify that the latest versions of VDO and LVM are installed on your RHEL 8 system.
Import the VDO-managed VDO volumes to LVM-managed VDO volumes before beginning the in-place upgrade:
# lvm_import_vdo --name <volume_group_name>/<lvm_name> /dev/mapper/<vdo_name>
Replace volume_group_name with the new volume group name, lvm_name with the new name of the LVM-managed VDO volume, and vdo_name with the name of the VDO-managed volume that you are importing.
ImportantYou cannot import an LVM-managed VDO volume to a VDO-managed VDO volume. As a result, it is not possible to reverse the import procedure if you intend to access these VDO volumes through the VDO manager in the future. For more information on LVM-managed VDO volumes, see the Deduplicating and compressing logical volumes on RHEL guide.
- The in-place upgrade fails on systems with Software Redundant Array of Independent Disks (RAID). (BZ#1957192)
-
During the in-place upgrade, the
Leapp
utility usually preserves the network interface controller (NIC) names between RHEL 8 and RHEL 9. However, on some systems, for example systems with network bonding, the NIC names might need to be updated between RHEL 8 and RHEL 9. On those systems, set theLEAPP_NO_NETWORK_RENAMING=1
environment variable, perform the in-place upgrade, and then verify that your network is working as expected. If needed, manually update the network configuration. (BZ#1919382) On systems with the NSFD service running on NFS servers, a non-existent NFS partition might be incorrectly detected during the in-place upgrade, inhibiting the upgrade. To prevent this issue, stop the NFSD service before running the in-place upgrade:
# systemctl stop /proc/fs/nfsd
(BZ#2036069)
The in-place upgrade might be stopped before the upgrade is performed because the
Leapp
utility incorrectly detects that there is not enough free disk space. If your system contains partitions formatted with the XFS filesystem without ftype attributes, you can work around this issue by changing the default size in theLEAPP_OVL_SIZE
environment variable to account for, at minimum, the specified missing disk space inside the container. It is recommended to increase the default size to greater than the specified missing disk space to prevent repeated error messages. For example, if theLeapp
utility detects that an additional 400 MB is needed, increase the default size from 2048 MB to at least 2500 MB.NoteThis workaround can require a large amount of free space in the
/var
partition.If this workaround does not resolve the issue, or if your system does not contain these partitions without ftype attributes, contact Red Hat support. (BZ#1832730)
On systems with 64-bit ARM architecture, the kernel page size has changed from 64k in RHEL 8 to 4k in RHEL 9. As a result, the swap partition is not mounted automatically after the in-place upgrade. To work around this issue, manually mount the swap partition and reinitialize the swap after performing the in-place upgrade:
# swapon -a --fixpgsz
(BZ#2040470)
- The in-place upgrade breaks networking on IBM Z with RoCE Express adapters. RHEL 9.0 uses Predictable Interface Names for RoCE Express adapters. These are different from the names available in the RHEL 8.6 distribution. Therefore, existing networking configurations of RoCE Express adapters will break with the current RHEL 9 minor release if you perform an in-place upgrade from RHEL 8 to RHEL 9.
9.4. Obtaining support
You can open a support case, select RHEL 7 as the product, and provide a sosreport
from your system.
-
To generate a
sosreport
on your system, run:
# sosreport
Note that you can leave the case ID empty.
For details on generating a sosreport, see the solution What is an sosreport and how to create one in Red Hat Enterprise Linux?.
For more information on opening and managing a support case on the Customer Portal, see the article How do I open and manage a support case on the Customer Portal?.
Chapter 10. Related information
You can refer to the following instructional materials:
- Red Hat Enterprise Linux technology capabilities and limits
- Supported in-place upgrade paths for Red Hat Enterprise Linux
- Considerations in adopting RHEL 9
- Customizing your Red Hat Enterprise Linux in-place upgrade
- Automating your Red Hat Enterprise Linux pre-upgrade report workflow
- Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux
- Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades
- Upgrading from RHEL 7 to RHEL 8
- How to convert from CentOS or Oracle Linux to RHEL
- Red Hat Insights Documentation
Appendix A. RHEL 8 repositories
Before the upgrade, ensure you have appropriate repositories enabled as described in step 4 of the procedure in Preparing a RHEL 8 system for the upgrade.
If you plan to use Red Hat Subscription Manager during the upgrade, you must enable the following repositories before the upgrade by using the subscription-manager repos --enable repository_id
command:
Table A.1. RHEL 8 repositories
Architecture | Repository | Repository ID |
---|---|---|
64-bit Intel and AMD | Base |
|
Appstream |
| |
64-bit ARM | Base |
|
Extras |
| |
IBM POWER (little endian) | Base |
|
Appstream |
| |
IBM Z | Base |
|
Appstream |
|
You can enable the following repositories before the upgrade by using the subscription-manager repos --enable repository_id
command:
Table A.2. Voluntary RHEL 8 repositories
Architecture | Repository | Repository ID |
---|---|---|
64-bit Intel and AMD | Code Ready Linux Builder |
|
Supplementary |
| |
64-bit ARM | Code Ready Linux Builder |
|
Supplementary |
| |
IBM POWER (little endian) | Code Ready Linux Builder |
|
Supplementary |
| |
IBM Z | Code Ready Linux Builder |
|
Supplementary |
|
If you have enabled a RHEL 8 Code Ready Linux Builder or a RHEL 8 Supplementary repository before an in-place upgrade, Leapp
enables the RHEL 8 CodeReady Linux Builder or the RHEL 8 Supplementary repositories, respectively. For more information, see the Package manifest.
If you decide to use custom repositories, enable them per instructions in Configuring custom repositories.
Appendix B. RHEL 9 repositories
If your system is registered to the Red Hat Content Delivery Network (CDN) using the Red Hat Subscription Manager (RHSM), RHEL 9 repositories are automatically enabled during the in-place upgrade. However, on systems registered to Red Hat Satellite using RHSM, you must manually enable and synchronize both RHEL 8 and RHEL 9 repositories before running the pre-upgrade report.
Make sure to enable version 9.0 of each repository. If you have enabled only the RHEL 9 version of the repositories, the in-place upgrade is inhibited.
If you plan to use Red Hat Satellite during the upgrade, you must enable and synchronize at least the following RHEL 9 repositories before the upgrade using either the Satellite web UI or the hammer repository-set enable
and hammer product synchronize
commands:
Table B.1. RHEL 9 repositories
Architecture | Repository | Repository ID | Repository name | Release version |
---|---|---|---|---|
64-bit Intel and AMD | BaseOS |
| Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) | x86_64 9.0 |
Appstream |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) | x86_64 9.0 | |
64-bit ARM | BaseOS |
| Red Hat Enterprise Linux 9 for ARM 64 - BaseOS (RPMs) | aarch64 9.0 |
Appstream |
| Red Hat Enterprise Linux 9 for ARM 64 - AppStream (RPMs) | aarch64 9.0 | |
IBM Power (little endian) | BaseOS |
| Red Hat Enterprise Linux 9 for Power, little endian - BaseOS (RPMs) | ppc64le 9.0 |
Appstream |
| Red Hat Enterprise Linux 9 for Power, little endian - AppStream (RPMs) | ppc64le 9.0 | |
IBM Z | BaseOS |
| Red Hat Enterprise Linux 9 for IBM z Systems - BaseOS (RPMs) | s390x 9.0 |
Appstream |
| Red Hat Enterprise Linux 9 for IBM z Systems - AppStream (RPMs) | s390x 9.0 |