9.4. Known issues for the RHEL 9.6 to RHEL 10.0 upgrade
There are a variety of known issues that you might encounter when upgrading from RHEL 9.6 to RHEL 10.1.
-
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>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)
If
dracutis configured to include the deprecatednetwork-legacymodule, the system does not boot after the upgrade. This issue often occurs on systems that have been in-place upgraded to RHEL 9. To prevent this problem, perform the following actions:-
Remove the
network-legacymodule from thedracutconfiguration. - Rebuild existing initramfs images.
Reboot the system before you start the upgrade.
For more information see the leapp upgrade fails to boot after upgrading to RHEL 10.0 Knowledgebase solution.
-
Remove the