红帽全球峰会9.3. Known issues for the RHEL 9.7 to RHEL 10.1 upgrade
There are a variety of known issues that you might encounter when upgrading from RHEL 9.7 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, you must configure Red Hat Subscription Manager (RHSM) to use such a proxy, or you must execute the
subscription-managercommand 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)
-
The upgrade might fail if you are upgrading by using Red Hat Update Infrastructure (RHUI) with an ISO image. You can work around this issue by not using the
--isooption with the upgrade or see the Red Hat Knowledgebase solution Offline Leapp upgrade using ISO fails with "Failed to synchronize cache for repo 'rhul-microsoft-azure-rhel8', ignoring this repo. (RHEL-3296) -
If you are upgrading by using Red Hat Update Infrastructure (RHUI), files in the
/usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/directory are incorrectly reported as custom files in the pre-upgrade report. Unless you modified these files manually, you can ignore the warnings about these files in the report and the in-place upgrade will not be affected. (RHEL-40115) -
When upgrading systems by using Red Hat Upgrade Infrastructure (RHUI), the upgrade could fail if the RHUI setup of the system differs from defaults implemented in the in-place upgrade solution RHUI systems expected by the
Leapputility. To resolve this problem, configure the upgrade process to adjust it for your RHUI setup. For more information, see Using RHUI to configure an in-place upgrade.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}