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 the leapp upgrade command is executed with the --debug option. The /var/log/leapp/answerfile contains questions required to be answered by Leapp . 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: 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 : Download phase If a problem occurs during downloading RPM packages, examine transaction debug data located in the /var/log/leapp/dnf-debugdata/ directory. Note The /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: 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 . 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: 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 8.10 to RHEL 9.4 and 9.5 upgrade The following are Known Issues you may encounter when upgrading. Network teaming currently does not work when the in-place upgrade is performed while Network Manager is disabled or not installed. 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 that Leapp 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, you can manage Virtual Data Optimizer (VDO) volumes by using either the VDO manager or the Logical Volume Manager (LVM). In RHEL 9, it is only possible to manage VDO volumes by using LVM. To continue using VDO-managed volumes on RHEL 9, import those volumes to LVM-managed VDO volumes before the upgrade. For more information, see Importing existing VDO volumes to LVM . The in-place upgrade might fail 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, such as systems with network bonding, the NIC names might need to be updated between RHEL 8 and RHEL 9. On those systems, perform the following steps: Set the LEAPP_NO_NETWORK_RENAMING=1 environment variable to prevent the Leapp utility from incorrectly preserving the original RHEL 8 NIC names. Perform the in-place upgrade. Verify that your network is working correctly. If needed, manually update the network configuration. (BZ# 1919382 ) If your system boots by using BIOS, the in-place upgrade fails when upgrading the GRUB boot loader if the boot disk's embedding area does not contain enough space for the core image installation. This results in a broken system, and can occur when the disk has been partitioned manually, for example using the RHEL 6 fdisk utility. To verify whether this issue affects you, perform the following steps: Determine which sector starts the first partition on the disk with the installed boot loader: The standard partitioning, which ensures enough space for the core image, starts on sector 2048. Determine whether the starting sector provides enough space. The RHEL 9.0 core image requires at least 36 KiB. For example, if the sector size is the standard 512 bytes, then starting on sector 73 or lower would not provide enough space. Note The RHEL 9 core image might be larger than 36 KiB and require a higher starting sector. Always verify how much space the current RHEL 9 core requires. If the embedding area does not contain enough storage space, perform a fresh installation of the RHEL 9 system instead of performing an in-place upgrade. (BZ# 2181380 ) After the in-place upgrade, SSH keys are no longer auto-generated if the system meets the following conditions: The system is on a cloud. The cloud-init package is installed. The ssh_genkeytypes configuration is set to ~ in the /etc/cloud/cloud.cfg file, which is the default. This issue prevents the system from connecting by using SSH if the original keys have been removed. For more information about preventing this issue, see the Red Hat Knowledgebase solution Unable to SSH to new Virtual Machine after upgrading the template to RHEL 8.7 or 9 . (BZ# 2210012 ) VMWare virtual machines that were created at Hardware Level 13 and are booting with UEFI might experience issues during the upgrade because the NVRAM file is too small. For more information, see the Red Hat Knowledgebase solution VMWare: Getting "No space left on device" when executing efibootmgr or mokutil command to add entries . ( RHEL-3362 ) The upgrade might fail if you are upgrading by using RHUI with an ISO image. You can work around this issue by not using the --iso option 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 too many file systems are mounted, the pre-upgrade process might fail with the following error message: If this issue occurs, complete the following steps: Unmount any file systems that are not related to the system partitions and are not needed during the upgrade process. Comment out the unmounted file systems' entries in the /etc/fstab file to prevent them from being mounted during the upgrade process. Restore the original file system configuration after the upgrade. ( RHEL-3320 ) If any of the mounted file systems that are defined in the /etc/fstab file do not have the shared propagation flag set, the upgrade might fail. To prevent this issue, remount these file systems to set them as shared: 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 ) The upgrade might fail if limited resources have been set for the upgrade process. For example, the maximum number of open files descriptors and maximum size of files written by the process and its children attributes can be reached by the upgrade process if they are set. To prevent these issues, increase or remove these limits before the upgrade process. For more information, see the Red Hat Knowledgebase solution Why does leapp preupgrade fail with sqlite3.OperationalError: unable to open database file traceback error ? and Ensure that there is enough diskspace in /var/lib/leapp/scratch/diskimages/root_boot at least XXX mib are needed . ( RHEL-16881 , RHEL-26459 ) In-place upgrades using Red Hat Update Infrastructure (RHUI) on Amazon Web Services (AWS) with the ARM architecture are currently experiencing issues. Use the Red Hat Subscription Management (RHSM) instead. ( RHEL-38909 ) If you are upgrading by using 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 ) By default, the logrotate is not active after the upgrade. The logrotate was previously managed by cron in RHEL 8 and earlier. In RHEL 9, it is managed by systemd . To activate logrotate persistently, run the following command after the upgrade: 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 the subscription-manager command fails. If you use the --proxy option instead of the configuration change, the upgrade process fails because Leapp is unable to detect the proxy. To prevent this problem from occurring, manually edit the rhsm.conf file. 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.conf configuration 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.conf configuration file. For more information, see the Red Hat Knowledgebase solution How does Leapp work with a proxy? The upgrade might fail with a MountError message when all of the following conditions are met: A mount point that is defined in /etc/fstab contains underscore characters. Another mount point defined in /etc/stab has the same name if the underscore character is replaced with a forward slash. For example, having both /var/tmp and /var_tmp mount points defined in /etc/fstab causes the upgrade to fail. To prevent this problem, unmount the mount point that contains underscore characters, and comment that mount point out from the /etc/fstab file before the upgrade. You can restore the configuration after the upgrade. ( RHEL-62737 ) 9.4. Known issues for the RHEL 8.8 to RHEL 9.2 upgrade The following are Known Issues you may encounter when upgrading from RHEL 8.8 to RHEL 9.2. Network teaming currently does not work when the in-place upgrade is performed while Network Manager is disabled or not installed. 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 that Leapp 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, you can manage Virtual Data Optimizer (VDO) volumes by using either the VDO manager or the Logical Volume Manager (LVM). In RHEL 9, it is only possible to manage VDO volumes by using LVM. To continue using VDO-managed volumes on RHEL 9, import those volumes to LVM-managed VDO volumes before the upgrade. For more information, see Importing existing VDO volumes to LVM . The in-place upgrade might fail 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, such as systems with network bonding, the NIC names might need to be updated between RHEL 8 and RHEL 9. On those systems, perform the following steps: Set the LEAPP_NO_NETWORK_RENAMING=1 environment variable to prevent the Leapp utility from incorrectly preserving the original RHEL 8 NIC names. Perform the in-place upgrade. Verify that your network is working correctly. If needed, manually update the network configuration. (BZ# 1919382 ) The in-place upgrade might fail if there is not enough available disk space. The error messages and logs might contain misleading or invalid information about the problem and resolution. For more information about resolving this issue, see the Red Hat Knowledgebase solution leapp fails with "There is not enough space on the file system hosting /var/lib/leapp directory to extract the packages" . (BZ# 1832730 , BZ# 2210300 ) If your system boots by using BIOS, the in-place upgrade fails when upgrading the GRUB boot loader if the boot disk's embedding area does not contain enough space for the core image installation. This results in a broken system, and can occur when the disk has been partitioned manually, for example using the RHEL 6 fdisk utility. To verify whether this issue affects you, perform the following steps: Determine which sector starts the first partition on the disk with the installed boot loader: The standard partitioning, which ensures enough space for the core image, starts on sector 2048. Determine whether the starting sector provides enough space. The RHEL 9.0 core image requires at least 36 KiB. For example, if the sector size is the standard 512 bytes, then starting on sector 73 or lower would not provide enough space. Note The RHEL 9 core image might be larger than 36 KiB and require a higher starting sector. Always verify how much space the current RHEL 9 core requires. If the embedding area does not contain enough storage space, perform a fresh installation of the RHEL 9 system instead of performing an in-place upgrade. (BZ# 2181380 ) After the in-place upgrade, SSH keys are no longer auto-generated if the system meets the following conditions: The system is on a cloud. The cloud-init package is installed. The ssh_genkeytypes configuration is set to ~ in the /etc/cloud/cloud.cfg file, which is the default. This issue prevents the system from connecting by using SSH if the original keys have been removed. For more information on preventing this issue, see the Red Hat Knowledgebase solution Unable to SSH to new Virtual Machine after upgrading the template to RHEL 8.7 or 9 . (BZ# 2210012 ) If too many file systems are mounted, the pre-upgrade process might fail with the following error message: If this issue occurs, complete the following steps: Unmount any file systems that are not related to the system partitions and are not needed during the upgrade process. Comment out the unmounted file systems' entries in the /etc/fstab file to prevent them from being mounted during the upgrade process. Restore the original file system configuration after the upgrade. ( RHEL-3320 ) In-place upgrades using Red Hat Update Infrastructure (RHUI) on Amazon Web Services (AWS) with the ARM architecture are currently experiencing issues. Use the Red Hat Subscription Manager (RHSM) instead. ( RHEL-38909 ) In-place upgrades on Microsoft Azure by using RHUI virtual machines might fail. To prevent this issue, verify that you have installed the leapp-rhui-azure-1.0.0-10.el8.noarch package version before upgrading. By default, the logrotate is not active after the upgrade. The logrotate was previously managed by cron in RHEL 8 and earlier. In RHEL 9, it is managed by systemd . To activate logrotate persistently, run the following command after the upgrade: 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 the subscription-manager command fails. If you use the --proxy option instead of the configuration change, the upgrade process fails because Leapp is unable to detect the proxy. To prevent this problem from occurring, manually edit the rhsm.conf file. 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.conf configuration 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.conf configuration file. For more information, see the Red Hat Knowledgebase solution How does Leapp work with a proxy? The upgrade might fail with a MountError message when all of the following conditions are met: A mount point that is defined in /etc/fstab contains underscore characters. Another mount point defined in /etc/stab has the same name if the underscore character is replaced with a forward slash. For example, having both /var/tmp and /var_tmp mount points defined in /etc/fstab causes the upgrade to fail. To prevent this problem, unmount the mount point that contains underscore characters, and comment that mount point out from the /etc/fstab file before the upgrade. You can restore the configuration after the upgrade. ( RHEL-62737 ) 9.5. Obtaining support To open a support case, select RHEL 8 as the product, and provide a sosreport from your system. To generate a sosreport on your system, run: 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? .

Commands:
Title: None Reason: Confirmation ============================= check_vdo.confirm ============================= Label: Are all VDO devices, if any, successfully converted to LVM management? Description: Enter True if no VDO devices are present on the system or all VDO devices on the system have been successfully converted to LVM management. Entering True will circumvent check of failures and undetermined devices. Recognized VDO devices that have not been converted to LVM management can still block the upgrade despite the answer.All VDO devices must be converted to LVM management before upgrading. Reason: To maximize safety all block devices on a system that meet the criteria as possible VDO devices are checked to verify that, if VDOs, they have been converted to LVM management. If the devices are not converted and the upgrade proceeds the data on unconverted VDO devices will be inaccessible. In order to perform checking the 'vdo' package must be installed. If the 'vdo' package is not installed and there are any doubts the 'vdo' package should be installed and the upgrade process re-run to check for unconverted VDO devices. If the check of any device fails for any reason an upgrade inhibiting report is generated. This may be problematic if devices are dynamically removed from the system subsequent to having been identified during device discovery. If it is certain that all VDO devices have been successfully converted to LVM management this dialog may be answered in the affirmative which will circumvent block device checking. Type: bool Default: None Available choices: True/False Unanswered question. Uncomment the following line with your answer confirm =
[check_vdo] Available choices: True/False Unanswered question. Uncomment the following line with your answer confirm = True
journalctl
ausearch -m AVC,USER_AVC -ts boot journalctl -t setroubleshoot dmesg | grep -i -e selinux -e type=1400
fdisk -l
OperationalError: unable to open database file
mount -o remount --make-shared <mountpoint>
systemctl enable --now logrotate.timer
fdisk -l
OperationalError: unable to open database file
systemctl enable --now logrotate.timer
sosreport