3 Known Issues

This chapter describes any known issues for Unbreakable Enterprise Kernel Release 7.

Unusable or Unavailable Features for the Arm Platform

The following are specific features that are known to not work, remain untested, or have issues that render the feature unusable.

  • InfiniBand

    InfiniBand hardware is currently not supported for the Arm architecture when using UEK R7.

  • FibreChannel

    FibreChannel hardware is currently not supported for the Arm architecture when using UEK R7.

  • RDMA

    RDMA is not supported on the Arm platform.

dracut-install: ERROR: installing 'virtio' might be displayed during UEK R7 installation

In UEK R7, virtio isn't built as a module, but is built directly into the kernel. As such, you don't have to specify virtio in the dracut configuration file to add it to initramfs. If you previously had dracut configuration that included this module, attempting to install UEK R7 displays the following dracut error:

dracut-install: ERROR: installing 'virtio'
dracut: FAILED:  /usr/lib/dracut/dracut-install -D
/var/tmp/dracut.FOKWjy/initramfs --kerneldir
/lib/modules/5.15.0-0.21.1.el8uek.x86_64/ -m xen_netfront xen_blkfront
virtio_blk virtio_net virtio virtio_pci virtio_balloon hyperv_keyboard
hv_netvsc hid_hyperv hv_utils hv_storvsc hyperv_fb ahci libahci
dracut-install: ERROR: installing 'virtio'
dracut: FAILED:  /usr/lib/dracut/dracut-install -D
/var/tmp/dracut.G2XSGh/initramfs --kerneldir
/lib/modules/5.15.0-0.21.1.el8uek.x86_64/ -m xen_netfront xen_blkfront
virtio_blk virtio_net virtio virtio_pci virtio_balloon hyperv_keyboard
hv_netvsc hid_hyperv hv_utils hv_storvsc hyperv_fb ahci libahci

This error is displayed, regardless of whether you use the yum or rpm command to install UEK R7.

To work around the issue, before installing UEK R7, remove the "virtio" text from the dracut configuration file. Make sure to remove only the "virtio" text, leaving all other "virtio_*" entries intact, for example:

cat /etc/dracut.conf.d/01-dracut-vm.conf
add_drivers+=" xen_netfront xen_blkfront "
add_drivers+=" virtio_blk virtio_net virtio virtio_pci virtio_balloon "
add_drivers+=" hyperv_keyboard hv_netvsc hid_hyperv hv_utils hv_storvsc
hyperv_fb "
add_drivers+=" ahci libahci "

Use the following command to verify that virtio is built into the kernel:

grep CONFIG_VIRTIO= /boot/config-5.15.0-0.30.4.el8uek.x86_64

If virtio is built into the kernel, the output should be as follows:

CONFIG_VIRTIO=y

(Bug ID 33834972)

Upgrading from UEK R6 to UEK R7 on Arm platform may fail if RAID 5 default page size differs from default stripe size

Starting with UEK R7, the default page size on the Arm platform has changed to 4 KB, from the previous 64 KB default. This change in page size might cause an upgrade from UEK R6 to UEK R7 to fail on systems that are configured for RAID 5 when the default page size differs from the default stripe size.

For this reason, before upgrading from UEK R6 to UEK R7, back up and reformat RAID 5 volumes. In cases where retaining the same RAID 5 configuration is preferred, we recommend that you continue to run UEK R6.

See Default Page Size on Arm Platform Changed to 4 KB for additional information.

(Bug ID 33858264)

Swap partitions created on Arm platform using an earlier UEK release don't work after upgrade to UEK R7

The UEK R7 release includes a significant change for the Arm platform regarding the default page size, which has changed to 4 KB, from the previous 64 KB default. Any swap partitions that were created on the Arm platform using an earlier UEK release, for example, UEK R6, don't work after upgrading to UEK R7.

Note:

This issue applies to the Arm platform, irrespective of file system type.

