Chapter 5 Known Issues

Table of Contents

This chapter describes known issues in Oracle Linux 7.9. Note that some issues may apply to both the x86_64 and Arm (aarch64) platforms. For known issues that impact the Arm (aarch64) platform only, see Section 7.4, “Known Issues (aarch64)”.

For any additional issues that are specific to the UEK R6, refer to Unbreakable Enterprise Kernel: Release Notes for Unbreakable Enterprise Kernel Release 6.

5.1 Installation and Upgrade Issues

You might encounter one or more of the following issues during an Oracle Linux 7.9 installation or upgrade.

5.1.1 Installer kernel fails to boot on systems with a multipath-enabled NVMe controller

The Oracle Linux 7.9 installer may fail to boot on systems with a multipath-enabled Non-Volatile Memory Express (NVMe) controller.

To work around the issue, disable native multipath support at boot for the installation by setting the nvme_core.multipath=N kernel argument on the target system.

(Bug ID 31758304)

5.1.2 Upgrade from ULN fails if the openscap-containers package is installed

Upgrading from Oracle Linux 7.8 to Oracle Linux 7.9 by installing packages from ULN fails if the openscap-containers package is already installed on the system that you are upgrading.

To avoid encountering this issue, remove the openscap-containers package prior to upgrading to Oracle Linux 7.9: 

# yum -y remove openscap-containers

(Bug ID 30686371)

5.1.3 Graphical installer allows users to edit kickstart settings

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

When performing a graphical installation, where some installation options are already set by using a kickstart configuration file, you can still modify these settings by clicking the various fields during the installation and then editing the predefined content. These types of edits during the installation process require that you intentionally attempt to modify the setting, effectively enabling an interactive installation, where the options that are set in the kickstart configuration are not secured by any policy.

Note that these types of edits are not possible when performing a text installation. During a text installation, you can only modify those fields that have not already been defined in the kickstart configuration file.

(Bug ID 28642357)

5.1.4 Graphical installer fails to produce error when unacceptable Kdump value is entered

There is a minor upstream usability error that applies to the graphical installer when configuring Kdump settings. In the situation where you attempt to configure a manual kdump memory reservation, and you then set the memory reservation value to an unacceptable value, the installer allows you to click Done and return to the Installation Summary screen without producing a warning or error message.

When you select an unacceptable value, the installer resets the value to the last-known acceptable value that was entered; or, the installer sets the default minimum value of 512 MB. Note that this information is not displayed in the Installation Summary screen. Because an incorrect value cannot be stored for this parameter, the installation succeeds even when incorrect information is entered.

This issue does not occur with the text-based installer, which correctly returns an error if you enter an unacceptable value, preventing you from continuing until you enter an acceptable value.

(Bug IDs 31133351, 31182708)

5.1.5 Graphical installer does not display the reserved memory that is manually set for Kdump

A minor usability error applies to the graphical installer when configuring Kdump settings. If you manually change the default memory size that is reserved for Kdump, the new setting is not displayed when the screen is refreshed. Instead, only the values for the total system memory and usable system memory are displayed. Consequently, the limits for the parameter "Memory to be reserved (Mb)" become unknown for future Kdump configuration.

Note

The default settings for Kdump memory reservation of auto is adequate as the kernel will determine what size to use when it boots

Note

The default settings for Kdump memory reservation of auto is adequate as the kernel will determine what size to use when it boots

(Bug IDs 31133287 and 31182699)

5.1.6 FCoE boot fails on HPE servers with HPE FlexFabric adapters

This issue is caused by a known limitation with the bnx2x and bnx2fc drivers and the Option Card Black Box - Active Health (OCBB) feature when the input–output memory management unit (IOMMU) is enabled. The issue occurs because the network adapter firmware attempts to access a memory area that is not assigned network devices when bringing the interface up or down, or when loading or unloading the driver. When this issue occurs, you must reboot the system.

As a workaround, you must specify intel_iommu=off in the kernel boot parameters.

(Bug ID 30102871)

5.1.7 Information about installing on an iSCSI disk

When installing on an iSCSI disk, you must add the rd.iscsi.ibft=1 parameter to the boot command line and then specify at least one MBR or GPT-formatted disk as an installation target. Otherwise, the installation fails with the following error message: 

No valid boot loader target device found.
Important

Any prior instruction advising you to use the ip=ibft is no longer valid, as this option is now fully deprecated.

(Bug IDs 22076589, 30155659)

