Known Issues

Installation and Upgrade Issues

The following issues might be encountered during an installation.

Graphical installer allows users to edit kickstart settings

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

Note that this type of change is not possible when performing a text installation. During a text installation, the user can only modify fields that have not already been defined in the kickstart configuration file. (Bug ID 28642357)

Installation on an iSCSI disk

When installing on an iSCSI disk, you must add either ip=ibft or rd.iscsi.ibft=1 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 error message No valid boot loader target device found. (Bug ID 22076589)

Installation on an HPE 3PAR TPVV

If you have not applied a Thin Persistence license to an HPE 3PAR storage array, 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)

Installation fails on Aura7 NVMe device

Installation fails if the target device is an Aura7 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 that prevents installation.

To work around the issue, disable multipath at boot for the installation by using the installer boot argument nompath. After the installation, blocklist the NVMe block devices for multipath configuration on the system by editing /etc/multipath.conf, or you can disable device mapper multipath altogether. See Oracle Linux 7: Administrator's Guide for more information about configuring multipath. (Bug ID 27638939)

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

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

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 yum update:

sudo ulimit -n 4096
sudo yum update -y

(Bug ID 28720235)

Package Conflicts

The following are known package conflicts for packages that are distributed by Oracle for Oracle Linux 7 through ULN or the Oracle Linux yum server.

dovecot-devel.i686 and dovecot-devel.x86_64

The dovecot-devel.i686 and dovecot-devel.x86_64 packages in the ol7_x86_64_optional_latest ULN channel conflict. Attempting to install both packages results in a transaction check error:

Transaction check error:
  file /usr/include/dovecot/config.h conflicts between attempted installs of
dovecot-devel-1:2.2.10-7.el7.i686 and dovecot-devel-1:2.2.10-7.el7.x86_64

There are bitsize differences between the identified file. You may only install one of these packages on the same system at once. (Bug ID 25057633)

PackageKit.i686 and PackageKit.x86_64

The PackageKit.i686 package from 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:

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 once. To avoid the conflict, exclude the PackageKit.i686 package in your yum configuration. For more information about how to exclude packages, see Oracle Linux: Unbreakable Linux Network User's Guide for Oracle Linux 6 and Oracle Linux 7.

(Bug ID 24963661)

Upgrading kmod-oracleasm produces depmod errors indicating missing file or directory

The installation or upgrade of the kmod-oracleasm package may result in an error similar to:

depmod: ERROR: fstatat(6, kvdo.ko): No such file or directory
depmod: ERROR: fstatat(6, uds.ko): No such file or directory

This error appears on systems that are running a previous version of the kmod-oracleasm package due to a downgrade. When upgrading or reinstalling, the kmod-kvdo package installs the module into the weak-updates directory. This practice differs from the previous installation approach expected by kmod-oracleasm, which can result in a NULL symbolic link that is declared as a missing file. A standard installation or upgrade is unaffected by this issue. The issue only appears if the packages are downgraded and then upgraded again. (Bug ID 28864195).

Automatic Bug Reporting Tool

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.

libvirtd process displays a warning on start-up after an upgrade

After upgrading from Oracle Linux 7.4, the libvirtd process displays a warning message similar to following during start-up:

libvirtd ... warning : virQEMUCapsInit:1211 : Failed to get host CPU cache info 
libvirtd ... warning : virLXCDriverCapsInit:85 : Failed to get host CPU cache info

You can safely ignore this warning. Note that this warning does not occur with a fresh installation. (Bug ID 27700583)

Snapshots of KVM guests using UEFI fail and are unsupported

You cannot do 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 with 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)

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

An Oracle Linux 7 KVM guest 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 remaining slots 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 highlighted text in the following example:

sudo /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 \
...

sudo /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)

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

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

grubby fatal error: unable to find a suitable template

When the system is rebooted after the kernel update, the system boots to the old kernel.

Similarly, when upgrading from Oracle Linux 7.4 to Oracle Linux 7.6, if /boot is hosted on a btrfs subvolume, the system boots to the old Oracle Linux 7.4 kernel after the upgrade is complete.

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:

sudo 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 using the following command, substituting menu entry title with the title of the kernel entry that you identified in the listing:

sudo grub2-set-default "menu entry title"

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

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

(Bug ID 22750169)

Hebrew LaTeX fonts

Installing the tex-fonts-hebrew package fails unless you first install all of the texlive* packages. (Bug ID 19059949)

InfiniBand Issues

The following are issues that you might encounter when using InfiniBand devices.

Kdump might fail due to an incorrect InfiniBand Adapter M3 Firmware version