Upon the first boot into UEK R7 after an upgrade, the following systemd service failure is indicated:

systemctl list-units --failed
UNIT LOAD ACTIVE SUB DESCRIPTION 

dev-mapper-ol_myhost\x2dswap.swap loaded failed failed
/dev/mapper/ol_myhost-swap

To work around this issue, you must reinitialize the swap device with the new page size after upgrading to UEK R7. Use the swapon command as follows and specify the swap location:

sudo swapon --fixpgsz /dev/mapper/ol_myhost-swap
swapon: /dev/mapper/ol_myhost-swap: swap format pagesize does not match.
swapon: /dev/mapper/ol_myhost-swap: reinitializing the swap.
mkswap: /dev/mapper/ol_myhost-swap: warning: wiping old swap signature.
Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=d7ef0a33-403f-447b-863f-d52b7f66c803

In the previous command, /dev/mapper/ol_myhost-swap is an example of a typical swap location that you might specify.

For more information about the important change in default page size for the Arm platform in UEK R7, see Default Page Size on Arm Platform Changed to 4 KB.

(Bug ID 34322552)

Cloud-init and systemd-udevd fail to rename mlx5_core network interfaces during upgrade from UEK R6 to UEK R7

During an upgrade from UEK R6 to UEK R7 on an Oracle Infrastructure instance, cloud-init and systemd-udevd revert to using the older UEK R6 device naming scheme (ifcfg-ens300f0) for the mlx5_core network interface, rather than correctly renaming the device with the new UEK R7 device naming scheme (ens300f0np0).

To ensure that the mlx5_core network interface does not revert to using the former UEK R6 device naming scheme, do the following after the upgrade to UEK R7 has completed, prior to rebooting the system:

  1. Remove the old network configuration file, for example:

    sudo rm /etc/sysconfig/network-scripts/ifcfg-ens300f0
  2. Remove any cached data saved by cloud-init:

    sudo cloud-init clean
  3. Reboot the instance for the changes to take effect.

(Bug ID 34146775)

Mellanox NIC interface name subject to change after upgrading from UEK R6 to UEK R7

During a kernel upgrade from UEK R6 to UEK R7, the mlx5_core device name is subject to change, from ens2f0 (UEK R6) to ens2f0np0 (UEK R7).

You might encounter this issue under the following circumstances:

  • When upgrading an Oracle Linux 8 system that is running UEK R6 to UEK R7.

  • When upgrading an Oracle Linux 8 system that is running UEK R6 to Oracle Linux 9 (which ships with UEK R7 by default).

  • When upgrading an Oracle Linux 8 system that is already running UEK R7 to Oracle Linux 9.

    Note:

    In the case where an Oracle Linux 8 system is already running UEK R7, if you previously configured the system to use backwards-compatible device names (ens2f0), you might need to apply the workaround that follows to your GRUB configuration after the upgrade to Oracle Linux 9 has completed.

Note that fresh installations of UEK R7 on Oracle Linux 8 and Oracle Linux 9 use the default naming convention for UEK R7 (enp2s0f0np0) by default.

To retain backwards-compatible (UEK R6) device names for the mlx5_core driver-based network interface card (NIC), perform the following workaround after upgrading to UEK R7, prior to rebooting your system. It is recommended that you back up your existing grub.cfg file before making this change.

  1. Edit the /etc/default/grub file and append the end of the line in the GRUB_CMDLINE_LINUX= module as follows:

    GRUB_CMDLINE_LINUX="console=xxxx mlx5_core.expose_pf_phys_port_name=0"
  2. After editing the file, locate the grub.cfg file on your system, then run the command to update GRUB configuration, as appropriate:

    • On BIOS-based systems, the grub.cfg output/target file is usually located at /boot/grub2/grub.cfg and you would run the following command:

      sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    • On UEFI-based systems, the grub.cfg output/target file could be located at /etc/grub2-efi.cfg or /boot/efi/EFI/redhat/grub.cfg. Depending on the location of the file, you would run one of the following commands:

      sudo grub2-mkconfig -o /etc/grub2-efi.cfg
      sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  3. Reboot the system for the changes to take effect.