5.1.8 Information about installing on an HPE 3PAR TPVV

If you have not applied a Thin Persistence license to an HPE 3PAR storage array, the installation fails to create a file system on a thin provisioned virtual volume (TPVV). This license is required to support the low-level SCSI UNMAP command for storage reclamation. If you do not have a suitable license, the workaround is to use a fully provisioned virtual volume (FPVV) instead of a TPVV.

(Bug ID 22140852)

5.1.9 Installation fails on Oracle Flash Accelerator F640 NVMe device

An installation fails if the target device is an Oracle Flash Accelerator F640 NVMe add-in card with two block devices. Although the card has two independent NVMe controllers and devices, they are assigned identical WWIDs. The multipath device mapper maps the two block devices to the same WWID, resulting in a bogus multipath configuration, which prevents the installation.

To work around this issue, disable multipath for the installation at boot time by using the installer boot argument nompath. After the installation completes, block list the NVMe block devices for the multipath configuration on the system by editing the /etc/multipath.conf file. Or, you can disable device mapper multipath altogether. See Oracle® Linux 7: Administrator's Guide for more information about configuring multipath.

(Bug ID 27638939)

5.1.10 Upgrade fails if open files limit is too low and rpm-plugin-systemd-inhibit is installed

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

An upgrade from Oracle Linux 7.6 can fail if the log-in session open files limit is set too low and the system that is being upgraded includes multiple packages from many channels or repositories. This issue can be triggered if the rpm-plugin-systemd-inhibit package is installed and the session is configured for a maximum open file limit that is lower than 4096. The issue typically results in the yum command failing to update and produces error messages similar to the following: 

Verifying  : glib2-static-2.56.1-1.el7.i686
glib2-static-2.56.1-1.el7.i686 was supposed to be installed but is not!

To resolve this issue, set the open file limit to 4096 before running the yum update command, for example: 

# ulimit -n 4096
# yum update -y

(Bug ID 28720235)

5.1.11 32-bit RDMA packages are installed when upgrading a system that has rdma-core installed

For upgrades prior to Oracle Linux 7.4, where the rdma-core.noarch package is installed, 32-bit versions of the packages, as well as many dependencies are also installed unnecessarily. This problem occurs because the original version of the package is obsoleted. Thus, during upgrade, the package is replaced with both the rdma-core.i686 and rdma-core.x86_64 versions of the package, along with any dependencies for those packages.

To work around the issue, run the yum update command with the --exclude=\*.i686 option, for example: 

# yum update --exclude=\*.i686

(Bug ID 28217831)

5.2 Package Conflict: PackageKit.i686 and PackageKit.x86_64

The PackageKit.i686 package in the ol7_x86_64_optional_latest ULN channel conflicts with the PackageKit.x86_64 package in the ol7_x86_64_u6_base channel. Attempting to install both packages results in a transaction check error similar to the following: 

Transaction check error:
  file /usr/lib/python2.7/site-packages/packagekit/__init__.pyc from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/__init__.pyo from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/backend.pyc from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/backend.pyo from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/enums.pyc from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/enums.pyo from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/filter.pyc from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/filter.pyo from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/misc.pyc from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/misc.pyo from install of
PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/package.pyc from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/package.pyo from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/progress.pyc from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64
  file /usr/lib/python2.7/site-packages/packagekit/progress.pyo from install
of PackageKit-version.el7.i686 conflicts with file from package
PackageKit-version.el7.x86_64

You may only install one of these packages on the same system at the same time. To avoid this conflict, exclude the PackageKit.i686 package in your yum configuration. For more information about how to exclude packages during an installation, see Oracle® Linux: Unbreakable Linux Network User's Guide for Oracle Linux 6 and Oracle Linux 7.

(Bug ID 24963661)

5.3 Uninstalling libpcap can result in the removal of a large number of libvirt packages

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

The libpcap package is updated to enable functionality for future technologies. If you install this package and then attempt to uninstall it, a large number of libvirt packages might also be uninstalled caused by dependency relationships. The libvirt package has a dependency on the libvirt-daemon-driver-nwfiler package and this package has a dependency on libpcap. Removing the libpcap package removes the entire libvirt family of packages.

(Bug ID 28582266)

5.4 Database installation and operation fails if RemoveIPC=yes is configured for systemd

If the RemoveIPC=yes setting is configured for systemd, interprocess communication (IPC) is terminated for a non-system user's processes when that user logs out. This setting, which is intended for use on laptop systems, can cause software problems on servers. For example, if the user is a database software owner such as oracle for Oracle Database, this configuration can cause a database installation to fail or database services to crash.

