Chapter 10. Known issues

The auth and authconfig Kickstart commands require the AppStream repository

The authselect-compat package is required by the auth and authconfig Kickstart commands during installation. Without this package, the installation fails if auth or authconfig are used. However, by design, the authselect-compat package is only available in the AppStream repository. To work around this problem, verify that the BaseOS and AppStream repositories are available to the installer or use the authselect Kickstart command during installation. (BZ#1640697)

syspurpose addons have no effect on the subscription-manager attach --auto output.

In Red Hat Enterprise Linux 8, four attributes of the syspurpose command-line tool have been added: role , usage , service_level_agreement and addons . Currently, only role , usage and service_level_agreement affect the output of running the subscription-manager attach --auto command. Users who attempt to set values to the addons argument will not observe any effect on the subscriptions that are auto-attached. ( BZ#1687900 )

Postfix TLS fingerprint algorithm in the FIPS mode needs to be changed to SHA-256

By default in RHEL 8, postfix uses MD5 fingerprints with the TLS for backward compatibility. But in the FIPS mode, the MD5 hashing function is not available, which may cause TLS to incorrectly function in the default postfix configuration. To workaround this problem, the hashing function needs to be changed to SHA-256 in the postfix configuration file. For more details, see the related Knowledgebase article Fix postfix TLS in the FIPS mode by switching to SHA-256 instead of MD5 . ( BZ#1711885 )

Users can run sudo commands as locked users

In systems where sudoers permissions are defined with the ALL keyword, sudo users with permissions can run sudo commands as users whose accounts are locked. Consequently, locked and expired accounts can still be used to execute commands. To work around this problem, enable the newly implemented runas_check_shell option together with proper settings of valid shells in /etc/shells . This prevents attackers from running commands under system accounts such as bin . (BZ#1786990)

# dnf module enable libselinux-python
# dnf install libselinux-python

# dnf module install libselinux-python:2.8/common

# update-crypto-policies --set DEFAULT:NO-CAMELLIA

app pkcs15-init {
        framework pkcs15 {
                use_file_caching = false;
				The smart-card provisioning through pkcs15-init only works if you apply the previously described workaround.
				(BZ#1947025)
			
systemd cannot execute commands from arbitrary paths

					The systemd service cannot execute commands from /home/user/bin arbitrary paths because the SELinux policy package does not include any such rule. Consequently, the custom services that are executed on non-system paths fail and eventually log the Access Vector Cache (AVC) denial audit messages when SELinux denied access. To work around this problem, do one of the following:
						Execute the command using a shell script with the -c option. For example,
					
bash -c command

						Execute the command from a common path using /bin, /sbin, /usr/sbin, /usr/local/bin, and /usr/local/sbin common directories.
				(BZ#1860443)
			
selinux-policy prevents IPsec from working over TCP

					The libreswan package in RHEL 8.4 supports IPsec-based VPNs using TCP encapsulation. However, the selinux-policy package does not reflect this update. As a consequence, when you set Libreswan to use TCP, the ipsec service fails to bind to the given TCP port.
				To work around the problem, use a custom SELinux policy:
						Open a new .cil file in a text editor, for example:
					
# vim local_ipsec_tcp_listen.cil




    

						Insert the following rule:
					
(allow ipsec_t ipsecnat_port_t (tcp_socket (name_bind name_connect)))

						Save and close the file.
						Install the policy module:
					
# semodule -i local_ipsec_tcp_listen.cil

						Restart the ipsec service:
					
# systemctl restart ipsec

				As a result, Libreswan can bind and connect to the commonly used 4500/tcp port.
				(BZ#1931848)
			
Installation with the Server with GUI or Workstation software selections and CIS security profile is not possible

					The CIS security profile is not compatible with the Server with GUI and Workstation software selections. As a consequence, a RHEL 8 installation with the Server with GUI software selection and CIS profile is not possible. An attempted installation using the CIS profile and either of these software selections will generate the error message:
				
package xorg-x11-server-common has been added to the list of excluded packages, but it can't be removed from the current software selection without breaking the installation.

				To work around the problem, do not use the CIS security profile with the Server with GUI or Workstation software selections.
				(BZ#1843932)
			
rpm_verify_permissions fails in the CIS profile

					The rpm_verify_permissions rule compares file permissions to package default permissions. However, the Center for Internet Security (CIS) profile, which is provided by the scap-security-guide packages, changes some file permissions to be more strict than default. As a consequence, verification of certain files using rpm_verify_permissions fails.
				To work around this problem, manually verify that these files have the following permissions:
						/etc/cron.d (0700)
						/etc/cron.hourly (0700)
						/etc/cron.monthly (0700)
						/etc/crontab (0600)
						/etc/cron.weekly (0700)
						/etc/cron.daily (0700)
				(BZ#1843913)
			
Kickstart uses org_fedora_oscap instead of com_redhat_oscap in RHEL 8

					The Kickstart references the Open Security Content Automation Protocol (OSCAP) Anaconda add-on as org_fedora_oscap instead of com_redhat_oscap which might cause confusion. That is done to preserve backward compatibility with Red Hat Enterprise Linux 7.
				(BZ#1665082)
			
Certain sets of interdependent rules in SSG can fail

					Remediation of SCAP Security Guide (SSG) rules in a benchmark can fail due to undefined ordering of rules and their dependencies. If two or more rules need to be executed in a particular order, for example, when one rule installs a component and another rule configures the same component, they can run in the wrong order and remediation reports an error. To work around this problem, run the remediation twice, and the second run fixes the dependent rules.
				(BZ#1750755)
			
OSCAP Anaconda Addon does not install all packages in text mode

					The OSCAP Anaconda Addon plugin cannot modify the list of packages selected for installation by the system installer if the installation is running in text mode. Consequently, when a security policy profile is specified using Kickstart and the installation is running in text mode, any additional packages required by the security policy are not installed during installation.
				To work around this problem, either run the installation in graphical mode or specify all packages that are required by the security policy profile in the security policy in the %packages section in your Kickstart file.
				As a result, packages that are required by the security policy profile are not installed during RHEL installation without one of the described workarounds, and the installed system is not compliant with the given security policy profile.
				(BZ#1674001)
			
OSCAP Anaconda Addon does not correctly handle customized profiles

					The OSCAP Anaconda Addon plugin does not properly handle security profiles with customizations in separate files. Consequently, the customized profile is not available in the RHEL graphical installation even when you properly specify it in the corresponding Kickstart section.
				To work around this problem, follow the instructions in the Creating a single SCAP data stream from an original DS and a tailoring file Knowledgebase article. As a result of this workaround, you can use a customized SCAP profile in the RHEL graphical installation.
				(BZ#1691305)
			
Remediating service-related rules during kickstart installations might fail

					During a kickstart installation, the OpenSCAP utility sometimes incorrectly shows that a service enable or disable state remediation is not needed. Consequently, OpenSCAP might set the services on the installed system to a non-compliant state. As a workaround, you can scan and remediate the system after the kickstart installation. This will fix the service-related issues.
				(BZ#1834716)
			
Certain rsyslog priority strings do not work correctly

					Support for the GnuTLS priority string for imtcp that allows fine-grained control over encryption is not complete. Consequently, the following priority strings do not work properly in rsyslog:
				
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+DHE-RSA:+AES-256-GCM:+SIGN-RSA-SHA384:+COMP-ALL:+GROUP-ALL

				To work around this problem, use only correctly working priority strings:
			
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+ECDHE-RSA:+AES-128-CBC:+SIGN-RSA-SHA1:+COMP-ALL:+GROUP-ALL

				As a result, current configurations must be limited to the strings that work correctly.
				(BZ#1679512)
			
Conflict in SELinux Audit rules and SELinux boolean configurations

					If the Audit rule list includes an Audit rule that contains a subj_* or obj_* field, and the SELinux boolean configuration changes, setting the SELinux booleans causes a deadlock. As a consequence, the system stops responding and requires a reboot to recover. To work around this problem, disable all Audit rules containing the subj_* or obj_* field, or temporarily disable such rules before changing SELinux booleans.
				With the release of the RHSA-2021:2168 advisory, the kernel handles this situation properly and no longer deadlocks.
				(BZ#1924230)
			

The nm-cloud-setup service removes manually-configured secondary IP addresses from interfaces

Based on the information received from the cloud environment, the nm-cloud-setup service configures network interfaces. Disable nm-cloud-setup to manually configure interfaces. However, in certain cases, other services on the host can configure interfaces as well. For example, these services could add secondary IP addresses. To avoid that nm-cloud-setup removes secondary IP addresses: Stop and disable the nm-cloud-setup service and timer:

# systemctl disable --now nm-cloud-setup.service nm-cloud-setup.timer

# nmcli connection show

# nmcli connection up "<profile_name>"

IPsec network traffic fails during IPsec offloading when GRO is disabled

IPsec offloading is not expected to work when Generic Receive Offload (GRO) is disabled on the device. If IPsec offloading is configured on a network interface and GRO is disabled on that device, IPsec network traffic fails. To work around this problem, keep GRO enabled on the device. (BZ#1649647)

Certain BCC utilities display a harmless warning

Due to macro redefinitions in some compiler specific kernel headers. Some BPF Compiler Collection (BCC) utilities show the following warning:

A vmcore capture fails after memory hot-plug or unplug operation

After performing the memory hot-plug or hot-unplug operation, the event comes after updating the device tree which contains memory layout information. Thereby the makedumpfile utility tries to access a non-existent physical address. The problem appears if all of the following conditions meet: A little-endian variant of IBM Power System runs RHEL 8. The kdump or fadump service is enabled on the system. Consequently, the capture kernel fails to save vmcore if a kernel crash is triggered after the memory hot-plug or hot-unplug operation. To work around this problem, restart the kdump service after hot-plug or hot-unplug:

# systemctl restart kdump.service

As a result, vmcore is successfully saved in the described scenario. (BZ#1793389)

ipcalc: command not found

To work around this problem: Install the ipcalc package manually.

dnf install ipcalc

kdumpctrl rebuild

systemctl restart kdump

Debug kernel fails to boot in crash capture environment in RHEL 8

Due to memory-demanding nature of the debug kernel, a problem occurs when the debug kernel is in use and a kernel panic is triggered. As a consequence, the debug kernel is not able to boot as the capture kernel, and a stack trace is generated instead. To work around this problem, increase the crash kernel memory accordingly. As a result, the debug kernel successfully boots in the crash capture environment. (BZ#1659609)

# modinfo <AFFECTED_DRIVER> | grep rhelversion

KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"

KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd"

[    2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace
[    2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]

03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=0us LTR1.2_Threshold=0ns
                L1SubCtl2: T_PwrOn=10us

Topology does not contain any NUMA node, aborting!

-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0

-mca pml_ucx_priority 5

As a result, the OPEN MPI library is able to choose an alternative available transport layer over UCX. (BZ#1866402)

The default 7 4 1 7 printk value sometimes causes temporary system unresponsiveness

The default 7 4 1 7 printk value allows for better debugging of the kernel activity. However, when coupled with a serial console, this printk setting can cause intense I/O bursts that can lead to a RHEL system becoming temporarily unresponsive. To work around this problem, we have added a new optimize-serial-console TuneD profile, which reduces the default printk value to 4 4 1 7 . Users can instrument their system as follows:

The /boot file system cannot be placed on LVM

You cannot place the /boot file system on an LVM logical volume. This limitation exists for the following reasons: On EFI systems, the EFI System Partition conventionally serves as the /boot file system. The uEFI standard requires a specific GPT partition type and a specific file system type for this partition. RHEL 8 uses the Boot Loader Specification (BLS) for system boot entries. This specification requires that the /boot file system is readable by the platform firmware. On EFI systems, the platform firmware can read only the /boot configuration defined by the uEFI standard. The support for LVM logical volumes in the GRUB 2 boot loader is incomplete. Red Hat does not plan to improve the support because the number of use cases for the feature is decreasing due to standards such as uEFI and BLS. Red Hat does not plan to support /boot on LVM. Instead, Red Hat provides tools for managing system snapshots and rollback that do not need the /boot file system to be placed on an LVM logical volume. (BZ#1496229)

The ocf:heartbeat:pgsql resource agent and any third-party agents that parse crm_mon output in their stop operation may fail to stop during a shutdown process in RHEL 8.4

In the RHEL 8.4 GA release, Pacemaker’s crm_mon command-line tool was modified to display a "shutting down" message rather than the usual cluster information when Pacemaker starts to shut down. As a result, shutdown progress, such as the stopping of resources, can not be monitored, and resource agents that parse crm_mon output in their stop operation (such as the ocf:heartbeat:pgsql agent distributed with the resource-agents package, or some custom or third-party agents) could fail to stop, leading to cluster problems. It is recommended that clusters that use the ocf:heartbeat:pgsql resource agent not be upgraded to RHEL 8.4 until the z-stream is available. ( BZ#1948620 )

getpwnam() might fail when called by a 32-bit application

When a user of NIS uses a 32-bit application that calls the getpwnam() function, the call fails if the nss_nis.i686 package is missing. To work around this problem, manually install the missing package by using the yum install nss_nis.i686 command. ( BZ#1803161 )

GCC Toolset 10: Valgrind erroneously reports IBM z15 architecture support

Valgrind does not support certain IBM z15 processors features yet, but a bug in GCC Toolset 10 Valgrind causes it to report z15 support when run on a z15-capable system. As a consequence, software that tries to use z15 features when available cannot run under Valgrind. To work around this problem, when running on a z15 processor, use the system version of Valgrind accessible via /usr/bin/valgrind. This build will not report z15 support. ( BZ#1937340 )

# systemctl edit pmproxy

[Service]
MemoryMax=10G

# systemctl restart pmproxy

As a result, the pmproxy service is restarted if the memory usage of pmproxy reaches the given limit. (BZ#1991659)

Installing KRA fails if all KRA members are hidden replicas

The ipa-kra-install utility fails on a cluster where the Key Recovery Authority (KRA) is already present, if the first KRA instance is installed on a hidden replica. Consequently, you cannot add further KRA instances to the cluster. To work around this problem, unhide the hidden replica that has the KRA role before you add new KRA instances. You can hide it again when ipa-kra-install completes successfully. ( BZ#1816784 )

# authselect select sssd --force

Disabling flatpak repositories from Software Repositories is not possible

Currently, it is not possible to disable or remove flatpak repositories in the Software Repositories tool in the GNOME Software utility. ( BZ#1668760 )

The guest operating system reported that it failed with the following error code: 0x1E

radeon fails to reset hardware correctly

The radeon kernel driver currently does not reset hardware in the kexec context correctly. Instead, radeon falls over, which causes the rest of the kdump service to fail. To work around this problem, disable radeon in kdump by adding the following line to the /etc/kdump.conf file:

dracut_args --omit-drivers "radeon"
force_rebuild 1

Restart the machine and kdump . After starting kdump , the force_rebuild 1 line may be removed from the configuration file. Note that in this scenario, no graphics will be available during kdump , but kdump will work successfully. (BZ#1694705)

virsh iface-\* commands do not work consistently

Currently, virsh iface-* commands, such as virsh iface-start and virsh iface-destroy , frequently fail due to configuration dependencies. Therefore, it is recommended not to use virsh iface-\* commands for configuring and managing host network connections. Instead, use the NetworkManager program and its related management applications. (BZ#1664592)

the CPU is incompatible with host CPU: Host CPU does not provide required features: hle, rtm

<feature policy='disable' name='hle'/>
<feature policy='disable' name='rtm'/>
<feature policy='disable' name='taa-no'/>

# perf kvm record -e trace_imc/trace_cycles/  -p <guest pid> -i

kdump sometimes does not start on Azure and Hyper-V

On RHEL 8 guest operating systems hosted on the Microsoft Azure or Hyper-V hypervisors, starting the kdump kernel in some cases fails when post-exec notifiers are enabled. To work around this problem, disable crash kexec post notifiers:

# echo N > /sys/module/kernel/parameters/crash_kexec_post_notifiers

(BZ#1865745)

device (eth0): linklocal6: DAD failed for an EUI-64 address

# Output what the /dev/disk/by-id/<value> for the specified hyper-v virtual disk.
# Takes a single parameter which is the virtual disk file.
# Note: kickstart syntax works with and without the /dev/ prefix.
param (
    [Parameter(Mandatory=$true)][string]$virtualdisk
$what = Get-VHD -Path $virtualdisk
$part = $what.DiskIdentifier.ToLower().split('-')
$p = $part[0]
$s0 = $p[6] + $p[7] + $p[4] + $p[5] + $p[2] + $p[3] + $p[0] + $p[1]
$p = $part[1]
$s1 =  $p[2] + $p[3] + $p[0] + $p[1]
[string]::format("/dev/disk/by-id/wwn-0x60022480{0}{1}{2}", $s0, $s1, $part[4])

PS C:\Users\Public\Documents\Hyper-V\Virtual hard disks> .\by-id.ps1 .\Testing_8\disk_3_8.vhdx
/dev/disk/by-id/wwn-0x60022480e00bc367d7fd902e8bf0d3b4
PS C:\Users\Public\Documents\Hyper-V\Virtual hard disks> .\by-id.ps1 .\Testing_8\disk_3_9.vhdx
/dev/disk/by-id/wwn-0x600224807270e09717645b1890f8a9a2

part / --fstype=xfs --grow --asprimary --size=8192 --ondisk=/dev/disk/by-id/wwn-0x600224807270e09717645b1890f8a9a2
part /home --fstype="xfs" --grow --ondisk=/dev/disk/by-id/wwn-0x60022480e00bc367d7fd902e8bf0d3b4

redhat-support-tool does not work with the FUTURE crypto policy

Because a cryptographic key used by a certificate on the Customer Portal API does not meet the requirements by the FUTURE system-wide cryptographic policy, the redhat-support-tool utility does not work with this policy level at the moment.