Known Issues

Installation Issues

The following are known installation issues that are reported in Oracle Linux 8.

ULN registration wizard not displayed on first boot after an installation

On new installations of Oracle Linux 8, the ULN registration wizard that presents the options to register with ULN and to use Oracle Ksplice is not displayed on first boot.

As an alternative, you can register with ULN after the installation completes. For instructions, see https://linux.oracle.com/.

(Bug ID 29933974)

Syslog Error: Failed to insert module 'ip_tables': Operation not permitted

During an Oracle Linux 8 installation, the following message can be observed in the /var/log/messages:systemd log:

1]: Failed to insert module 'ip_tables': Operation not permitted

This error can be safely ignored, as the ip_tables kernel module subsequently and can be verified by running the following command:

grep IPTABLES /boot/config*

The following output indicates the module loaded successfully:

CONFIG_IP_NF_IPTABLES=m
CONFIG_IP6_NF_IPTABLES=m

You can also check that the module loaded successfully by running the following command:

modinfo ip_tables

The output of the previous command indicates the module loaded successfully:

filename:      
/lib/modules/4.18.0-32.el8.x86_64/kernel/net/ipv4/netfilter/ip_tables.ko.xz
alias:          ipt_icmp
description:    IPv4 packet filter
author:         Netfilter Core Team <coreteam@netfilter.org>
license:        GPL
rhelversion:    8.0
srcversion:     3967C875058C2EE2475C9C2
depends:        
retpoline:      Y
intree:         Y
name:           ip_tables
vermagic:       4.18.0-32.el8.x86_64 SMP mod_unload modversions
sig_id:         PKCS#7
signer:        
sig_key:        
sig_hashalgo:   md4
signature:      30:82:02:59:06:09:2A:86:48:86:F7:0D:01:07:02:A0:82:02:4A:30:
82:02:46:02:01:01:31:0D:30:0B:06:09:60:86:48:01:65:03:04:02:
01:30:0B:06:09:2A:86:48:86:F7:0D:01:07:01:31:82:02:23:30:82:
02:1F:02:01:01:30:7A:30:62:31:22:30:20:06:03:55:04:0A:0C:19:
4F:72:61:63:6C:65:20:41:6D:65:72:69:63:61:2C:20:49:6E:63:2E:
2C:63:3D:55:53:31:19:30:17:06:03:55:04:03:0C:10:4F:72:61:63:
.
.
.

(Bug ID 29500599)

Graphics controller requirements for an installation on an Oracle VM VirtualBox guest

To successfully install Oracle Linux 8 on an Oracle VM VirtualBox guest, where the graphical installation program is used and the default Server with GUI environment is selected, you must set the guest to use the VMSVGA graphics controller and configure the guest with at least 64MB of memory. Otherwise, the graphical display is unable to start correctly.

Beginning with Oracle VM VirtualBox 6.0, the VMSVGA graphics controller is the default controller for guests running Linux operating systems. This issue is more likely to appear if install Oracle Linux 8 on an existing guest that was created on an earlier Oracle VM VirtualBox release. To configure Oracle Linux 8 guests, Oracle recommends that you use Oracle VM VirtualBox 6.0 or later.

(Bug ID 30004543)

Installation on KVM guest by using iPXE and iSCSI boot results in incorrect IQN name

After installing Oracle Linux 8 on a KVM guest by using iPXE and iSCSI boot, the SCSI Qualified Name (IQN) in the /etc/iscsi/initiatorname.iscsi file is not correct.

Note that this incorrect configuration could impact kdump functionality.

The workaround for this issue is to manually modify the /etc/iscsi/initiatorname.iscsi file with the correct IQN after the installation completes.

(Bug ID 29536715)

Oracle Linux 8 does not recognize SAS controllers on older Oracle Sun hardware

The Oracle Linux 8 installer does not recognize some Serial Attached SCSI (SAS) controllers that are found in older Oracle Sun server models. If you attempt to install Oracle Linux 8 on these server models, the installer does not recognize the local disk and the installation fails. Examples of these server models include, but are not limited to, the following: Oracle Sun Fire X4170 M2 Server, Oracle Sun Fire X4170 M3 Server, Oracle Sun OVCA X3-2 Server, and the Oracle Sun X4-2 Server.