By default, Oracle Linux 7.9 configures RemoveIPC=no in the /etc/systemd/logind.conf file to prevent systemd from terminating IPC. However, if you have touched this file before updating your system to Oracle Linux 7.9, the update installs the new version of the file as /etc/systemd/logind.conf.rpmnew and does not set RemoveIPC=no in the /etc/systemd/logind.conf file. To avoid database crashes, set RemoveIPC=no in the /etc/systemd/logind.conf file and then run the systemctl reboot command to reboot the system.

(Bug ID 22224874)

5.5 Automatic Bug Reporting Tool

Note

The following information pertains to both x86_64 and 64-bit Arm platforms.

The automated reporting daemons and features provided by the Red Hat Automatic Bug Reporting Tool (ABRT) are not supported with Oracle Linux

ABRT packages and associated files, such as libreport, are included in the distribution to satisfy package dependencies and can be used to generate local bug reports but the features to automatically upload these reports are not supported. For technical assistance, contact Oracle Support by using the My Oracle Support portal or by telephone.

5.6 File Systems Issues

The following file systems issues are encountered when running Oracle Linux 7.9.

5.6.1 XFS: No support for reflink feature in RHCK

If an XFS file system is created with support for the reflink feature with the UEK R5 kernel, you cannot mount the XFS file system with the RHCK kernel. The file system can only be mounted as read-only.

(Bug ID 30119906)

5.6.2 XFS: No support for real-time devices in RHCK

If an XFS file system is created with support for real-time devices with the UEK R5 kernel, you cannot mount the XFS file system with the RHCK kernel.

(Bug ID 30115269)

5.7 ACPI error messages displayed on Dell EMC PowerEdge Server during boot

When booting an Intel-based Dell EMC PowerEdge Server, error messages similar to the following might be displayed if the Dell Active Power Controller (DAPC) setting is enabled in the BIOS: 

kernel: ACPI Error: No handler for Region [SYSI] (0000000061df8ef3) [IPMI] (20190816/evregion-132)
kernel: ACPI Error: Region IPMI (ID=7) has no handler (20190816/exfldio-265)
kernel: ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20190816/psparse-531)
kernel: ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20190816/psparse-531)
kernel: ACPI Error: AE_NOT_EXIST, Evaluating _PMC (20190816/power_meter-743)

Note that this issue is encountered on both RHCK and UEK kernels.

The workaround for this issue is to disable the apci_power_meter kernel module as follows: 

# echo "blacklist acpi_power_meter" >> /etc/modprobe.d/hwmon.conf

After disabling the apci_power_meter kernel module, reboot the system for the change to take effect.

For environments that do not require the DAPC feature, as an alternative workaround, you can disable the DAPC BIOS setting.

(Bug ID 32105233)

5.8 grubby fatal error during kernel upgrade when /boot is on a BTRFS subvolume

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

If /boot is hosted on a Btrfs subvolume, GRUB 2 is unable to correctly process the initramfs and vmlinuz path names. This problem occurs when you update or install a new kernel and then the grubby command attempts to update the GRUB 2 configuration. In the case where you have a fresh installation of Oracle Linux 7.9 and you upgrade the RHCK or UEK kernel, the following error is displayed: 

grubby fatal error: unable to find a suitable template

After the kernel update, when the system is rebooted, it boots the old kernel.

The workaround for this problem is to use grub2-mkconfig to regenerate the /etc/grub2/grub.cfg file, or /etc/grub2-efi.cfg file on a UEFI booted system, immediately after the kernel has been installed or upgraded, for example: 

# grub2-mkconfig -o /boot/grub2/grub.cfg

Obtain a listing of the kernel menu entries in the generated configuration as follows: 

# grep -P "submenu|^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2

From the listing, select the kernel entry that you want to run as the default kernel and set this entry as the default by using the following command: 

# grub2-set-default "menu entry title"

In the previous command, menu entry title is the title of the kernel entry that you identified in the listing.

You can use the grub2-editenv list command to check that the saved_entry has been updated with the selected kernel menu title.

Reboot the system and use uname -a to check that the correct kernel is now running.

(Bug ID 22750169)

5.9 Hebrew LaTeX fonts

Note

The following information applies to both x86_64 and 64-bit Arm (aarch64) platforms.

Installing the tex-fonts-hebrew package fails unless you first install all of the texlive* packages.

(Bug ID 19059949)

