Chapter 4 Known Issues

This chapter describes known issues that you may encounter when installing and using the Oracle Linux 9 software. Information that pertains to a specific platform is noted accordingly.

4.1 Installation Issues

The following are known installation issues for Oracle Linux 9.

4.1.1 iscsi-init service falls into a failed state by default

At the initial boot after installation, the iscsi-init.service service enters a failed state on a system where the operating system is installed to local disk. The failure is caused by the service attempting to write to a configuration file early in the boot process before the root file system becomes writable. Running the systemctl is-system-running command generates a report that indicates that the system is degraded. However, if a system is configured with a valid InitiatorName value in the /etc/iscsi/initiatorname.iscsi file, this issue is not encountered. In this case, the service runs normally.

To workaround this issue, wait until the system is fully booted. Then, run the following command:

sudo systemctl restart iscsi-init

The iscsi-init.service is a one-time service in the installation process and therefore, the issue is no longer encountered in subsequent reboots.

(Bug ID 33930979)

4.1.2 Network installation with PXE boot server fails

While using a PXE boot server to perform a network installation on a UEFI client where Secure Boot is enabled, the installation might fail because the grubx64.efi file cannot load the grub configuration file. The grub bootloader switches to the command line mode and the installation process stops at the grub prompt.

To work around this issue, configure the tftpd service to run with the -r blksize option enabled.

If you are using dnsmasq for TFTP services, uncomment the tftp-no-blocksize line in the /etc/dnsmasq.conf file. Then restart the dnsmasq service.

(Bug ID 32433445)

4.2 Virtualization Issues

The following are known virtualization issues for Oracle Linux 9

4.2.1 KVM virtual machines panic when started on Oracle Linux 9 hosts

The glibc version that is included with Oracle Linux 9 checks for compatibility between a system's CPU and new architectures that are supported. A system might pass the compatibility check. However, the CPU flags that are set on the system after passing the check might be unknown to the KVM virtual machines that are hosted on that system. Consequently, the VMs panic when they are booted.

To work around this issue, run the following command:

virsh edit vm-name

Then, add the following declaration in the virtual machine's XML file:

<cpu mode='host-model' check='partial'/>

The check parameter's partial setting sets libvirt to check the VM's CPU specification before starting a domain. However, the rest of the checking is left on the hypervisor, which can still provide a different virtual CPU.

(Bug ID 34224821)

4.2.2 Virtual machines fail to start at boot because the virbr0 interface is not available

After reboot, the virbr0 network interface may be missing and this can prevent virtual machines from automatically starting up after boot.

The libvirt daemons on Oracle Linux 9 are modular to handle atomic features within the virtualization environment and are started and run as required, and stopped after two minutes of inactivity. The daemon responsible for setting up the networking interfaces for libvirt is virtnetworkd. This service is currently not automatically started when a virtual machine is started.

To work around this issue, enable the virtnetworkd service so that it starts at boot:

sudo systemctl enable --now virtnetworkd

(Bug ID 34237540)

4.3 Kernel Issues

The following are known kernel issues in Oracle Linux 9.

4.3.1 Kdump might fail on some AMD hardware with RHCK and UEK R7

Kdump might fail on some AMD hardware that is running Oracle Linux 9 with either RHCK or UEK R7. Impacted hardware includes the AMD EPYC CPU (codename Naples, Rome and Milan) servers.

To work around this issue, modify the /etc/sysconfig/kdump configuration file and remove the iommu=off command-line option from the KDUMP_COMMANDLINE_APPEND variable. Then, restart the kdump service for the changes to take effect.

(Bug ID 34312626)

4.3.2 Sub-optimal Kdump settings on some platforms

The crashkernel memory reservations for certain platforms might not be optimal in all circumstances.

To check if Kdump settings are optimal, ensure the Kdump kernel is loaded:

sudo kdumpctl status
kdump: Kdump is operational

If kdumpctl reports otherwise, change the crashkernel settings to a higher value for your memory requirements:

  1. Run cat /proc/cmdline to see the current kernel command line options.

  2. Use the grubby command to remove the current crashkernel settings for all kernels, for example:

    sudo grubby --update-kernel=ALL --remove-args="crashkernel=2G-8G:256M,8G-:896M
  3. Use the grubby command to add a new crashkernel setting for all kernels, for example:

    sudo grubby --update-kernel=ALL --args="crashkernel=2G-:448M"
  4. Reboot the system for the changes to take effect. Confirm that the new changes have enabled the Kdump kernel to load correctly.

The crashkernel=auto option is no longer supported on Oracle Linux 9. Some platforms, such as the Raspberry Pi have maximum limits for crashkernel memory reservation.

(Bug ID 34240246)

4.4 Flatpak-system-helper file access triggers SELinux policy violations

Booting Oracle Linux 9 with a GUI desktop environment that has SELinux enabled can produce SELinux security messages similar to the following:

SELinux is preventing /usr/libexec/flatpak-system-helper from read access on the file passwd.
SELinux is preventing /usr/libexec/flatpak-system-helper from write access on the directory flatpak.
SELinux is preventing /usr/libexec/flatpak-system-helper from watch access on the directory /usr/libexec.

A popup message notifying you of a violation might appear immediately after the installation if the Server with GUI or Workstation with GUI installation profiles are selected and SELinux is enabled and Flatpak installed.

You can continue to use Flatpak with SELinux; however, continued use can result in large numbers of messages to the logs.

To work around this issue, create an SELinux policy module for the flatpak-system-helper service:

ausearch -c 'flatpak-system-' --raw |audit2allow -M my-flatpaksystem
semodule -i my-flatpaksystem.pp

(Bug ID 34321783)