Upgrading from RHEL 9 to RHEL 10
Instructions for an in-place upgrade from Red Hat Enterprise Linux 9 to Red Hat Enterprise Linux 10
Abstract
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We appreciate your feedback on our documentation. Let us know how we can improve it.
Submitting feedback through Jira (account required)
- Log in to the Jira website.
- Click Create in the top navigation bar
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.
Key migration terminology Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
The in-place upgrade replaces the RHEL 9 operating system on your system with a RHEL 10 version.
You can perform the in-place upgrade only from one major RHEL version to the next consecutive one, for example, RHEL 8 to RHEL 9 or RHEL 9 to RHEL 10. If you want to upgrade a system across multiple versions, such as from RHEL 8 to RHEL 10, you must perform multiple in-place upgrades to reach your target version.
Currently, you can perform an in-place upgrade from the following source RHEL 9 minor versions to the following target RHEL 10 minor versions:
| System configuration | Source OS version | Target OS version |
|---|---|---|
| RHEL | RHEL 9.6 | RHEL 10.0 |
Chapter 2. Planning an upgrade to RHEL 10 Copy linkLink copied to clipboard!
In-place upgrades allow you to upgrade to the latest version of RHEL without losing existing configurations and system subscriptions. In general, in-place upgrades are less time-consuming and costly than a fresh install of RHEL. However, not all systems are eligible for an in-place upgrade. Before beginning your upgrade from RHEL 9 to RHEL 10, review system requirements, limitations, and other considerations.
2.1. Planning an upgrade from RHEL 9 to RHEL 10 Copy linkLink copied to clipboard!
An in-place upgrade is the recommended and supported method for upgrading your system to the next major version of RHEL.
Consider the following before upgrading to RHEL 10:
Applications - You can migrate applications installed on your system by using the
Leapputility. 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.
- Boot loader - You cannot switch the boot loader from BIOS to UEFI on RHEL 9 or RHEL 10. If your RHEL 9 system uses BIOS and you want your RHEL 10 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?
- Customization - To use custom repositories, see the Configuring custom repositories Knowledgebase article.
- Downtime - The upgrade process can take from several minutes to several hours.
- 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.
-
Language - All
Leappreports, logs, and other generated documentation are in English, regardless of the language configuration. 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 10 are met.
- You have access to up-to-date content for the selected source and target OS versions. See Preparing a RHEL 9 system for the upgrade for more information.
- Public clouds - The in-place upgrade is not currently supported for on-demand Pay-As-You-Go (PAYG) instances using Red Hat Update Infrastructure (RHUI).
- Real Time for Network Functions Virtualization (NFV) in Red Hat OpenStack Platform - Upgrades on real-time systems are supported.
- RHEL for Real Time - Upgrades on real-time systems are supported.
- SAP HANA - Upgrades with SAP HANA are currently unsupported.
Satellite
- Client - If you manage your hosts through Satellite, you can upgrade multiple hosts simultaneously from RHEL 9 to RHEL 10 using the Satellite web UI. For more information, see Upgrading Hosts to Next Major Red Hat Enterprise Linux Release.
- Server and Capsule - You can upgrade Satellite Servers and Capsules starting in Satellite 6.16. For more information, see Upgrading Satellite or Capsule to RHEL 9 in-place by using Leapp.
Security - 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 10.
-
During the upgrade process, the
Leapputility sets SELinux mode to permissive. -
Leappsupports in-place upgrades of RHEL 9.6 and later systems in Federal Information Processing Standard (FIPS) 140 mode to RHEL 9 FIPS-mode-enabled systems. FIPS mode stays enabled throughout 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
Backup - You should always back up your system before 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.
- Encryption - Systems with encrypted storage can be upgraded if the storage uses the LUKS2 format configured with the Clevis TPM 2.0 token. For more information, see Configuring manual enrollment of LUKS-encrypted volumes by using a TPM 2.0 policy.
Notable known limitations of the Leapp utility include:
Known limitations - Notable known limitations of
Leappcurrently include:- 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 is supported.
- The in-place upgrade is currently unsupported for on-demand PAYG instances on the public clouds that use Red Hat Update Infrastructure (RHUI) but not Red Hat Subscription Manager (RHSM) for a RHEL subscription.
- The in-place upgrade is not supported for systems with Ansible Automation Platform installed. To use a RHEL 9 Ansible Automation Platform installation on RHEL 10, see the Red Hat Knowledgebase solution How do I migrate my Ansible Automation Platform installation from one environment to another?.
- Red Hat JBoss Enterprise Application Platform (EAP) is not supported for the upgrade to RHEL 10. You must manually install and configure JBoss EAP on your system after the upgrade.
- The Stratis filesystem is not supported for the upgrade.
You can use Red Hat Lightspeed to determine which of the systems you have registered to Red Hat Lightspeed is on a supported upgrade path to RHEL 10. Note that the Advisor recommendation considers only the RHEL 9 minor version and does not perform a pre-upgrade assessment of the system. See also Advisor-service recommendations overview.
Chapter 3. Preparing for the upgrade Copy linkLink copied to clipboard!
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 9 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-registered system for the upgrade.
3.1. Preparing a RHEL 9 system for the upgrade Copy linkLink copied to clipboard!
This procedure describes the steps that are necessary before performing an in-place upgrade to RHEL 10 by using the Leapp utility.
If you do not plan to use Red Hat Subscription Manager (RHSM) during the upgrade process, follow instructions in Performing an in-place upgrade without Red Hat Subscription Manager.
Prerequisites
- The system meets conditions listed in Planning an upgrade.
- If the system has been previously upgraded from RHEL 8 to RHEL 9, ensure that all required post-upgrade steps have been completed. For more information, see Performing post-upgrade tasks in the Upgrading from RHEL 8 to RHEL 9 guide.
- Optional: You have reviewed the best practices in The best practices and recommendations for performing RHEL Upgrade using Leapp Knowledgebase article.
- You have ensured that your system has been successfully registered to the Red Hat Content Delivery Network (CDN) or Red Hat Satellite by using RHSM.
- Satellite-registered systems only: You have completed the steps in Preparing a Satellite system for the upgrade to ensure that your system meets the requirements for the upgrade.
Procedure
-
Optional: Unmount non-system OS file systems that are not required for the upgrade and comment them out from the
/etc/fstabfile. For example, this includes file systems containing only data files unrelated to the system itself. This can reduce the amount of time needed for the upgrade process and prevent potential issues related to third-party applications that are not migrated properly during the upgrade by custom or third-party actors. If you are upgrading by using RHSM, verify that the system is registered to an account with Simple Content Access (SCA) enabled:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure you have appropriate repositories enabled. The following command enables the Base and AppStream repositories for the 64-bit Intel and AMD architectures; for other architectures, see RHEL 9 repositories.
subscription-manager repos --enable rhel-9-for-x86_64-baseos-rpms --enable rhel-9-for-x86_64-appstream-rpms
# subscription-manager repos --enable rhel-9-for-x86_64-baseos-rpms --enable rhel-9-for-x86_64-appstream-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteOptional: Enable the CodeReady Linux Builder (also known as Optional) or Supplementary repositories. For more information about the content of these repositories, see the Package manifest.
Set the system release version:
subscription-manager release --set 9.6
# subscription-manager release --set 9.6Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you use the
dnf versionlockplugin to lock packages to a specific version, clear the lock by running:dnf versionlock clear
# dnf versionlock clearCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure that you have up-to-date
leappandleapp-repositorypackages:RHEL 9.6: version
0.19.0of theleapppackage and version0.22.0of theleapp-repositorypackage.The
leapp-repositorypackage contains theleapp-upgrade-el9toel10RPM package.NoteDisconnected systems only:download the following packages from the Red Hat Customer Portal:
-
leapp -
leapp-deps -
python3-leapp -
leapp-upgrade-el9toel10 -
leapp-upgrade-el9toel10-deps
-
Install the
Leapputility:dnf install leapp-upgrade
# dnf install leapp-upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Update all packages to the latest RHEL 9 version and reboot:
dnf update reboot
# dnf update # rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Optional: Review, remediate, and then remove the
rpmnewandrpmsavefiles. If you use a configuration management system, ensure that it does not interfere with the in-place upgrade process:
-
If your configuration management system has a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the
leapp preupgradecommand. Do not enable the configuration management system until after the upgrade is complete to prevent issues during the upgrade. If your configuration management system has agentless architecture, do not execute the configuration and deployment file. For example, if your system has Ansible, do not execute an Ansible playbook during the upgrade.
WarningAutomation of the pre-upgrade and upgrade process by 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 your configuration management system has a client-server architecture, such as Puppet, Salt, or Chef, disable the system before running the
-
If you are upgrading by using an ISO image, verify that the ISO image contains the target OS version, for example, RHEL 10.0, and is saved to a persistent local mount point to ensure that the
Leapputility can access the image throughout the upgrade process.
3.2. Preparing a Satellite-registered system for the upgrade Copy linkLink copied to clipboard!
Before you can perform an in-place upgrade to RHEL 10 of a system that is registered to Satellite, you must prepare your system. Perform these 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 9 system for the upgrade.
Prerequisites
- You have administrative privileges for the Satellite Server.
- Satellite is on a version in full or maintenance support. For more information, see Red Hat Satellite Product Life Cycle and Which RHEL versions and architectures are supported as client systems managed by Red Hat Satellite server?
Procedure
- Import a subscription manifest with RHEL 9 repositories into Satellite Server. For more information, see the Managing Red Hat Subscriptions chapter in the Managing Content Guide for the particular version of Red Hat Satellite.
Enable and synchronize all required RHEL 9 and RHEL 10 repositories on the Satellite Server with the latest updates for the source and target OS versions. Required repositories must be available in the content view and enabled in the associated activation key.
NoteFor RHEL 10 repositories, enable the target OS version, for example, RHEL 10.0, of each repository. If you enable only the RHEL 10 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 9 for x86_64 - AppStream (RPMs)
rhel-9-for-x86_64-appstream-rpms
x86_64 <source_os_version>
Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)
rhel-9-for-x86_64-baseos-rpms
x86_64 <source_os_version>
Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs)
rhel-10-for-x86_64-appstream-rpms
x86_64 <target_os_version>
Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs)
rhel-10-for-x86_64-baseos-rpms
x86_64 <target_os_version>
Replace <source_os_version> and <target_os_version> with the source OS version and target OS version respectively, for example, 9.6 and 10.0.
For other architectures, see RHEL 9 repositories and RHEL 10 repositories.
For more information, see the Importing Content chapter in the Managing Content Guide for the particular version of Red Hat Satellite.
Attach the content host to a content view containing the required RHEL 9 and RHEL 10 repositories.
For more information, see the Managing Content Views chapter in the Managing Content Guide for the particular version of Red Hat Satellite.
Verification
Verify that the correct RHEL 9 and RHEL 10 repositories have been added to the correct content view on Satellite Server.
- In the Satellite web UI, navigate to Content > Lifecycle > Content Views and click the name of the content view.
Click the Repositories tab and verify that the repositories appear as expected.
NoteYou can also verify that the repositories have been added to the content view by using the following commands:
hammer repository list --search 'content_label ~ rhel-9' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment> hammer repository list --search 'content_label ~ rhel-10' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>
# hammer repository list --search 'content_label ~ rhel-9' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment> # hammer repository list --search 'content_label ~ rhel-10' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace <content_view_name> with the name of the content view, <organization> with the organization, and <lifecycle_environement> with the name of the lifecycle environment..
Verify that the correct RHEL 10 repositories are enabled in the activation key associated with the content view:
- In Satellite web UI navigate to Content > Lifecycle > Activation Keys and click the name of the activation key.
-
Click the Repository Sets tab and verify that the statuses of the required repositories are
Enabled.
Verify that all expected RHEL 9 repositories are enabled in the host. For example:
subscription-manager repos --list-enabled | grep "^Repo ID"
# subscription-manager repos --list-enabled | grep "^Repo ID" Repo ID: rhel-9-for-x86_64-baseos-rpms Repo ID: rhel-9-for-x86_64-appstream-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 4. Reviewing the pre-upgrade report Copy linkLink copied to clipboard!
To assess upgradability of your system, start the pre-upgrade process by using the leapp preupgrade command. During this phase, the Leapp utility collects data about the system, assesses upgradability, and generates a pre-upgrade report.
4.1. About the pre-upgrade report Copy linkLink copied to clipboard!
The pre-upgrade report summarizes potential problems and suggests recommended solutions. The report also helps you decide whether it is possible or advisable to proceed with the upgrade.
Reviewing a pre-upgrade report can also be useful if you want to perform a fresh installation of a RHEL 9 system instead of the in-place upgrade process.
Always review the entire pre-upgrade report, even when the report finds no inhibitors to the upgrade. The pre-upgrade report contains recommended actions to complete before the upgrade to ensure that the upgraded system functions correctly.
The pre-upgrade assessment does not modify the system configuration, but it does consume non-negligible space in the /var/lib/leapp directory. In most cases, the pre-upgrade assessment requires up to 4 GB of space, but the actual size depends on your system configuration. If there is not enough space in the hosted file system, the pre-upgrade report might not show complete results of the analysis. To prevent issues, ensure that your system has enough space in the /var/lib/leapp directory or move the directory to a dedicated partition so that space consumption does not affect other parts of the system.
You can assess upgradability in the pre-upgrade phase using either of the following ways:
-
Review the pre-upgrade report in the generated
leapp-report.txtfile and manually resolve reported problems using the command line. - Use the web console to review the report, apply automated remediations where available, and fix remaining problems using the suggested remediation hints.
You can process the pre-upgrade report by 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.
The pre-upgrade report cannot simulate the entire in-place upgrade process and therefore cannot identify all inhibiting problems with your system. As a result, the Leapp utility might still terminate your in-place upgrade even after you have reviewed and remediated all problems in the report. For example, the pre-upgrade report cannot detect issues related to broken package downloads.
4.2. Assessing upgradability of RHEL 9 to RHEL 10 from the command line Copy linkLink copied to clipboard!
You can identify potential upgrade problems during the pre-upgrade phase before the upgrade by using the command line.
Prerequisites
- You completed the in Preparing for the upgrade procedure.
You are logged in as the root user with the unconfined SELinux role.
NoteIf you use the
sudocommand, you must use the-r unconfined_r -t unconfined_toptions when entering eachleappcommand, for example:sudo -r unconfined_r -t unconfined_t leapp preupgrade
$ sudo -r unconfined_r -t unconfined_t leapp preupgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
On your RHEL 9 system, perform the pre-upgrade phase:
leapp preupgrade --target <_target_os_version_>
# leapp preupgrade --target <_target_os_version_>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace target_os_version with the target OS version, for example
10.0. If no target OS version is defined,Leappuses the default target OS version specified in the table 1.1 in Supported upgrade paths.If you are using 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> ...
# leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace repository_id with the repository IDs.
-
If you are upgrading without RHSM or by using RHUI, add the
--no-rhsmoption. -
If you have an Extended Upgrade Support (EUS) or Advanced Update Support (AUS) subscription, add the
--channel <channel>option. Replace <channel> with the channel name, for example,eusoraus. If you are using RHEL for Real Time or the Real Time for Network Functions Virtualization (NFV) in your Red Hat OpenStack Platform, enable the deployment by using the
--enablerepooption. For example:leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpms
# leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information, see Configuring Real-Time Compute.
Examine the report in the
/var/log/leapp/leapp-report.txtfile and manually resolve all the reported problems. Some reported problems contain remediation suggestions. Inhibitor problems prevent you from upgrading until you have resolved them.The report contains the following risk factor levels:
- 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.
In certain system configurations, the
Leapputility generates true or false questions that you must answer manually. If the pre-upgrade report contains a Missing required answers in the answer file message, complete the following steps:-
Open the
/var/log/leapp/answerfilefile and review the true or false questions. Manually edit the
/var/log/leapp/answerfilefile, uncomment the confirm line of the file by deleting the#symbol, and confirm your answer asTrueorFalse. For more information, see the Troubleshooting tips.NoteAlternatively, you can answer the true or false question by running the following command:
leapp answer --section <question_section>.<field_name>=<answer>
# leapp answer --section <question_section>.<field_name>=<answer>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Open the
- Repeat the previous steps to rerun the pre-upgrade report to verify that you have resolved all critical issues.
4.3. Assessing upgradability of RHEL 9 to RHEL 10 and applying automated remediations through the web console Copy linkLink copied to clipboard!
You can identify potential problems in the pre-upgrade phase before the upgrade and apply automated remediations by using the web console. See Getting started using the RHEL web console for more information about the web console.
Prerequisites
- You completed the in Preparing for the upgrade procedure.
You are logged in as the root user with the unconfined SELinux role.
NoteIf you use the
sudocommand, you must use the-r unconfined_r -t unconfined_toptions when entering eachleappcommand, for example:sudo -r unconfined_r -t unconfined_t leapp preupgrade
$ sudo -r unconfined_r -t unconfined_t leapp preupgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
Install the
cockpit-leappplug-in:dnf install cockpit-leapp
# dnf install cockpit-leappCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Log in to the web console as
rootor as a user that has permissions to enter administrative commands withsudo. On your RHEL 9 system, perform the pre-upgrade phase either from the command line or from the web console terminal:
leapp preupgrade --target <target_os_version>
# leapp preupgrade --target <target_os_version>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace target_os_version with the target OS version, for example
10.0. If no target OS version is defined,Leappuses the default target OS version specified in the table 1.1 in Supported upgrade paths.If you are using 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> ...
# leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
If you are upgrading without RHSM or by using RHUI, add the
--no-rhsmoption. -
If you have an Extended Upgrade Support (EUS) or Advanced Update Support (AUS) subscription, add the
--channel <channel>option. Replace <channel> with the channel name, for example,eusor`aus`. If you are using RHEL for Real Time or the Real Time for Network Functions Virtualization (NFV) in your Red Hat OpenStack Platform, enable the deployment by using the
--enablerepooption. For example:leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpms
# leapp preupgrade --enablerepo rhel-10-for-x86_64-rt-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information, see Configuring Real-Time Compute.
In the web console, select Upgrade Report from the navigation menu to review all reported problems. Inhibitor problems prevent you from upgrading until you have resolved them. To view a problem in detail, select the row to open the Detail pane.
Figure 4.1. In-place upgrade report in the web console
The report contains the following risk factor levels:
- 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.
In certain configurations, the
Leapputility generates true or false questions that you must answer manually. If the Upgrade Report contains a Missing required answers in the answer file row, complete the following steps:- Select the Missing required answers in the answer file row to open the Detail pane. The default answer is stated at the end of the remediation command.
- To confirm the default answer, select Add to Remediation Plan to start the remediation later or Run Remediation to start the remediation immediately.
To select the non-default answer instead, run the
leapp answercommand in the terminal, specifying the question you are responding to and your confirmed answer.leapp answer --section <question_section>.<field_name>=<answer>
# leapp answer --section <question_section>.<field_name>=<answer>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteYou can also manually edit the
/var/log/leapp/answerfilefile, uncomment the confirm line of the file by deleting the#symbol, and confirm your answer asTrueorFalse. For more information, see the Troubleshooting tips.
Some problems have remediation commands that you can run to automatically resolve the problems. You can run remediation commands individually or all together in the remediation command.
- To run a single remediation command, open the Detail pane for the problem and click Run Remediation.
To add a remediation command to the remediation plan, open the Detail pane for the problem and click Add to Remediation Plan.
Figure 4.2. Detail pane
- To run the remediation plan containing all added remediation commands, click the Remediation plan link in the top right corner above the report. Click Execute Remediation Plan to run all listed commands.
- After reviewing the report and resolving all reported problems, repeat steps 3-7 to rerun the report to verify that you have resolved all critical issues.
Chapter 5. Performing the upgrade Copy linkLink copied to clipboard!
After you have completed the preparatory steps and reviewed and resolved the problems found in the pre-upgrade report, you can perform the in-place upgrade on your system.
5.1. Performing the upgrade from RHEL 9 to RHEL 10 Copy linkLink copied to clipboard!
This procedure lists steps required to perform the upgrade frp, RHEL 9 to RHEL 10 by using the Leapp utility.
Prerequisites
- You completed the Preparing for the upgrade procedure, including a full system backup.
- You completed the Reviewing the pre-upgrade report procedure and all reported issues resolved.
- You have temporarily disabled antivirus software to prevent the upgrade from failing.
Procedure
You completed the Ensure that you have a full system backup or a virtual machine snapshot. You can use the following backup options:
- Create a full backup of your system by using 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?.
Create a snapshot of your system by using LVM snapshots or RAID splitting. In case of upgrading a virtual machine, you can create a snapshot of the whole VM. You can also manage snapshot and rollback boot entries by using the Boom utility. For more information, see What is BOOM and how to install it? and Managing system upgrades with snapshots.
NoteBecause LVM snapshots do not create a full backup of your system, you might not be able to recover your system after certain upgrade failures. As a result, it is safer to create a full backup by using the ReaR utility.
On your RHEL 9 system, start the upgrade process:
leapp upgrade --target <_target_os_version_>
# leapp upgrade --target <_target_os_version_>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace target_os_version with the target OS version, for example
10.0. If no target OS version is defined,Leappuses the default target OS version specified in the table 1.1 in Supported upgrade paths.If you are using custom repositories from the
/etc/yum.repos.d/directory for the upgrade, enable the selected repositories as follows:leapp upgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...
# leapp upgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
If you are upgrading without RHSM or using RHUI, add the
--no-rhsmoption. -
If you are upgrading by using an ISO image, add the
--no-rhsmand--iso <file_path>options. Replace <file_path> with the file path to the saved ISO image, for example/home/rhel9.iso. -
If you have an Extended Upgrade Support (EUS) or Advanced Update Support (AUS) subscription, add the
--channel channeloption. Replace channel with the value you used with theleapp preupgradecommand, for example,eusoraus. Note that you must use the same value with the--channeloption in both theleapp preupgradeandleapp upgradecommands. If you are using RHEL for Real Time or the Real Time for Network Functions Virtualization (NFV) in your Red Hat OpenStack Platform, enable the deployment by using the
--enablerepooption. For example:leapp upgrade --enablerepo rhel-10-for-x86_64-rt-rpms
# leapp upgrade --enablerepo rhel-10-for-x86_64-rt-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information, see Configuring Real-Time Compute.
At the beginning of the upgrade process,
Leapprepeats the pre-upgrade phase described in Reviewing the pre-upgrade report.-
If the system is upgradable,
Leappdownloads necessary data and prepares an RPM transaction for the upgrade. -
If your system does not meet the parameters for a reliable upgrade,
Leappterminates the upgrade process and provides a record describing the issue and a recommended solution in the/var/log/leapp/leapp-report.txtfile. For more information, see Troubleshooting.
-
If the system is upgradable,
Manually restart the system:
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow In this phase, the system boots into a RHEL 10-based initial RAM disk image, initramfs.
Leappupgrades all packages and automatically restarts to the RHEL 10 system.Alternatively, you can run the
leapp upgradecommand with the--rebootoption and skip this manual step.If a failure occurs, investigate logs and known issues as described in Troubleshooting.
- Log in to the RHEL 10 system and verify its state as described in Verifying the post-upgrade state.
- Perform all post-upgrade tasks described in the upgrade report and in Performing post-upgrade tasks.
Chapter 6. Verifying the post-upgrade state Copy linkLink copied to clipboard!
After performing the in-place upgrade to RHEL 10, verify that the system is in the correct state. Doing so allows you to identify and correct any critical errors that could impact your system.
6.1. Verifying the post-upgrade state of the RHEL 10 system Copy linkLink copied to clipboard!
After the upgrade to RHEL 10 is completed, determine whether the system is in the required state.
Prerequisites
- The system has been upgraded following the steps described in Performing the upgrade and you have been able to log in to RHEL 10.
Procedure
Verify that the current OS version is RHEL 10. For example:
cat /etc/redhat-release Red Hat Enterprise Linux release 10.0 (Coughlan)
# cat /etc/redhat-release Red Hat Enterprise Linux release 10.0 (Coughlan)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check the OS kernel version. For example:
uname -r
# uname -r 6.12.0-55.2.1.el10_0.x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note that
.el10is important and the version should not be earlier than 6.12.0.If you are using the Red Hat Subscription Manager:
Verify that the correct product is installed. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the release version is set to the expected target OS version immediately after the upgrade. For example:
subscription-manager release
# subscription-manager release Release: 10.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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 might 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 on the RHEL 10 system Copy linkLink copied to clipboard!
After the in-place upgrade, clean up your RHEL 10 system by removing unneeded packages, disable incompatible repositories, and update the rescue kernel and initial RAM disk.
7.1. Performing post-upgrade tasks Copy linkLink copied to clipboard!
After performing the upgrade to RHEL 10, complete the following recommended major tasks.
Prerequisites
*You completed the Performing the upgrade procedure and you have been able to log in to RHEL 10.
- You verified the status of the in-place upgrade as described in Verifying the post-upgrade state.
Procedure
Remove any remaining
Leapppackages from the exclude list in the/etc/dnf/dnf.confconfiguration file, including thesnactorpackage, which is a tool for upgrade extension development. During the in-place upgrade,Leapppackages that were installed with theLeapputility are automatically added to the exclude list to prevent critical files from being removed or updated. After the in-place upgrade, theseLeapppackages 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.confconfiguration file and remove the desiredLeapppackages from the exclude list. To remove all packages from the exclude list:
dnf config-manager --save --setopt exclude=''
# dnf config-manager --save --setopt exclude=''Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
To manually remove packages from the exclude list, edit the
Remove remaining RHEL 9 packages, including remaining
Leapppackages.Locate remaining RHEL 9 packages:
rpm -qa | grep -e '\.el[789]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
# rpm -qa | grep -e '\.el[789]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sortCopy to Clipboard Copied! Toggle word wrap Toggle overflow Remove remaining RHEL 9 packages from your RHEL 10 system. To ensure that RPM dependencies are maintained, use
DNFwhen performing this action. Review the transaction before accepting to ensure no packages are unintentionally removed.For example:
dnf remove $(rpm -qa | grep \.el[789] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')
# dnf remove $(rpm -qa | grep \.el[789] | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Remove remaining
Leappdependency packages:dnf remove leapp-deps-el10 leapp-repository-deps-el10
# dnf remove leapp-deps-el10 leapp-repository-deps-el10Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Optional: Remove all remaining upgrade-related data from the system:
rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp
# rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leappCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantRemoving this data might limit Red Hat Support’s ability to investigate and troubleshoot post-upgrade problems.
Disable DNF repositories whose packages are not RHEL 10-compatible. Repositories managed by RHSM are handled automatically. To disable these repositories:
dnf config-manager --set-disabled <repository_id>
# dnf config-manager --set-disabled <repository_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace repository_id with the repository ID.
Replace the old rescue kernel and initial RAM disk with the current kernel and disk:
Remove the existing rescue kernel and initial RAM disk:
rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*
# rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*Copy to Clipboard Copied! Toggle word wrap Toggle overflow Reinstall the rescue kernel and related initial RAM disk:
/usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"
# /usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow If your system is on the IBM Z architecture, update the
ziplboot loader:zipl
# ziplCopy to Clipboard Copied! Toggle word wrap Toggle overflow
. Optional: Check existing configuration files:
-
Review, remediate, and then remove the
rpmnew,rpmsave, andleappsavefiles. Note thatrpmsaveandleappsaveare equivalent and can be handled similarly. For more information, see What are rpmnew & rpmsave files? -
Remove configuration files for RHEL 9 DNF modules from the
/etc/dnf/modules.d/directory that are no longer valid. Note that these files have no effect on the system when related DNF modules do not exist.
-
Review, remediate, and then remove the
- Re-evaluate and re-apply your security policies. Especially, change the SELinux mode to enforcing. For details, see Applying security policies.
Verification
Verify that the previously removed rescue kernel and rescue initial RAM disk files have been created for the current kernel:
ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"
# ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* # lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the rescue boot entry refers to the existing rescue files. See the
grubbyoutput:grubby --info /boot/vmlinuz-*rescue*
# grubby --info /boot/vmlinuz-*rescue*Copy to Clipboard Copied! Toggle word wrap Toggle overflow Review the
grubbyoutput and verify that no RHEL 9 boot entries are configured:grubby --info ALL
# grubby --info ALLCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that no files related to previous RHEL are present in the
/boot/loader/entriesfile:grep -r ".el9" "/boot/loader/entries/" || echo "Everything seems ok."
# grep -r ".el9" "/boot/loader/entries/" || echo "Everything seems ok."Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 8. Applying security policies Copy linkLink copied to clipboard!
During the in-place upgrade process, the Leapp utility must switch the SELinux policy to permissive mode. Furthermore, security profiles might contain changes between major releases. To restore system security, switch SELinux to enforcing mode again and verify the system-wide cryptographic policy. You may also want to remediate the system to be compliant with a specific security profile. Also, some security-related components require pre-update steps for a correct upgrade.
8.1. Changing SELinux mode to enforcing Copy linkLink copied to clipboard!
During the in-place upgrade process, the Leapp utility sets SELinux mode to permissive. After you finish the system upgrade, you must manually change SELinux mode to enforcing.
Prerequisites
- The system has been upgraded and you have performed the Verification described in Verifying the post-upgrade state.
Procedure
Ensure that there are no SELinux denials, for example, by using the
ausearchutility:ausearch -m AVC,USER_AVC -ts boot
# ausearch -m AVC,USER_AVC -ts bootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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/configfile in a text editor of your choice, for example:vi /etc/selinux/config
# vi /etc/selinux/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure the
SELINUX=enforcingoption:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Save the change, and restart the system:
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
After the system restarts, confirm that the
getenforcecommand returnsEnforcing:getenforce
$ getenforce EnforcingCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. System-wide cryptographic policies Copy linkLink copied to clipboard!
The system-wide cryptographic policies component 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 9. For example, if you used the DEFAULT cryptographic policy in RHEL 9, your system upgraded to RHEL 10 also uses DEFAULT. Note that specific settings in predefined policies differ, and RHEL 10 cryptographic policies contain more strict and more secure default values. See the Using system-wide cryptographic policies 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
$ 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
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
You can also customize system-wide cryptographic policies. For details, see the Customizing system-wide cryptographic policies with subpolicies 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.
8.3. Upgrading a system hardened to a security baseline Copy linkLink copied to clipboard!
To get a fully hardened system after a successful upgrade to RHEL 10, 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 9 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 RHEL 10 during the upgrade.
You cannot use the same SCAP content for scanning RHEL 9 and RHEL 10. Update the management platforms if the compliance of the system is managed by tools such as Red Hat Satellite or Red Hat Lightspeed.
As an alternative to automated remediations, you can make the changes manually by following an OpenSCAP-generated report. For information about generating a compliance report, see Scanning the system for configuration compliance.
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-guidepackage is installed on your RHEL 10 system.
Procedure
Find the appropriate security compliance data stream
.xmlfile:ls /usr/share/xml/scap/ssg/content/
$ ls /usr/share/xml/scap/ssg/content/ ... ssg-rhel10-ds.xml ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow See the Viewing profiles for configuration compliance section for more information.
Remediate the system according to the selected profile from the appropriate data stream:
oscap xccdf eval --profile <profile_ID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
# oscap xccdf eval --profile <profile_ID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<profile_ID>with the ID of the profile according to which you want to harden your system. For a full list of profiles supported in RHEL 10, see SCAP Security Guide profiles supported in RHEL 10.WarningIf not used carefully, running the system evaluation with the
--remediateoption 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
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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-rhel10-ds.xml
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. Verifying USBGuard policies Copy linkLink copied to clipboard!
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
usbguardservice is installed and running on your RHEL 10 system.
Procedure
-
Back up your *.conf files stored in the
/etc/usbguard/directory. -
Use the
usbguard generate-policyto 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 9 without any modification.
8.5. Updating fapolicyd databases Copy linkLink copied to clipboard!
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
# systemctl stop fapolicydCopy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the database:
fapolicyd-cli --delete-db
# fapolicyd-cli --delete-dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the service:
systemctl start fapolicyd
# systemctl start fapolicydCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
Chapter 9. Troubleshooting Copy linkLink copied to clipboard!
The in-place upgrade is a complex process, and it is common to encounter issues and roadblocks. Refer to the following troubleshooting resources and tips for help on resolving these issues.
9.1. Troubleshooting resources Copy linkLink copied to clipboard!
The following troubleshooting resources can help you diagnose and troubleshoot issues you encounter throughout the upgrade process.
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,
Leappprints info, warning, error, and critical messages. -
In debug mode,
Leappprints debug, info, warning, error, and critical messages.
Logs
-
The
/var/log/leapp/leapp-upgrade.logfile 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 upgradecommand is executed with the--debugoption. -
The
/var/log/leapp/answerfilecontains questions required to be answered byLeapp. -
The
journalctlutility provides complete logs.
Reports
-
The
/var/log/leapp/leapp-report.txtfile 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.jsonfile 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 Copy linkLink copied to clipboard!
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
Leappin the/var/log/leapp/answerfilefile. If any answers are missing,Leappinhibits 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:
The Label field specifies the question that requires an answer. In this example, the question is Are all VDO devices, if any, successfully converted to LVM management?
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 confirm = True
[check_vdo]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True
Download phase
If a problem occurs during downloading RPM packages, examine transaction debug data located in the
/var/log/leapp/dnf-debugdata/directory.NoteThe
/var/log/leapp/dnf-debugdata/directory is empty or does not exist if no transaction debug data was produced. This might occur when the required repositories are not available.
Initramfs phase
During this phase, potential failures redirect you to the Dracut shell. Check the Journal log:
journalctl
# journalctlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, restart the system from the Dracut shell using the
rebootcommand and check the/var/log/leapp/leapp-upgrade.logfile.
Post-upgrade phase
- If your system seems to be successfully upgraded but booted with the old RHEL 9 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.
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, ordmesgutilities:ausearch -m AVC,USER_AVC -ts boot journalctl -t setroubleshoot dmesg | grep -i -e selinux -e type=1400
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400Copy to Clipboard Copied! Toggle word wrap Toggle overflow The most common problems are caused by incorrect labeling. See Troubleshooting problems related to SELinux for more details.
9.3. Known issues for the RHEL 9 to RHEL 10 upgrade Copy linkLink copied to clipboard!
The following are Known Issues you may encounter when upgrading.
-
If your RHEL 9 system uses a device driver that is provided by Red Hat but is not available in RHEL 10,
Leappinhibits the upgrade. However, if the RHEL 9 system uses a third-party device driver thatLeappdoes not have data for in the/etc/leapp/files/device_driver_deprecation_data.jsonfile,Leappdoes 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
- The in-place upgrade might fail on systems with Software Redundant Array of Independent Disks (RAID). (BZ#1957192)
During the in-place upgrade, the
Leapputility usually preserves the network interface controller (NIC) names between RHEL 9 and RHEL 10. However, on some systems, such as systems with network bonding, the NIC names might need to be updated between RHEL 9 and RHEL 10. On those systems, perform the following steps:-
Set the
LEAPP_NO_NETWORK_RENAMING=1environment variable to prevent the Leapp utility from incorrectly preserving the original RHEL 9 NIC names. - Perform the in-place upgrade.
Verify that your network is working correctly. If needed, manually update the network configuration.
(BZ#1919382)
-
Set the
If any of the mounted file systems that are defined in the
/etc/fstabfile do not have thesharedpropagation flag set, the upgrade might fail. To prevent this issue, remount these file systems to set them as shared:mount -o remount --make-shared <mountpoint>
# mount -o remount --make-shared <mountpoint>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace mountpoint with the mountpoint of each file system.
For more information, see the Red Hat Knowledgebase solution Leapp "Can not load RPM file" during the DNF transaction check. (RHEL-23449)
-
If you use an HTTP proxy, Red Hat Subscription Manager must be configured to use such a proxy, or the
subscription-managercommand must be executed with the--proxy <hostname>option. Otherwise, an execution of thesubscription-managercommand fails. If you use the--proxyoption instead of the configuration change, the upgrade process fails becauseLeappis unable to detect the proxy. To prevent this problem from occurring, manually edit therhsm.conffile. For more information, see the Red Hat Knowledgebase solution How to configure HTTP Proxy for Red Hat Subscription Management. (BZ#1689294) -
For systems that require a proxy to access RHEL 9 content, you usually need to configure the use of the proxy by DNF in the
/etc/dnf/dnf.confconfiguration file. If the current DNF configuration is not compatible with the DNF version on the target system, specify the valid target configuration in the/etc/leapp/files/dnf.confconfiguration file. For more information, see the Red Hat Knowledgebase solution How does Leapp work with a proxy?
-
The kerberos client might break after the upgrade if it is configured to use the deprecated
/etc/ssl/certs/ca-certificates.crtfile for root certificates. To fix the configuration, use the/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pemfile instead. (RHEL-65265) - On IBM Z machines, the upgrade might fail if the system is on multipath LVM SCSI LUNs. (RHEL-76159)
9.4. Obtaining support Copy linkLink copied to clipboard!
To open a support case, select RHEL 9 as the product, and provide a sosreport from your system.
-
To generate a
sosreporton your system, run:
sosreport
# sosreport
Note that you can leave the case ID empty.
For more information about generating a sosreport, see the Red Hat Knowledgebase solution What is an sosreport and how to create one in Red Hat Enterprise Linux?.
For more information about opening and managing a support case on the Customer Portal, see the Red Hat Knowledgebase solution, How do I open and manage a support case on the Customer Portal?.
Appendix A. RHEL 9 repositories Copy linkLink copied to clipboard!
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 9 and RHEL 10 repositories before running the pre-upgrade report.
Make sure to enable the source OS version of each repository, for example 9.6. 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:
| 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 <source_os_version> |
| AppStream |
| Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) | x86_64 <source_os_version> | |
| 64-bit ARM | BaseOS |
| Red Hat Enterprise Linux 9 for ARM 64 - BaseOS (RPMs) | aarch64 <source_os_version> |
| AppStream |
| Red Hat Enterprise Linux 9 for ARM 64 - AppStream (RPMs) | aarch64 <source_os_version> | |
| IBM Power (little endian) | BaseOS |
| Red Hat Enterprise Linux 9 for Power, little endian - BaseOS (RPMs) | ppc64le <source_os_version> |
| AppStream |
| Red Hat Enterprise Linux 9 for Power, little endian - AppStream (RPMs) | ppc64le <source_os_version> | |
| IBM Z | BaseOS |
| Red Hat Enterprise Linux 9 for IBM z Systems - BaseOS (RPMs) | s390x <source_os_version> |
| AppStream |
| Red Hat Enterprise Linux 9 for IBM z Systems - AppStream (RPMs) | s390x <source_os_version> |
Replace <source_os_version> with the source OS version, for example 9.6.
Appendix B. RHEL 10 repositories Copy linkLink copied to clipboard!
If your system is registered to the Red Hat Content Delivery Network (CDN) by using the Red Hat Subscription Manager (RHSM), RHEL 10 repositories are automatically enabled during the in-place upgrade. However, on systems registered to Red Hat Satellite by using RHSM, you must manually enable and synchronize both RHEL 9 and RHEL 10 repositories before running the pre-upgrade report.
Make sure to enable the target OS version of each repository, for example 10.0. If you have enabled only the RHEL 10 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 10 repositories before the upgrade by using either the Satellite web UI or the hammer repository-set enable and hammer product synchronize commands:
| Architecture | Repository | Repository ID | Repository name | Release version |
|---|---|---|---|---|
| 64-bit Intel and AMD | BaseOS |
| Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs) | x86_64 <target_os_version> |
| AppStream |
| Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs) | x86_64 <target_os_version> | |
| 64-bit ARM | BaseOS |
| Red Hat Enterprise Linux 10 for ARM 64 - BaseOS (RPMs) | aarch64 <target_os_version> |
| AppStream |
| Red Hat Enterprise Linux 10 for ARM 64 - AppStream (RPMs) | aarch64 <target_os_version> | |
| IBM Power (little endian) | BaseOS |
| Red Hat Enterprise Linux 10 for Power, little endian - BaseOS (RPMs) | ppc64le <target_os_version> |
| AppStream |
| Red Hat Enterprise Linux 10 for Power, little endian - AppStream (RPMs) | ppc64le <target_os_version> | |
| IBM Z | BaseOS |
| Red Hat Enterprise Linux 10 for IBM z Systems - BaseOS (RPMs) | s390x <target_os_version> |
| AppStream |
| Red Hat Enterprise Linux 10 for IBM z Systems - AppStream (RPMs) | s390x <target_os_version> |
Replace <target_os_version> with the target OS version, for example 10.0.