5.10 InfiniBand CA port generates warnings if disabled

You might see the following warning messages if you use the ibportstate disable command to disable an InfiniBand CA or router port: 

ibwarn: [2696] _do_madrpc: recv failed: Connection timed out
ibwarn: [2696] mad_rpc: _do_madrpc failed; dport (Lid 38)
ibportstate: iberror: failed: smp set portinfo failed

You can safely ignore these warnings.

(Bug ID 16248314)

5.11 Kdump fails to start when lockdown is enabled

The kdump service fails to start if the kernel lockdown feature is enabled and either the integrity or confidentiality parameters have been set.

To work around this issue, append the -s option in Kdump /usr/bin/kdumpctl configuration file to include the standard_kexec_args="-p" argument. You must restart the kdump service for the changes to take effect.

(Bug ID 31724653)

5.12 KVM Issues

The following KVM issues may be encountered.

5.12.1 Snapshots of KVM guests that use UEFI fail and are unsupported

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

You cannot create snapshots of KVM guests if they use UEFI. In older versions of QEMU and libvirt, the tools might allow you to create the snapshot without an error or warning, but the snapshot could be corrupted. More recent versions of these tools prevent snapshot creation by producing an error similar to the following: 

virsh # snapshot-create-as OL7-seboot
error: Operation not supported: internal snapshots of a VM with pflash based
firmware are not supported

(Bug ID 26826800)

5.12.2 KVM guests with LSI MegaRAID SAS ISCSI controller limited to 7 virtual disks

An Oracle Linux 7.9 KVM guest that is using the LSI MegaRAID SAS ISCSI controller is limited to 7 virtual disks. Although KVM guests can have up to 8 ISCSI virtual disks, the LSI MegaRAID SAS controller uses the first slot for the ISCSI Initiator, leaving just the 7 slots remaining for virtual disks.

The workaround for this issue is to use the megasas controller instead of the lsi controller when creating ISCSI virtual disks. For example, change -device lsi to -device megasas, as shown in following examples: 

# /usr/bin/qemu-system-x86_64 -machine accel=kvm -m 8192 -smp 8 \
-drive file=/path/OracleLinux-7.6-x86_64.qcow2,format=qcow2,if=none,id=disk \  
-device ide-hd,bus=ide.0,unit=0,drive=disk,bootindex=0 -device lsi,id=lsi0 \ 
-drive  file=/path/disk1.img,format=raw,if=none,id=drive_image1 \
-device scsi-hd,id=image1,drive=drive_image1,bus=lsi0.0 \
...
# /usr/bin/qemu-system-x86_64 -machine accel=kvm -m 8192 -smp 8 \
-drive file=/path/OracleLinux-7.6-x86_64.qcow2,format=qcow2,if=none,id=disk \  
-device ide-hd,bus=ide.0,unit=0,drive=disk,bootindex=0 -device megasas,id=lsi0 \ 
-drive  file=/path/disk1.img,format=raw,if=none,id=drive_image1 \
-device scsi-hd,id=image1,drive=drive_image1,bus=lsi0.0 \
...

(Bug 27681238)

5.13 Unable to create Oracle Linux 7 LXC containers on NFS

Note

The following issue applies to both x86_64 and 64-bit Arm (aarch64) platforms.

Creating Oracle Linux 7 containers fails when the root file system (/container) is hosted on an NFS share. This problem occurs because the iputils package in Oracle Linux 7 is built to use the Linux file-extended attributes, [xattr(7)] security capabilities(7). Because NFS does not support these file capabilities, the iputils package might not be installed into an NFS files system. For example, when attempting to create an Oracle Linux 7 container, the installation fails while installing the iputils package, producing the following error: 

Error unpacking rpm package iputils-20121221-7.el7.x86_64
error: unpacking of archive failed on file /usr/bin/ping: cpio: cap_set_file
error: iputils-20121221-7.el7.x86_64: install failed

Similar issues are seen when attempting to install the initscripts and systemd packages while creating an Oracle Linux 7 container.

This issue occurs on both NFSv3 and NFSv4. Note that Oracle Linux 6 containers are not affected.

(Bug ID 25024258)

5.14 Support for Oracle Linux 7 guests on Oracle VM and Xen

Oracle Linux 7 guests are supported for both hardware virtualization (HVM) and hardware virtualization, with paravirtual drivers (PVHVM) on Oracle VM Release 3. Oracle Linux 7 guests in a paravirtualized domain (PVM) on Oracle VM or other Xen-based hypervisors are not supported.

