4 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:
-
Remove the old network configuration file, for example:
sudo rm /etc/sysconfig/network-scripts/ifcfg-ens300f0
-
Remove any cached data saved by cloud-init:
sudo cloud-init clean
-
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.
-
Edit the
/etc/default/grub
file and append the end of the line in theGRUB_CMDLINE_LINUX=
module as follows:GRUB_CMDLINE_LINUX="console=xxxx mlx5_core.expose_pf_phys_port_name=0"
-
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
-
-
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)
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)