(Bug IDs 34103369, 34145887)

Random high CPU utilization issue encountered with database benchmark program

A random high CPU utilization issue has been encountered with the database benchmark program running on a 192-CPU virtual machine in Azure. This issue was initially discovered in Oracle Linux 8.4 and Ubuntu 20.04 (5.11.0-1022-azure); however, a complete fix for the issue isn't yet available in the upstream kernels.

This issue typically manifests itself with a >90% CPU utilization spike occurring every 1 to 2 minutes and lasting approximately 5 to 20 seconds, which degrades the system's performance significantly. When the CPU utilization spike is occurring, each of the 192 CPUs' %sys increases up to 60+%, and the %si increases up to 30%. In certain cases, the >90% CPU utilization spike has been observed 100% of the time.

To avoid encountering this issue, set the dm_mod.dm_mq_queue_depth=256 kernel parameter.

(Bug ID 33665982)

(aarch64) Disk Encryption Password Prompt Not Being Displayed at System Boot

If you install Oracle Linux with GUI on an encrypted disk, for example, by choosing Server with GUI during the installation stage, and VGA is enabled, the password prompt doesn't appear on the VGA output at system boot. Consequently, the boot process can not be completed. The prompt appears only on a serial console, and therefore, you would need to switch to a serial console to provide the password there.

This issue is specific to systems on the Arm platform only and occurs regardless of whether you're using secure boot or not. Further, the issue applies to Oracle Linux 8 or Oracle Linux 9 systems that use UEKR6 or UEKR7.

To make the GUI password prompt for disk encryption appear at boot time on VGA output without using a serial console, add plymouth.ignore-serial-consoles to the kernel command line in the GRUB configuration. For instructions, see the Managing Kernels and System Boot chapter in Oracle Linux 9: Managing Core System Configuration.

(Bug ID 35034465)

(aarch64) Permission error message is displayed during firmware upgrade

When firmware is being updated on a system that's running UEKR7 with a version earlier than 5.15.0-104.119.4.2, an error similar to the following might be displayed. The error occurs typically on systems on the AMD platform.

/var/tmp/rpm-tmp.x8KEGx: line 9: /sys/devices/system/cpu/microcode/reload: Permission denied

Code in the firmware package that triggers a reload is ignored because the kernel doesn't provide this facility. The message is harmless and can be ignored.

The reload facility is available in UEKR7 version 5.15.0-104.119.4.2 and later.

(Bug ID 35677123)

XFS DAX Mount Option Is Incompatible With Oracle Linux 9 With Reflink Enabled

On Oracle Linux 9 with UEK R7, the file system DAX mount option dax=always is incompatible with reflink-enabled XFS file systems. For example, running the command sudo mount -o dax=always /dev/pmem1 /mnt displays the following error:

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/pmem1, missing codepage 
    or helper program, or other error.
mount: (hint) your fstab has been modified, but systemd still uses the old version; 
    use 'systemctl daemon-reload' to reload.

(Bug ID 35991195)

xdp-tools on Oracle Linux 9 Is Incompatible With UEK R7

The Oracle Linux 9 xdp-tools package that contains the xdp-monitor and xdp-bench commands is incompatible with UEK R7. The following errors are displayed when these commands are run on an Oracle Linux 9 system that's running UEK R7:

– END PROG LOAD LOG –
libbpf: prog 'tp_xdp_cpumap_kthread': failed to load: -22
libbpf: failed to load object 'xdp_sample'
libbpf: failed to load BPF skeleton 'xdp_sample': -22

If you need this package, use Oracle Linux 8 with xdp-tools v1.2.10-1.el8 or earlier.

(Bug ID 36014171)