Oracle Linux 7 guests of any type are not supported on Oracle VM Release 2.

(Bug IDs 18712168, 18667813, 18266964)

5.15 Network Issues

The following issues are related to network features and configuration.

5.15.1 Device name change for Broadcom BCM573xx network driver (bnxt_en) may result in network configuration issues

An upstream change to the Broadcom BCM573xx network driver (bnxt_en) that was incorporated into UEK R6 results in a device name change for the second port on Broadcom network interfaces that use this driver. For example, a device that was previously identified as eno3d1 is now identified as eno3. This fix was applied to improve device naming and also to address assumptions about port functionality on a device, such as in situations where the network device may belong to different functions. Consequently, this change can result in issues with network scripts when upgrading from a system that uses RHCK or UEK R5, or an earlier UEK release, to UEK R6.

If you configured a second port on the affected card during the installation, upon first boot or any subsequent boot after the installation with UEK R6, the system fails to initialize the second port, as a result of an incorrect configuration entry due to this name change. Note that the system is unaffected if you boot into RHCK.

Also, if you are upgrading from an earlier Oracle Linux release to Oracle Linux 7.9, and a second port on the affected card was previously configured, the system fails to initialize the second port, as earlier UEK and RHCK releases also use a different naming scheme.

To work around this issue, if you are performing a new installation and intend to use UEK R6 as your default kernel, use the Oracle Linux 7.9 UEK boot ISO to perform the installation. Alternatively, you can either boot into RHCK; or, you can update the network interface configuration file name and the interface name to ensure that it corresponds to the naming convention that is used by the driver in UEK R6.

(Bug IDs 31972637) .

5.15.2 Geneve network driver support not available in UEK releases earlier than UEK R5

The ip and iproute commands that are included in Oracle Linux 7.9 provide support for Geneve-capable devices. The module for this driver is included with RHCK, but it is not included in releases earlier than UEK R5.

As such, the commands that you use to set, add, or view Geneve devices are only functional when used with RHCK; or, if you are running UEK R5 or UEK R6, which is the default UEK release that is shipped with Oracle Linux 7.9.

(Bug ID 24652835) .

5.15.3 Network connection icon reports incorrect state for interfaces

The network connection icon might report that an active network interface is disconnected. This behavior is seen for the root user but not for other users. Command-line utilities such as ip link and ifconfig report the correct state.

(Bug ID 19060089)

5.16 Power button defaults to ACPI Suspend mode

By default, the Oracle Linux 7 graphical user interface (GUI) console mode treats the hardware power button as the equivalent of the ACPI "Sleep" button, which puts the system into low-power sleep mode. This behavior is specific to the GNOME desktop environment.

In previous Oracle Linux releases, the hardware power button initiated a system shutdown. To ensure that Oracle Linux 7 behaves the same way, do the following:

  1. Create a file named /etc/dconf/db/local.d/01-shutdown-button-action with following content: 

    # cat /etc/dconf/db/local.d/01-power
[org/gnome/settings-daemon/plugins/power]
power-button-action='interactive'
#

  2. Create a file named /etc/dconf/db/local.d/locks/01-power with the following content: 

    # cat /etc/dconf/db/local.d/locks/01-power
/org/gnome/settings-daemon/plugins/power/power-button-action
#

  3. Run the following command: 

    # dconf update

  4. Log out of the desktop environment and then log back in for the new settings to take effect.

(Bug ID 25597898)

5.17 sosreport command issues warnings

Running the sosreport command in this release issues warnings similar to the following: 

[plugin:networking] skipped command 'ip -s macsec show': required kernel
modules or services not present (kmods=[macsec] services=[]). Use
'--allow-system-changes' to enable collection.
[plugin:networking] skipped command 'ss -peaonmi': required kernel modules or
services not present
(kmods=[tcp_diag,udp_diag,inet_diag,unix_diag,netlink_diag,af_packet_diag]
services=[]). Use '--allow-system-changes' to enable collection.

These warnings are caused by a change in the sos package version, which now includes the --allow-system-changes option. The warning is advising you to specify this option whenever you run the sosreport command to ensure that all of the data is collected correctly and that no system information is omitted from the resulting sosreport.

Note

When the --allow-system-changes option is specified, the command runs all of the subcommands, even those that are capable of changing the system, such as load kernel modules, and so on.

(Bug ID 30650012)

Copyright © 2021,2022, Oracle and/or its affiliates.