1. Unbreakable Enterprise Kernel Release 7 Update 2 - Release Notes (Version 5.15.0-200)
  2. Known Issues

3 Known Issues

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

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)