The following SAS controllers are removed from the mpt2sas driver in RHCK:

SAS2004, PCI ID 0x1000:0x0070
SAS2008, PCI ID 0x1000:0x0072
SAS2108_1, PCI ID 0x1000:0x0074
SAS2108_2, PCI ID 0x1000:0x0076
SAS2108_3, PCI ID 0x1000:0x0077
SAS2116_1, PCI ID 0x1000:0x0064
SAS2116_2, PCI ID 0x1000:0x0065
SSS6200, PCI ID 0x1000:0x007E

The following SAS controllers are removed from the megaraid_sas driver in RHCK:

Dell PERC5, PCI ID 0x1028:0x15
SAS1078R, PCI ID 0x1000:0x60
SAS1078DE, PCI ID 0x1000:0x7C
SAS1064R, PCI ID 0x1000:0x411
VERDE_ZCR, PCI ID 0x1000:0x413
SAS1078GEN2, PCI ID 0x1000:0x78
SAS0079GEN2, PCI ID 0x1000:0x79
SAS0073SKINNY, PCI ID 0x1000:0x73
SAS0071SKINNY, PCI ID 0x1000:0x71

The workaround for this issue to use the Unbreakable Enterprise Kernel Release 6 (UEK R6) boot ISO, and then run UEK R6 with Oracle Linux 8, as these controllers are supported in the Unbreakable Enterprise Kernel release.

(Bug ID 29120478)

GPG key file location must be explicitly set when adding repositories

If you are using the dnf config-manager --add-repo command to add a repository, the command does not add the GPG key file location configuration for that repository. The result is a package installation failure; as by default, dnf enables gpgcheck, but it requires the GPG key to be set or imported.

One workaround for this issue is to run the following command to ensure that the GPG key file location is set and imported:

sudo rpm --import "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle"

Another workaround is to add/set the GPG key for all of the individual repository entries under /etc/yum.repos.d, for example:

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

(Bug ID 29535274)

File System Issues

The following are known file systems issues that have been encountered in this release of Oracle Linux 8.

ext4: File system corruption occurs when both quota and dioread_nolock options are enabled

An issue with ext4 in Oracle Linux 8 results in file system corruption if unwritten extents are converted in IO completion so that they can be merged with siblings and both the dioread_nolock and quota options are enabled. This is a corner-case issue that exists in upstream code. A proposed patch is currently under review.

(Bug ID 29688421)

ext4: Frequent or repeated system shutdowns can cause file system corruption

If a system that is using the ext4 file system is repeatedly or frequently shut down, the file system might become corrupted. This issue is difficult to replicate and is therefore considered to be a corner-case issue. The issue exists in the upstream code and proposed patches are currently under review.

(Bug ID 27547113)

XFS: Existence of many unlinked tmp files causes file system corruption

An issue has been identified with XFS in Oracle Linux 8, where many unlinked tmp files are created, which causes file system corruption and results in the inability to recover after a system crash. This issue, the cause of which is currently unknown, has been observed when running a stress test.

(Bug ID 29682399)

XFS: xfs_repair interprets a slash (/) character in extended attribute name as corruption

An issue exists in Oracle Linux 8 that causes the xfs_repair utility to interpret a slash (/) character in an extended attribute name as file system corruption. The issue exists in upstream code and a proposed patch is currently under review.

(Bug ID 29680752)

XFS: Incorrect mkfs parameters cause file system corruption

If you run the mkfs utility and set invalid extent hints, the file system is created, but it becomes corrupted and cannot be mounted. The following error is displayed:

[18143.814821] XFS (sdb1): Failed to read root inode 0x80, error 117
mount: /mnt: mount(2) system call failed: Structure needs cleaning.

(Bug ID 29602175)

Kernel Issues

The following are known kernel issues that have been encountered in this release of Oracle Linux 8.

KVM guests boot with "amd64_edac_mod: Unknown symbol" errors on AMD 64-bit platforms

The following errors might be displayed repeatedly when KVM guests are booting on 64-bit AMD hosts:

[   12.474069] amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err [ 120)
[   12.474083] amd64_edac_mod: Unknown symbol amd_report_gart_errors (err 0)
[   12.852250] amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err 0)
[   12.852297] amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err 0)
.
.
.

