5 Troubleshooting Oracle Linux Upgrades

This chapter provides troubleshooting information and describes known issues that might affect the upgrade process.

Tools for Troubleshooting

Use the following options to generate more output when you are generating the preupgrade report or performing the actual upgrade:

  • --verbose displays warnings, error messages, and other critical information.

  • --debug adds debug information in addition to the same output as the --verbose option.

You can use the following resources and tools for obtaining troubleshooting information:

  • /var/log/leapp/leapp-report.txt
  • /var/log/leapp/leapp-upgrade.log

  • /var/log/leapp/dnf-debugdata/ a directory for debug information. Note that this directory is created only if you use the --debug option when issuing either the preupgrade or the upgrade command.

  • journalctl command

Known Issues

The following are known issues that you might encounter when upgrading an Oracle Linux 9 system to Oracle Linux 10.

Upgrade Issues

  • Leapp might report missing packages that are marked for installation

    The /var/log/leapp/leapp-preupgrade.log or /var/log/leapp/leapp-upgrade.log files might report a warning similar to the following:

    Warning: Packages marked by Leapp for install not found in repositories 
    metadata: rpcgen python3-pyxattr libnsl2-devel rpcsvc-proto-devel

    These packages are in the Oracle Linux10 Codeready Builder repository, which is a developer repository and is disabled by default.

    If the system requires these packages, then during the preupgrade or the upgrade phase, add the --enablerepo ol10_codeready_builder option to the appropriate Leapp command, for example:

    sudo leapp upgrade --oraclelinux --enablerepo ol10_codeready_builder

    Repositories that have been enabled during the Leapp upgrade remain enabled on the Oracle Linux 10 system after the upgrade completes.

    Alternatively, after completing the upgrade, you can manually install the packages required for your installation by using the dnf command.

    Bug ID 32827043

  • Some el9 packages might not be upgraded

    The same rpm -qa command syntax in the previous item that detects MySQL-related *.el9 packages might also list more *el9 packages on the system that weren't upgraded. Packages might not be upgraded if they were installed from repositories that aren't supported by Leapp, such as developer repositories. For such packages, do the following:

    1. Go to https://yum.oracle.com and check the Oracle Linux 10 repositories that would serve the packages you need.

    2. After the upgrade is completed, manually install the packages from those Oracle Linux 10 repositories.

    3. After all the necessary packages have been installed, remove the residual el9 packages from the system.

    Bug ID 32878386

  • (aarch64) Upgrade log might report errors related to the vmd module

    After completing an upgrade on aarch64 systems, the Leapp upgrade log might report the following message:

    dracut-install: Failed to find module 'vmd'

    The VMD module doesn't apply to the Arm architecture and therefore, the error message can be safely ignored.

    Bug ID 34172552

  • The signature is not alive error appears during reboot phase of leapp upgrade

    If the upgrade fails during a reboot phase with errors similar to Signature ... created at ... invalid: signature is not alive, verify that the system time is synchronized or try to upgrade at a later time. The in-place upgrade process might fail if the local time on the system is in the past compared to the build date of the latest release in the public RPM package.

    (Bug 38083008)

File Systems and Storage Issues

  • Systems with Btrfs in a RAID configuration can't be upgraded

    A system that uses the Btrfs file system in a RAID configuration can't be upgraded. In the /var/log/leapp/leapp-report.txt that's generated by the preupgrade command, this configuration is flagged as an inhibitor and no remedy is provided. If you upgrade the system and that configuration is detected, the upgrade process halts.

  • Detected XFS filesystems without bigtime feature.
    The XFS v5 file system format introduced the bigtime feature in Oracle Linux 9, to provides timestamps beyond the year 2038. XFS filesystems that don't have the bigtime feature enabled remain vulnerable to timestamp overflow issues. It is recommended to enable this feature on all XFS filesystems to ensure long-term compatibility and prevent potential failures. Following XFS file systems have not enabled the bigtime feature:
    - /kvm
    - /boot 
    - / 
    To enable the bigtime feature on XFS v5 filesystems, use the following command:
    xfs_admin -O bigtime=1 <filesystem_device>

    For older XFS v5 filesystems this step can only be done offline (for example, without the filesystem mounted).

  • Hosts with network mounted file systems can't be upgraded

    Leapp doesn't support upgrading systems with mounted file systems on network storage, NFS, or iSCSI. As a workaround, unmount the file systems and comment out their entries from /etc/fstab. After the upgrade is completed, you can restore the entries and remount the file systems.

Networking Issues

  • Possible upgrade error if system has several NICs with the same prefix as NIC that's used by kernel

    The in-place upgrade process might cause an error if the system to be upgraded has more than one NIC that shares the same prefix as the NIC that's used by the kernel, for example eth. After the upgrade, the system's network connectivity is lost.

    For more information, see About Network Interface Names in Oracle Linux 10: Setting Up Networking With NetworkManager.

  • NetworkManager might not start after the upgrade completes

    After the upgrade, the system's NetworkManager might not start because of the failure of its name resolution service. The failure can be verified by checking the status of the service.

    systemctl status systemd-resolved.service
    ● systemd-resolved.service - Network Name Resolution 
       Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; 
    disabled; > 
       Active: inactive (dead) 
         Docs: man:systemd-resolved.service(8) 
               https://www.freedesktop.org/wiki/Software/systemd/resolved

    The /var/log/messages file also reports the following error:

    dbus-daemon[742]: [system] Activation via systemd failed for unit 
    'dbus-org.freedesktop.resolve1.service': Unit 
    dbus-org.freedesktop.resolve1.service not found.

    To resolve this issue, choose one of the following workarounds:

    • Configure NetworkManager to not use systemd-resolved.service.

      Add the following entries to the /etc/NetworkManager/conf.d/no-systemd-resolved.conf file:

      [main]
      systemd-resolved=false
    • Enable the systemd-resolved.service as follows:

      systemctl enable systemd-resolved.service
      Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service → 
      /usr/lib/systemd/system/systemd-resolved.service. 
      Created symlink 
      /etc/systemd/system/multi-user.target.wants/systemd-resolved.service → 
      /usr/lib/systemd/system/systemd-resolved.service.
      systemctl start systemd-resolved.service

    You can also adopt other methods that are more consistent with the network name resolution model that you're using for the specific setup. For useful information, see About Network Interface Names in Oracle Linux 10: Setting Up Networking With NetworkManager.

Hardware Related Issues

  • Systems with unrecognized hardware can't be upgraded

    Support for certain hardware, such as the e1000 driver, has been removed from . The upgrade can't proceed on platforms that have such hardware installed. Even though UEK might continue to support the hardware, the upgrade procedure is still inhibited if the hardware is detected on the system.

Leapp Overlay Size Issues

  • Upgrading might require increased overlay size

    Upgrading Oracle Linux 9 systems with a huge number of packages to Oracle Linux 10 might fail because of insufficient space in the Leapp overlay file systems that are used during the upgrade. You might see the following error message:

    Error: Transaction test error: 
      installing package package-name needs 4MB on the / filesystem 

    As a workaround, increase the LEAPP_OVL_SIZE variable. The default size is 4096. The actual size you would need might be larger depending on the specific setup. Use the following command:

    sudo export LEAPP_OVL_SIZE=new-size