Kdump might fail on Oracle Linux 7.6 if the Oracle Dual Port QDR InfiniBand Adapter M3 Firmware version 2.31.5350 is installed.

To prevent this issue from occurring, update the Oracle Dual Port QDR InfiniBand Adapter M3 Firmware version to at least 2.31.5350. (Bug ID 26351183)

Disabling an InfiniBand CA port generates warnings

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)

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

If RemoveIPC=yes 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 server systems. 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.6 configures RemoveIPC=no in /etc/systemd/logind.conf to prevent systemd from terminating IPC. However, if you have touched this file before updating your system to Oracle Linux 7.6, the update installs the new version of the file as /etc/systemd/logind.conf.rpmnew and does not set RemoveIPC=no in /etc/systemd/logind.conf. To avoid database crashes, set RemoveIPC=no in /etc/systemd/logind.conf and run the systemctl reboot command to reboot the system. (Bug ID 22224874)

Unable to create Oracle Linux 7 LXC containers on NFS

The creation of 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 releases, (Updates 4 and 5) is built to use the Linux file extended attributes [xattr(7)] security capabilities(7). Because the NFS protocol 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.4 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.3 container.

This issue occurs on both NFSv3 and NFSv4.

Note that Oracle Linux 6 containers are not affected. (Bug ID 25024258)

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)

Hyper-V related services fail to start on Oracle Linux 7 guest with UEK R4 kernel under Windows Hyper-V Server

If you are running UEK R4 or an earlier release on Oracle Linux 7, the hypervkvpd and hypervvssd services fail to start if the Hyper-V packages are at version 0-0.29.20160216git.el7 or later.

To avoid this issue, upgrade to UEK R4U5 or later.

(Bug ID 24745861)

Geneve network driver support not available in UEK releases prior to UEK R5

The ip and iproute commands included with Oracle Linux 7.6 include support for Geneve-capable devices. The module for this driver is included with the RHCK but is not included in UEK R4. The commands to set, add or view Geneve devices are only functional when used with the RHCK or with UEK R5. (Bug ID 24652835).

`NetworkManager` fails to respond to IPv6 addresses on low priority networks with DHCP on UEK R4

When running UEK R4 on Oracle Linux 7.6, NetworkManager fails to send a response to low priority networks with DHCP on UEK R4. Networks with higher priority (link-local, IPv6 fe80:/64 routes) take priority over the lower priority networks. This behavior might result in the DHCPv6 server failing to send a response to a DHCP client on a lower priority network, even if the network has another output device. (Bug ID 27714775)

Network connection icon reports incorrect state for interfaces

The network connection icon might report an active network interface as being 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)

Power button defaults to ACPI Suspend

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

In previous Oracle Linux versions, the hardware power button initiated a system shutdown. To make Oracle Linux 7 do the same, create a file named /etc/dconf/db/local.d/01-shutdown-button with the following content:

[org/gnome/settings-daemon/plugins/power]
button-power='shutdown'

Then run the following command:

sudo dconf update

You must log out of the desktop environment and log back in for the new setting to take effect. (Bug ID 25597898)

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

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 due to dependency relationships. The libvirt package has a dependency on the libvirt-daemon-driver-nwfiler package and this package has a dependency on libpcap. Removing libpcap removes the entire libvirt family of packages. (Bug ID 28582266)

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

When upgrading from a system prior to Oracle Linux 7.4, where the rdma-core.noarch package is installed, 32-bit versions of the packages and many dependencies are also installed, unnecessarily. This problem occurs because the original version of the package is obsoleted, and during upgrade, the package is replaced with both the rdma-core.i686 and rdma-core.x86_64 versions of the package, along with those packages' dependencies.

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

sudo yum update --exclude=\*.i686

(Bug ID 28217831)

dmstats report output does not return any data

The dmstats report command does not recognize any of the device mapper targets that are present on a system and returns no output when it is run. The issue is a regression in the upstream package and can be resolved by downgrading the device-mapper packages, if required. (Bug ID 28642757)

microcode_ctl failed early load check for "intel-06-4f-01"

During installation and while booting, an error may appear in the system log:

dracut:    microcode_ctl: kernel version "4.14.35-1818.3.3.el7uek.x86_64"
failed early load check for "intel-06-4f-01", skipping

The intel ucode 06-4f-01 file is incorrectly excluded from initramfs for boot-time microcode updates on some kernel versions. This affects certain Intel Xeon E5 v4 CPUs, one of the models formerly known as Broadwell. Oracle Server X6-2 uses this CPU model. The message is harmless provided the BIOS is current for any system using this processor model, as the BIOS will perform the required update. This issue is planned to be addressed in an errata update for microcode_ctl. (Bug ID 28879995)