These errors occur because the module code for the kernel erroneously returns -EEXIST for modules that failed to load and are in the process of being removed from the module list. The amd64_edac_mod module will not be loaded in a VM. These errors can be ignored, as they do not impact functionality in any way.

This issue occurs on Oracle Linux 8 hosts that are running RHCK only and is not encountered on UEK R6 hosts.

(Bug ID 29853602)

Output of modinfo command does not show Retpoline support

A bug in the Oracle Linux 8 code causes Retropline support to not be displayed in the output of the modinfo -F retpoline command, even though the CONFIG_RETPOLINE flag is set to Y, for example:

sudo modinfo -F retpoline
/usr/lib/modules/4.18.0-80.el8.x86_64/kernel/sound/usb/usx2y/snd-usb-us122l.ko
.xz

The CONFIG_RETPOLINE=Y flag is still required to add and display Retpoline support. If the parameter is enabled, the kernel builds with a retpoline capable compiler.

To confirm that the CONFIG_RETPOLINE flag is enabled, search for the parameter in the kernel's config-kernel configuration file, for example:

cat /boot/config-5.4.17-2011.7.4.el8uek.x86_64 | grep RETPOLINE.

CONFIG_RETPOLINE=y

(Bug ID 29894295)

Kdump service fails to start on systems with Secure Boot enabled

In Oracle Linux 8, the Kdump service fails to start on systems that have Secure Boot enabled. This issue has been observed on both bare metal systems, as well as KVM guests. The following errors are reported by syslog:

Jun 24 03:12:18 vmx209-ps kdumpctl[930]: kexec_file_load failed: Required key
not available
Jun 24 03:12:18 vmx209-ps kdumpctl[930]: kexec: failed to load kdump kernel
Jun 24 03:12:18 vmx209-ps kdumpctl[930]: Starting kdump: [FAILED]
Jun 24 03:12:18 vmx209-ps systemd[1]: kdump.service: Failed with result
'exit-code'.
Jun 24 03:12:18 vmx209-ps systemd[1]: Failed to start Crash recovery kernel
arming.

If you want to use Kdump, the easiest workaround for this issue is to disable Secure Boot.

If you require Secure Boot and wish to continue to use Kdump, you can consider updating the UEFI key database for your system. The key database is used as a store for the key certificates issued by a vendor, so that signed EFI binaries can be validated when the system is operating in secure mode. To perform this update you may require physical access to the system to access the UEFI console and enroll the key there. You can use the Machine Owner Key (MOK) facility to update the UEFI Secure Boot key database and import the keys manually. The certificate keys that are used to sign each kernel are contained in the shim source packages that are used to verify the keys the kernels use.

Important:

Using the MOK utility with your system may depend on server firmware implementation and configuration. Check that your server supports this before attempting to manually update signature keys used for UEFI Secure Boot. If you are unsure, do not follow the instructions provided here.

Adding certificates to the UEFI Secure Boot key database by using the MOK utility requires that you have physical access to the system so that you can complete the enrollment request at the UEFI console. If you do not have physical access to the system, do not follow the instructions that are provided here.

Certificates used to sign each kernel, built by Oracle, are contained in the shim source package. You can download this package using the yumdownloader command available in the dnf-utils package:
```
sudo dnf install -y dnf-utils
sudo mkdir /tmp/shim
cd /tmp/shim
sudo yumdownloader --source shim
```
Extract the source package to access the Extended Validation certificate that is included as a secureboot.cer file. Use the rpm2cpio command to extract the package:
```
sudo rpm2cpio ./shim*.rpm | cpio -idmv
```
Use the mokutil command to request that the certificate that you have extracted from the shim package is included in the MOK list:
```
sudo mokutil --import ./secureboot.cer
```
The command prompts you to enter and confirm a password for the MOK enrollment request. You can use any password for this purpose, but you should note the password that you use, as you are prompted for it again when the system reboots.
Reboot the system.
The pending MOK key enrollment request is detected, and you must complete the enrollment from the UEFI console. You are prompted for the password that you set when you imported the certificate. When you have entered the correct password, the certificate is added to the MOK list and is automatically propagated to the system key ring on this boot, as well as subsequent boots.

(Bug ID 29954639)

Kdump runs out of memory when attempting to mount /sysroot on FC disks that use the Logical Volume Manager

An issue in Oracle Linux 8 causes Kdump to run out of memory if you attempt to mount /sysroot on a Fibre Channel (FC) disk that uses LVM. This issue is due to a lack of memory when the crashkernel loads.

To resolve the issue, you can do one of the following:

Override the crashkernel=auto boot option so that more memory is reserved for Kdump. For example, set the kernel boot parameter to crashkernel=512M.
Set the Kdump destination to a network location (NFS or SSH).

(Bug ID 29840266)

aarch64 only: Kdump tools fail to create vmcore.dmesg.txt on X-Gene 3 and ThunderX2 platforms

The Kdump crash dump tools fail to create a vmcore-dmesg.txt file (which is created with the vmcore file) on the X-Gene 3 and ThunderX2 platforms. This failure to create the vmcore-dmesg.txt file might result in a segmentation fault similar to the following:

...
kdump: saving to /sysroot//var/crash/127.0.0.1-2018-05-22-12:34:45/
kdump: saving vmcore-dmesg.txt
/lib/kdump-lib-initramfs.sh: line 118:   459 Segmentation fault      
$_dmesg_collector /proc/vmcore > ${_path}/vmcore-dmesg-incomplete.txt
kdump: saving vmcore-dmesg.txt failed
kdump: saving vmcore
Copying data                                      : [100.0 %] \          
eta: 0s
kdump: saving vmcore complete

You can retrieve the dmesg output manually by running crash against the vmcore and using the dmesg command when in the crash shell.

(Bug ID 29709556)

aarch64 only: netconsole kernel module does not work with some devices

In Oracle Linux 8, the netconsole kernel module does not work with the Mellanox ConnectX devices (mlx4_core and mlx5_core driver modules) and the QLogic FastLinQ devices (qede driver module).

(Bug IDs 29778572, 29692757, and 29691892)

aarch64 only: Kernel panic might occur during a kexec boot on X-Gene 3 platform

A kernel panic might occur sometimes during a kexec boot on the X-Gene 3 platform.

(Bug ID 29710047)

Networking Issues

The following are networking issues that might be encountered in this release of Oracle Linux 8.

tracepath6 does not parse destination IPv6 address correctly

Running the tracepath6 command fails to parse the destination IPv6 address correctly. Consequently, the tool traces a route to the wrong host.

To work around this issue, use a tool with similar capabilities to the tracepath6 command.

(Bug ID 29540588)

Failure to insert ip_tables module

The ip_tables module fails to insert with an 'Operation not permitted' error. This issue, which is currently under investigation, can occur if SELinux is in enforcing mode.

A workaround for this issue is to set SELinux to permissive mode, which you can do temporarily by running the setenforce 0 command. Or, you can set SELinux to permissive mode permanently by editing the /etc/selinux/config file and then rebooting the system.

(Bug ID 29517166)

aarch64 only: mlx5_core driver fails on X-Gene 3 platform with MTU setting greater than 1500

Mellanox ConnectX-5 devices (the mlx5_core driver module) fail to work on the X-Gene 3 platform with an MTU setting that is greater than 1500.

(Bug ID 29692676)

Restarting firewalld service results in SSH connection timeout

Restarting the firewalld service leads to an SSH connection timeout on the terminal from which the service was started. Note that other SSH terminals remain connected.

(Bug ID 29478124)

/var/run/rhnsd.pid file not readable after starting Spacewalk daemon

Oracle Linux 8 systems fail to read PID from /var/run/rhnsd.pid after the Spacewalk daemon starts.

The following error is reported in the /var/log/messages log:

systemd: Failed to read PID from file /var/run/rhnsd.pid: Invalid argument

This error can be safely ignored.

(Bug ID 2953130)

Error: "mcelog service does not support this processor"

An error indicating that the mcelog service does not support the processor can appear in the system log on systems with AMD processors, such as some Oracle Server hardware. The message might be displayed as follows:

mcelog: ERROR: AMD Processor family
23: mcelog does not support this processor.  Please use the edac_mce_amd
module instead.

The mcelog daemon is a service that is used on x86_64 platforms to log and handle hardware error messaging. On AMD systems, the edac_mce_amd kernel module handles machine exception logging. Therefore, AMD systems do not require the mcelog daemon. This error should be downgraded to a warning.

(Bug ID 29501190)

Podman Issues

The following are known issues for the Podman container management tool in this release of Oracle Linux 8.

Executing podman attach --latest causes panic if no containers are available

If you execute podman attach --latest and no containers exist in your environment, a runtime error occurs:

panic: runtime error: index out of range
...

Note that this error no longer occurs as soon as there are containers in the environment. Running the command when there are no containers is meaningless.

(Bug ID 29882537)

Requirements for using the default podman detach key sequence

The default key sequence that you use to detach a container (CTRL+P, CTRL+Q) requires a console that can handle detachment (pseudo-tty), as well as an input channel for passing control signals (stdin). Otherwise, you cannot create a container, attach it with the podman attach -l command, and then quit or detach the container by using the default key sequence, as documented in the podman-attach(1) manual

page.

To ensure that you can use the default CTRL+P, CTRL+Q key sequence to detach a container, use either of the following methods to create a container:

Create a container in the background:
```
podman run --rm -t -d container-registry.oracle.com/os/oraclelinux:7 top -b
```
You can then use the podman attach -l command to attach the container and the CTRL+P, CTRL+Q key sequence to detach the container.
Create a container interactively:
```
podman run --rm -t -i container-registry.oracle.com/os/oraclelinux:7 top -b
```
The interactive method creates the container and automatically attaches it. You can then use the CTRL+P, CTRL+Q key sequence to detach the container.

For more information, see the podman(1) and podman-attach(1) manual pages.

(Bug ID 29882852)

Authentication error displayed when attempting to pull an image and not specifying its correct name

If you attempt to pull an image by running the podman pull image-name command, but you do not specify the correct or full name of the image, an authentication error occurs.

For example, the following error is displayed because oracle:latest was specified as the name of the image instead of oraclelinux:latest, which is the correct name for the image:

Trying to pull registry.redhat.io/oracle:latest...Failed
Trying to pull quay.io/oracle:latest...Failed
Trying to pull docker.io/oracle:latest...Failed
error pulling image "oracle:latest": unable to pull oracle:latest: 3 errors
occurred:

* Error determining manifest MIME type for
docker://registry.redhat.io/oracle:latest: unable to retrieve auth token:
invalid username/password
* Error determining manifest MIME type for docker://quay.io/oracle:latest:
Error reading manifest latest in quay.io/oracle: error parsing HTTP 404
response body: invalid character '<' looking for beginning of value:
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>404 Not
Found</title>\n<h1>Not Found</h1>\n<p>The requested URL was not found on the
server.  If you entered the URL manually please check your spelling and try
again.</p>\n"
* Error determining manifest MIME type for docker://oracle:latest: Error
reading manifest latest in docker.io/library/oracle: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

To prevent this error from occurring, always specify the correct image name with the podman pull command.

(Bug ID 29894231)

Non-root user cannot export a running container as a tar archive when container is created by same non-root user

Although a non-root user can create a privileged running container, running the podman export -o tar_name.tar container_name command to export the container as a tar archive fails if it is run by the same non-root user.

If you have root access, the workaround for this issue is to create the privileged running container as the root user and also export it as the root user.

(Bug ID 29890374)

Oracle Container Registry unable to service requests to search catalog

Attempts to search for an image in the Oracle Container Registry by using the podman search command fail with an authorization error, even if you are logged into the registry:

ERRO[0001] error getting search results from v2 endpoint
"container-registry.oracle.com", status code 401 (Unauthorized)
...

The issue is related to how Oracle Container Registry handles token requests for access to "/v2/_catalog". The podman search command only requests a token for ping-level access and not for catalog access.

There is currently no workaround for this issue.

(Bug ID 29942671)

SELinux: "Class bpf not defined in policy" and "Class xdp_socket not defined in policy" errors occur during a boot

Rebooting an Oracle Linux 8 system in either SELinux permissive mode or enforcing mode produces the following messages in the /var/log/messages file:

SELinux:  Class bpf not defined in policy.
SELinux:  Class xdp_socket not defined in policy.
SELinux: the above unknown classes and permissions will be allowed

These messages are displayed because no definitions currently exist for these classes in SELinux policy. Per the last line of the message, classes and permissions will be allowed by default; and therefore, the messages can be safely ignored.

(Bug ID 29502976)