Chapter 11. Known issues

The fapolicyd framework does not fully support namespaces and containers. As a consequence, containers fail to start when fapolicyd is running.

To work around this problem, create the /etc/fapolicyd/rules.d/25-runc.rules file with the following content:

allow perm=any pattern=ld_so exe=/usr/bin/runc : all
allow perm=any uid=0 pattern=ld_so exe=/runc : trust=1

Save the file, run the fagenrules script, and enter the fapolicyd-cli --reload-rules command to apply the changes. Alternatively, you can remove the tmpfs value from the watch_fs option in the /etc/fapolicyd/fapolicyd.conf file and restart the fapolicyd service by using the systemctl restart fapolicyd command, but this lowers the system security.

As a result, you can use fapolicyd on systems running containers after you apply the previously described workaround. This preserves the enhanced security provided by fapolicyd and helps comply with configuration standards such as the Security Technical Implementation Guide (STIG) from the Defense Information Systems Agency (DISA).

Jira:RHEL-114562

The post-quantum cryptography (PQC) algorithms are not FIPS-validated and are not available in the FIPS provider. This causes the import of MLDSA-87 PQC keys into the RPM database and PQC signature verification to fail in FIPS mode.

To work around this problem, do not enable the DNF plugin to support PQC signatures in FIPS mode. As a result, the system verifies packages in FIPS mode through classical signatures.

Jira:RHEL-111478^[1]

The rpm-sequoia library fails to verify dual-signed RPM packages if one of the algorithms used for signing is disabled in system-wide cryptographic policies. This problem is common on systems that have post-quantum (PQ) algorithms disabled and cannot install packages signed with both classic and PQ cryptography.

To prevent breaking the system, the enablement of PQ algorithms for rpm-sequoia is hardcoded on the crypto-policies level. As a result, PQ algorithms for rpm-sequoia are enabled regardless of any settings in crypto-policies.

Jira:RHEL-112697

RHEL provides default udev rules that automatically configure memory onlining when you hot plug memory to virtual machines (VMs) with virtio-mem. However, current udev rules do not include VMs running on IBM Z. As a consequence, after hot-plugging memory to VMs running on IBM Z with virtio-mem, the memory is not immediately available in the VM.

To work around this problem, set the memhp_default_state=online kernel parameter in the VM and reboot it. For example:

# grubby --update-kernel=ALL --args=memhp_default_state=online

As a result, the hot-plugged memory is available in the VM.

Jira:RHEL-92781

If you configure IPsec cryptographic offload on a Mellanox ConnectX network interface controller (NIC) in Single-Root I/O Virtualization (SR-IOV) switchdev mode with the flow steering mode set to Software Managed Flow Steering (SMFS), the hardware offload for inbound IPsec Security Associations (SAs) fails. In this case, the ip xfrm state dir in show command returns the following error:

Error: mlx5_core: Device failed to offload this state.

To work around this problem, switch to Device-Managed Flow Steering (DMFS) before switching the device to switchdev mode. By using DMFS, the inbound IPsec state can successfully be offloaded to the hardware.

Jira:RHEL-114873^[1]

kdump does not support using NVMe over TCP (NVMe/TCP) connected namespaces as dump devices. If you configure an NVMe/TCP namespace for kdump, the crash dump process fails and no dump is collected. Consequently, the system cannot save the vmcore file during a kernel crash.

Jira:RHEL-109510^[1]

The MariaDB 10.5 and MySQL database management systems do not use the sysusers.d directories to populate users and working directories. MariaDB 10.5 and MySQL also do not use the tmpfiles.d directory. As a consequence, the database user can be missing and the database systems are not able to initialize because their working directory is missing. There is currently no workaround for this issue.

Jira:RHELDOCS-21366^[1]

VMs with the following configuration fail to boot if you set the host-phys-bits-limit parameter to 49 or more:

Instead, attempting to boot the VM fails with ERROR: Out of aligned pages.

Workaround: Set the host-phys-bits-limit parameter to 48 or less.

Jira:RHEL-82759

The podman build and buildah build commands avoid introducing inconsistencies between builds that use the same set of inputs when you invoke them with the following arguments:

To work around this problem, invoke the podman build or buildah build commands with the --rewrite-timestamp and --source-date-epoch arguments to minimize build inconsistencies. Additionally, update tools invoked in RUN instructions to avoid producing nondeterministic output when the $SOURCE_DATE_EPOCH environment variable is set.

Some tools or tool versions might still produce nondeterministic output, and you might not be able to build specific images reproducibly.

Jira:RHEL-62749

The command-line assistant does not recognize the Satellite certificate authority (CA) certificate for the Red Hat Satellite server. The Satellite CA certificate is used to issue and sign certificates for hosts that register with and are managed by Satellite. As a consequence, the command-line assistant cannot establish secure connections to the Satellite server, which prevents it from functioning correctly.

Work around: copy the Satellite CA certificate to the system trust store and update the CA trust database:

$ sudo cp /etc/rhsm/ca/katello* /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust

Jira:RHELDOCS-21325^[1]

FIPS mode is not supported by RHEL image builder. When using RHEL image builder customized with the xccdf_org.ssgproject.content_profile_stig profile remediation, the system fails to boot with the following error:

Warning: /boot//.vmlinuz-<kernel version>.x86_64.hmac does not exist
FATAL: FIPS integrity test failed
Refusing to continue

Enabling the FIPS policy manually after the system image installation with the fips-mode-setup --enable command does not work, because the /boot directory is on a different partition. System boots successfully if FIPS is disabled. Currently, there is no workaround available.

Jira:RHEL-4649

When using system-reinstall-bootc or bootc install on Azure, RHEL images marked as LVM will require resizing the default layout.

Workaround: Use RHEL images labeled as RAW. This does not require resizing the default layout.

Jira:RHELDOCS-19945^[1]

While using the inst.repo= or inst.stage2= boot options in the kernel command line along with a remote installation URL, an encrypted DNS, and a custom CA certificate in the Kickstart file, the installation program attempts to download the install.img stage2 image before processing the Kickstart file. Consequently, the hostname resolution fails, leading to display of some errors before successfully fetching the stage2 image.

Workaround: Define the installation source in the Kickstart file instead of the kernel command line.

Jira:RHEL-80867

When configuring a bonding device with LACP by using both kernel command-line boot options and a Kickstart file, the connection is created during the initramfs stage but reactivated in Anaconda. As a consequence, it causes a temporary disruption that leads to system subscription failure through the rhsm Kickstart command.

Workaround: Add --no-activate to the Kickstart network configuration to keep the network operational. As a result, the system subscription completes successfully.

Jira:RHELDOCS-19852^[1]

Deploying a bootc container image on a package mode system without enough free disk space can result in installation errors and prevent the system from booting. Ensure adequate disk space is available for the image to install and adjust the provision logical volume before deployment.

Jira:RHELDOCS-19948^[1]

Image mode for RHEL supports pp64le and s390x architectures besides the already supported x86_64 and ARM architectures. However, Anaconda might not function correctly on s390x and ppc64le architectures.

Jira:RHELDOCS-19496^[1]

The patch for BZ#2108969, released with the RHBA-2022:8295 advisory, introduced the following regression: The DNF upgrade using security filters fails for packages that change their architecture from or to noarch through the upgrade. Consequently, it can leave the system in a vulnerable state.

To work around this problem, perform the regular upgrade without security filters.

Jira:RHELPLAN-128381^[1]

The MariaDB database is a fork of MySQL. Over time, these services developed independently and are no longer fully compatible. These differences also affect the Perl database drivers. Consequently, if you use the DBD::mysql driver in a Perl application to connect to a MariaDB database, or the DBD::MariaDB driver to connect to a MySQL database, operations can lead to unexpected results. For example, the driver can return incorrect data from read operations. To avoid such problems, use the Perl driver in your application that matches the database service.

Red Hat only supports the following scenarios:

Note that RHEL 8 contained only the DBD::mysql driver. If you plan to upgrade to RHEL 9 and then to RHEL 10 and your application uses a MariaDB database, install the perl-DBD-MariaDB package after the upgrade and modify your application to use the DBD::MariaDB driver.

For further details, see the Red Hat Knowledgebase solution Support of MariaDB/MySQL cross-database connection from Perl db drivers.

Jira:RHELDOCS-19728^[1]

The Digital Phase-Locked Loop (DPLL) system experienced several issues, including uninitialized mutex usage and incorrect handling of pin phase adjustments, particularly during Physical Function (PF) resets. These issues led to unstable management of DPLL and pin configurations, causing inconsistent data states and connection mismanagement.

Workaround: To resolve this, mutexes were properly initialized, and mechanisms for updating pin phase adjustments, DPLL data, and connection states during PF resets were corrected. As a result, the DPLL system now performs reliably during resets, with accurate phase adjustments and consistent connection states, improving the overall stability of clock synchronization.

Jira:RHEL-36283^[1]

In some cases,ppc64le systems encounter a kernel panic when using the io_uring kernel parameter due to intensive input-output operations. As a consequence, ppc64le stops working and requires a system restart. The data might get lost during the crash.

Workaround: Disable the io_uring feature by adding the following kernel parameter at boot time:

module.builtin=io_uring=0

Jira:RHEL-28702^[1]

When you boot a Windows VM with Virtualization Based Security (VBS) enabled and an Input-Output Memory Management Unit (IOMMU) device by using the qemu-kvm utility, the booting sequence only shows the boot screen, resulting in an incomplete booting process.

Workaround: Ensure the VM domain XML is configured as below:

<features>
  <ioapic driver='qemu'/>
</features>
<devices>
<iommu model='intel'>
   <driver intremap='on' eim='off' aw_bits='48'/>
   <alias name='iommu0'/>
</iommu>
<memballoon model='virtio'>
   <alias name='balloon0'/>
   <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
   <driver iommu='on' ats='on'/>
</memballoon>
</devices>

Otherwise, the Windows VM cannot boot.

Jira:RHEL-45585^[1]

If you attempt to start a virtual machine (VM) with a large amount of bootable data disks, the VM might fail to boot with this error: Something has gone seriously wrong: import_mok_state() failed: Volume Full

Workaround: Decrease the number of bootable data disks and use one system disk. To ensure the system disk is first in the boot order, add boot order=1 to the device definition of the system disk in the XML configuration. For example:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/path/to/disk.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <boot order='1'/>
</disk>

Set boot order only for the system disk.

Jira:RHEL-68418

When assigned with 32 or more vCPUs, Windows Server 2025 virtual machines (VMs) slow down on a Red Hat Enterprise Linux host. Consequently, a Windows VM may boot slowly or be stuck during boot when the VM is configured with a large number of vCPUs.

Workaround: You can use the workaround at your own risk. Boot VM with small number of vCPUs to disable plaformclock on Windows Server. In command prompt with administrator privileges, run:

bcdedit /set useplatformclock no

Then, shut down the VM and reconfigure it with the desired large number of vCPUs. Also make sure that the hv-time option is enabled before starting the large VM again.

Jira:RHEL-62742^[1]

Currently, if you start the installation of virtio-win drivers from the VirtIO-Win installer bundle in a Windows guest operating system, clicking the Cancel button during the installation does not correctly stop it. The installer wizard interface displays a "Setup Failed" screen, but the drivers are installed and the IP address of the guest is reset.

Jira:RHEL-53962, Jira:RHEL-53965

Currently, Windows Virtualization-based Security (VBS) is not compatible with hot-plugging CPU and memory resources. As a consequence, attempting to attach memory or vCPUs to a running Windows virtual machine (VM) with VBS enabled only adds the resources to the VM after the guest system is restarted.

Jira:RHEL-66229, Jira:RHELDOCS-19066

When you launch a Red Hat Enterprise Linux VM of Azure platform with the Accelerated Networking feature, also known as Single Root Input Output Virtualization (SR-IOV), multiple network interface cards may have the same MAC address. Consequently, the VM may fail to acquire an IP address from a DHCP server and NetworkManager-wait-online.service may fail to start at boot time.

Workaround: Do not install the initscripts-rename-device package so that existing devices will not rename to existing device names.

Jira:RHEL-79783^[1]

Currently, it is possible to attempt hot-plugging memory to a RHEL 9 guest on VMware hypervisor even if the memory size of the attached memory dpes not align with the size of the individual memory blocks. However, attaching memory in this manner always fails with a Block size unaligned hotplug range error.

Workaround: Only hot-plug memory that is divisible by the configured memory block size on the guest. To obtain the memory block size, use the lsmem command. For further information, see The Red Hat KnowledgeBase.

Jira:RHEL-81748^[1]

With the Hyper-V enabled setting, Hyper-V Windows Server 2016 VM fails to boot on the AMD EPYC CPU host.

Workaround: Check for the following log message:

kvm: Booting SMP Windows KVM VM with !XSAVES && XSAVEC.
If it fails to boot try disabling XSAVEC in the VM config.

And try adding xsavec=off to -cpu cmdline to boot Hyper-V Windows Server 2016 VM.

Jira:RHEL-38957^[1]

When you experience a kernel crash on a Red Hat Enterprise Linux VM on the Azure Confidential VM instances, in this case DCv5 and ECv5 series, the kdump process may not complete and the VM becomes unresponsive. As a result, after a forced reboot, there is a vmcore-incomplete file.

Jira:RHEL-70228^[1]

Building a disk image on a host by using Podman with enabled the FIPS mode fails with the exit code 3 because of the update-crypto-policies package:

# Enable the FIPS crypto policy
# crypto-policies-scripts is not installed by default in RHEL-10
RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS

Workaround: Build the bootc image with FIPS mode disabled.

Jira:RHELDOCS-19539

When making changes in the etc/xdg/command-line-assistant/config.toml configuration file, it takes around 30 to 60 seconds for the command-line assistant daemon to recognize the changes, instead of applying the changes immediately. The command-line assistant is also missing the reload functionality.

Workaround: Follow the steps:

Jira:RHELDOCS-19734^[1]

Trying to build an ISO disk image from a GPG or a simple signed container results in an error, similar to the following:

manifest - failed
Failed
Error: cannot run osbuild: running osbuild failed: exit status 1
2024/04/23 10:56:48 error: cannot run osbuild: running osbuild failed: exit status 1

This happens because the system fails to get the image source signatures.

Workaround: You can either remove the signature from the container image or build a derived container image. For example, to remove the signature, you can run the following command:

$ sudo skopeo copy --remove-signatures containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4 containers-storage:registry.redhat.io/rhel9/rhel-bootc:9.4
$ sudo podman run \
       --rm \
       -it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ~/images/iso:/output \
       quay.io/centos-bootc/bootc-image-builder \
       --type iso --local \
       registry.redhat.io/rhel9/rhel-bootc:9.4

To build a derived container image, and avoid adding a simple GPG signatures to it, see the Signing container images product documentation.

Jira:RHEL-34807

Accessing a file system in the rescue mode triggers SELinux to autorelabel the file system on the next boot, which continues until SELinux runs in the permissive mode. Consequently, the system might go into an infinite loop of reboots after exiting the rescue mode as it cannot delete the /.autorelabel file.

Workaround: Switch to the permissive mode by adding enforcing=0 to the kernel command line on the next boot. The system displays a warning message as a preventive measure that informs about the possibility of this issue when accessing the file system in the rescue mode.

Jira:RHEL-14005

With the OpenSSL TLS toolkit 3.2.1 introduced in RHEL 9.5, you can no longer create certificates in the X.509 version 1 format using the openssl CA tool. The X.509 v1 format does not meet current web requirements.

Jira:RHEL-40605

In Red Hat Enterprise Linux 9.4 and earlier, when you specified an IPv6 address for an IPsrcaddr resource, the IPsrcaddr resource agent created a duplicate route with a different metric when the metric was used for the subnet. For example, this happened when NetworkManager created another IP address on the IPv6 subnet. In this situation, the IPsrcaddr resource failed to start because there was more than one match for the IP address. As of Red Hat Enterprise Linux 9.5, the IPsrcaddr resource agent specifies the metric of an existing route when it is available and a second route is not created. If, however, you created an IPaddr2 IPv6 resource that uses an IPv6 address before this upgrade, you must reboot your system to remove the duplicate route entry.

Jira:RHEL-32265^[1]

When using SeaBIOS to boot a virtual machine (VM) from a disk that uses logical or physical sector size of 4096 bytes, the boot disk is not displayed as available, and booting the VM fails. To boot a VM from such a disk, use UEFI instead of SeaBIOS.

Jira:RHEL-7110

On virtual machines (VM) that use a Windows guest operating system, enabling Hyper-V enlightenments in some cases does not result in the expected improvement in the CPU usage of the VM. There is currently no workaround for this issue.

Jira:RHEL-17331^[1]

Virtual machines (VMs) that use a Windows Server 2019 guest operating system currently fail to boot when they are configured to use more than 128 cores for a single virtual CPU (vCPU). Instead of booting, the VM displays a stop error on a blue screen.

Workaround: Use fewer than 128 core per vCPU.

Jira:RHELDOCS-18863^[1]

If the Kickstart file uses the services --enabled=…​ directive to enable systemd services and packages containing the specified service file are not included in the %packages section, the RHEL installation process fails with the following error:

Error enabling service <name_of_the_service>

Workaround: Include the respective package with the service file in Kickstart’s %packages section. As a result, RHEL installation completes, enabling expected services during installation.

Jira:RHEL-9633^[1]

When fapolicyd is installed with the Ansible DISA STIG profile, a race condition causes the trustdb database to be out of sync with the rpmdb database. As a consequence, missing files in trustdb cause denials on the system.

Workaround: Restart fapolicyd or run the Ansible DISA STIG profile again.

Jira:RHEL-24345^[1]

OpenSSH does not record a timeout before authentication for $IP port $PORT to the log. This might be important because the Fail2Ban intrusion prevention daemon and similar systems use these log records in its mdre-ddos regular expression and no longer ban the IPs of clients that attempt this type of attack. There is currently no known workaround for this problem.

Jira:RHEL-45727

The OSPP subpolicy has been aligned with Commercial National Security Algorithm (CNSA) 1.0. This affects the interoperability of hosts that use the FIPS:OSPP policy-subpolicy combination, with the following major aspects:

Jira:RHEL-2735^[1]

ReaR image creation by using the rear mkrescue or rear mkbackup command fails with the following message:

grub2-mkstandalone may fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/x86_64-efi/moddep.lst file)
(...)
grub2-mkstandalone: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.

The missing files are part of the grub2-efi-x64-modules package. If you install this package, the rescue image is created successfully without any errors. When the UEFI Secure Boot is enabled, the rescue image is not bootable because it uses a boot loader that is not signed.

Workaround: Add the following variables to the /etc/rear/local.conf or /etc/rear/site.conf ReaR configuration file:

UEFI_BOOTLOADER=/boot/efi/EFI/redhat/grubx64.efi
SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi

With the suggested workaround, the image can be produced successfully even on systems without the grub2-efi-x64-modules package, and it is bootable on systems with Secure Boot enabled. In addition, during the system recovery, the bootloader of the recovered system is set to the EFI shim bootloader.

For more information about UEFI, Secure Boot, and shim bootloader, see the UEFI: what happens when booting the system Knowledge Base article.

Jira:RHELDOCS-18064^[1]

When you collect system usage statistics by using the sar or iostat utilities, the %util column produced by sar or iostat might contain invalid data.

Jira:RHEL-26275^[1]

The information in /etc/os-release was previously available by calling the lsb-release binary. This binary was included in the redhat-lsb package, which was removed in RHEL 9. Now, you can display information about the operating system, such as the distribution, version, code name, and associated metadata, by reading the /etc/os-release file. This file is provided by Red Hat and any changes to it will be overwritten with each update of the redhat-release package. The format of the file is KEY=VALUE, and you can safely source the data for a shell script.

Jira:RHELDOCS-16427^[1]

When using a QLogic Corp. FastLinQ QL45000 Series 10/25/40/50GbE, FCOE Controller automatically enables the lldpad daemon on systems running RHV. As a consequence, I/O operations are stopped with an error, for example, [qedf_eh_abort:xxxx]:1: Aborting io_req=ff5d85a9dcf3xxxx.

Workaround: DisableLink Layer Discovery Protocol (LLDP) and then enable it for interfaces that can be set on the vdsm configuration level. For more information, https://access.redhat.com/solutions/6963195.

Jira:RHEL-8104^[1]

By enabling the Input-Output Memory Management Unit (IOMMU) on AMD platforms when the BNX2I adapter is in use, a system fails to boot with the Direct Memory Access Remapping (DMAR) timeout errors.

Workaround: Disable the IOMMU before booting by using the kernel command-line option, iommu=off. As a result, the system boots without any errors.

Jira:RHEL-25730^[1]

To prevent remote code execution and mitigate CVE-2024-32004, stricter ownership checks have been introduced in Git for cloning local repositories. With this update, Git treats local repositories with potentially unsafe ownership as dubious.

As a consequence, if you attempt to clone from a repository locally hosted through git-daemon and you are not the owner of the repository, Git returns a security alert about dubious ownership and fails to clone or fetch from the repository.

Workaround: Explicitly mark the repository as safe by executing the following command:

git config --global --add safe.directory /path/to/repository

Jira:RHELDOCS-18435^[1]

If the online backup and the online automembership rebuild tasks attempt to acquire the same two locks in the opposite order, it can lead to an unrecoverable deadlock that requires you to stop and restart the server. To work around this problem, do not launch the online backup and the online automembership rebuild tasks in parallel.

Jira:RHELDOCS-18065^[1]

Currently, when you import a virtual machine (VM) in the RHEL web console on ARM64 architecture and then you try to interact with it in the VNC console, the console does not react to your input.

Additionally, when you create a VM in the web console on ARM64 architecture, the VNC console does not display the last lines of your input.

Jira:RHEL-31993^[1]

Microsoft SQL Server 2022 on RHEL 9.4 and later supports running as an SELinux-confined application. However, due to a limitation in Microsoft SQL Server, running the service as an SELinux-confined application does not work in high-availability mode.

Workaround: You can run Microsoft SQL Server as an unconfined application if you require the service to be high available.

Note that this limitation also impacts installing Microsoft SQL Server when you use the mssql RHEL System Role to install this service.

Jira:RHELDOCS-17719^[1]

Currently, you cannot set up TX queue size on KVM virtual machines (VMs) that use vhost-kernel as a back end for the virtio network driver. As a consequence, you can use only the default value of 256 for the TX queue, which might prevent you from optimizing your VM network throughput. There is currently no workaround for this issue.

Jira:RHEL-1138^[1]

When you boot a host, it does not detect any vulnerabilities in the spec_rstack_overflow parameter. After querying the parameter for logs, it displays the message:

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Mitigation: Safe RET

After booting a VM on the same host, the VM detects a vulnerability in the spec_rstack_overflow parameter. And when you query the parameter for logs, it displays the message:

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Vulnerable: Safe RET, no microcode

However, this is a false warning message, and you can ignore the status of the /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow file inside the VM.

Jira:RHEL-17614^[1]

Before booting the VM, set the status of Ethernet link down for the e1000 or igb model network interface. Despite this, after the VM boots, the network interface keeps the up status, because when you set the status of Ethernet link down and then stop and re-start the VM, it is automatically set back to up. Consequently, the correct state of network interface is not maintained.

Workaround: Set the network interface status to down inside the VM by using command:

# ip link set dev eth0 down

Alternatively, you can try to remove and add this network interface again while the VM is running.

Jira:RHEL-21867

The current script for generating runtime policies, create_runtime_policy.sh, uses SHA checksum functions, for example, sha256sum, to compute the file digest. However, when the input file name contains a backslash or \n, the checksum function adds a backslash before the digest in its output. In such cases, the generated policy file is malformed. When provided with the malformed policy file, the Keylime tenant produces the following or similar error message: me.tenant - ERROR - Response code 400: Runtime policy is malformatted.

Workaround: Remove the backslash from the malformed policy file manually by entering the following command: sed -i 's/^\\//g' <malformed_file_name>.

Jira:RHEL-11867^[1]

When the API version number of the Keylime agent (keylime-agent-rust) has been updated, the agent rejects requests that use a different version. As a consequence, if a Keylime agent is added to a verifier and then updated, the verifier tries to contact the agent using the old API version. The agent rejects this request and fails the attestation.

Workaround: Update the verifier (keylime-verifier) before updating the agent (keylime-agent-rust). As a result, when the agents are updated, the verifier detects the API change and updates its stored data accordingly.

Jira:RHEL-1518^[1]

Correctly, the IMA hash of a file should update after any change to the file, and fapolicyd should prevent execution of the changed file. However, this does not happen due to differences in IMA policy setup and in file hashing by the evctml utility. As a result, the IMA hash is not updated in the extended attribute of a changed file. Consequently, fapolicyd incorrectly allows the execution of the changed file.

Jira:RHEL-520^[1]

When you run the createrepo_c command on local repositories, it generates duplicate copies of repodata files, one of the copies is compressed and one is not.

Workaround: There is no workaround available, however, you can safely ignore the duplicate files. The createrepo_c command generates duplicate copies because of requirements and differences in other tools relying on repositories created by using createrepo_c.

Jira:RHELPLAN-112860^[1]

Installing the latest real-time kernel with the dnf package manager requires resolving package dependencies to retain the new and current kernel versions simultaneously. By default, dnf removes the older kernel-rt package during the upgrade.

Workaround: Add the current kernel-rt package to the installonlypkgs option in the /etc/yum.conf configuration file, for example, installonlypkgs=kernel-rt.

The installonlypkgs option appends kernel-rt to the default list used by dnf. Packages listed in installonlypkgs directive are not removed automatically and therefore support multiple kernel versions to install simultaneously.

Note that having multiple kernels installed is a way to have a fallback option when working with a new kernel version.

Jira:RHELPLAN-153123^[1]

For non-x86_64 architectures, when running kdump on systems with Linux Unified Key Setup (LUKS) encrypted partitions, systems require a certain amount of available memory. When the available memory is less than the required amount of memory, the systemd-cryptsetup service fails to mount the partition. Consequently, the second kernel fails to capture the crash dump file on the LUKS-encrypted targets.

Workaround: Query the Recommended crashkernel value and gradually increase the memory size to an appropriate value. The Recommended crashkernel value can serve as a reference to set the required memory size.

Jira:RHEL-11196^[1]

When the i40e adapter encounters an I/O error on IBM Power10 systems, the Enhanced I/O Error Handling (EEH) kernel services trigger the network driver’s reset and recovery. However, EEH repeatedly reports I/O errors until the i40e driver reaches the predefined maximum of EEH freezes. As a consequence, EEH causes the device to fail permanently.

Jira:RHEL-15404^[1]

NVMe/FC devices can be unavailable during parsing or execution of pre-scripts of the Kickstart file, which can cause the Kickstart installation to fail.

Workaround: Update the boot argument to inst.wait_for_disks=30. This option causes a delay of 30 seconds, and should provide enough time for the NVMe/FC device to connect. With this workaround along with the NVMe/FC devices connecting in time, the Kickstart installation proceeds without issues.

Jira:RHEL-8164^[1]

While installing the vdo package, RHEL installs the kmod-kvdo package and a kernel with 4k page size as dependencies. As a consequence, updates from RHEL 9.3 to 9.x fail because kmod-kvdo conflicts with the 64k kernel.

Workaround: Remove the vdo package and its dependencies before attempting to update.

Jira:RHEL-8354

The WebKitGTK web browser engine fails when trying to display web pages on the IBM Z architecture. The web page remains blank and the WebKitGTK process ends unexpectedly.

As a consequence, you cannot use certain features of applications that use WebKitGTK to display web pages, such as the following:

Jira:RHEL-4157

Currently, if you start a VM that uses an NVIDIA A16 GPU passthrough device, the NVIDIA A16 GPU physical device on the host system in some cases stops working.

To work around the problem, reboot the hypervisor and set the reset_method for the GPU device to bus:

# echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
# cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
bus

For details, see the Red Hat Knowledgebase.

Jira:RHEL-7212^[1]

On virtual machines (VMs) that use Windows guest operating systems, the system in some cases becomes unresponsive when under high I/O load. When this happens, the system logs a viostor Reset to device, \Device\RaidPort3, was issued error. There is currently no workaround for this issue.

Jira:RHEL-1609^[1]

Currently, a virtual machine (VM) that uses a Windows 10 guest operating system might become unresponsive during boot if a virtio-win-scsi PCI device with a local disk back end is attached to the VM.

Workaround: Boot the VM with the multi_queue option enabled.

Jira:RHEL-1084^[1]

Under certain circumstances, the virtio-balloon driver does not work correctly on virtual machines (VMs) that use a Windows 10 or Windows 11 guest operating system. As a consequence, such VMs might not use their assigned memory efficiently.

Jira:RHEL-12118

Currently, when a virtio file system (virtiofs) is configured on a virtual machine (VM) that uses a Windows guest operating system, the performance of virtiofs in the VM is significantly worse than in VMs that use Linux guests. There is currently no workaround for this issue.

Jira:RHEL-1212^[1]

On virtual machines (VMs) that use a Windows guest operating system, removing a storage device when the VM is running (also known as a device hot-unplug) in some cases fails. As a consequence, the storage device remains attached to the VM and the disk manager service might become unresponsive. There is currently no workaround for this issue.

Jira:RHEL-869

When hot plugging the maximum number of CPUs to a Windows virtual machine (VM) with huge pages enabled, the guest operating system might crash with the following Stop error:

PROCESSOR_START_TIMEOUT

There is currently no workaround for this issue.

Jira:RHEL-1220

When updating the KVM paravirtualized (virtio) drivers on a Windows virtual machine (VM), the update might cause the mouse to stop working and the newly installed drivers might not be signed. This problem occurs when updating the virtio drivers by installing from the virtio-win-guest-tools package, which is a part of the virtio-win.iso file.

Workaround: Update the virtio drivers by using Windows Device Manager.

Jira:RHEL-574^[1]

When attempting to boot a RHEL 9 virtual machine (VM) into the debug kernel, the booting might fail with the following error if the machine kernel is using the kmemleak=on argument.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

This problem affects mainly large VMs because they spend more time in the boot sequence.

Workaround: Edit the /etc/fstab file on the machine and add extra timeout options to the /boot and /boot/efi mount points. For example:

UUID=e43ead51-b364-419e-92fc-b1f363f19e49 /boot xfs defaults,x-systemd.device-timeout=600,x-systemd.mount-timeout=600 0 0

UUID=7B77-95E7 /boot/efi vfat defaults,uid=0,gid=0,umask=077,shortname=winnt,x-systemd.device-timeout=600,x-systemd.mount-timeout=600 0 2

Jira:RHELDOCS-16979^[1]

A new version of a driver from the driver update disc might not load if the same driver from the installation initial ramdisk has already been loaded. As a consequence, an updated version of the driver cannot be applied to the installation environment.

Workaround: Use the modprobe.blacklist= kernel command line option together with the inst.dd option. For example, to ensure that an updated version of the virtio_blk driver from a driver update disc is loaded, use modprobe.blacklist=virtio_blk and then continue with the usual procedure to apply drivers from the driver update disk. As a result, the system can load an updated version of the driver and use it in the installation environment.

Jira:RHEL-4762

Anaconda performs the Kickstart network configuration only through the NetworkManager API. Anaconda processes the network configuration after the %pre Kickstart section. As a consequence, some tasks from the Kickstart %pre section are blocked. For example, downloading packages from the %pre section fails due to unavailability of the network configuration.

Workaround:

As a result, it is possible to use the network for tasks in the %pre section and the Kickstart installation process completes.

Jira:RHELPLAN-150080^[1]

The OSCAP Anaconda add-on does not provide an option to select or deselect tailoring of security profiles in the RHEL graphical installation. Starting from RHEL 8.8, the add-on does not take tailoring into account by default when installing from archives or RPM packages. Consequently, the installation displays the following error message instead of fetching an OSCAP tailored profile:

There was an unexpected problem with the supplied content.

Workaround: You must specify paths in the %addon org_fedora_oscap section of your Kickstart file, for example:

xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml
tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml

As a result, you can use the graphical installation for OSCAP tailored profiles only with the corresponding Kickstart specifications.

Jira:RHEL-1824

When Keylime receives a certificate chain as multiple certificates in the PEM format concatenated in a single file, the keylime-agent-rust Keylime component does not correctly use all the provided certificates during signature verification, resulting in a TLS handshake failure. As a consequence, the client components (keylime_verifier and keylime_tenant) cannot connect to the Keylime agent.

Workaround: Use just one certificate instead of multiple certificates.

Jira:RHELPLAN-157225^[1]

On systems with limited memory, the OpenSCAP scanner might stop prematurely or it might not generate the results files. To work around this problem, you can customize the scanning profile to deselect rules that involve recursion over the entire / file system:

Workaround: See the related Knowledgebase article.

Jira:RHELPLAN-145263^[1]

The sysstat package provides the %vmeff metric to measure the page reclaim efficiency. The values of the %vmeff column returned by the sar -B command are incorrect because sysstat does not parse all relevant /proc/vmstat values provided by later kernel versions.

Workaround: You can calculate the %vmeff value manually from the /proc/vmstat file. For details, see Why the sar(1) tool reports %vmeff values beyond 100 % in RHEL 8 and RHEL 9?

Jira:RHEL-12009

The OpenSLP provides a dynamic configuration mechanism for applications in local area networks, such as printers and file servers. However, SLP is vulnerable to a reflective denial of service amplification attack through UDP on systems connected to the internet. SLP allows an unauthenticated attacker to register new services without limits set by the SLP implementation. By using UDP and spoofing the source address, an attacker can request the service list, creating a Denial of Service on the spoofed address.

To prevent external attackers from accessing the SLP service, disable SLP on all systems running on untrusted networks, such as those directly connected to the internet.

Workaround: Configure firewalls to block or filter traffic on UDP and TCP port 427.

Jira:RHEL-6995^[1]

The libotr library and toolkit for off-the-record (OTR) messaging provides end-to-end encryption for instant messaging conversations. However, the libotr library does not conform to the Federal Information Processing Standards (FIPS) due to its use of the gcry_pk_sign() and gcry_pk_verify() functions. As a result, you cannot use the libotr library in FIPS mode.

Jira:RHELPLAN-122108^[1]

RHEL is compatible with both 4k and 64k page size kernels. Customer applications with dependencies on a 4k kernel page size might require updating when moving from 4k to 64k page size kernels. Known instances of this include jemalloc and dependent applications.

The jemalloc memory allocator library is sensitive to the page size used in the system’s runtime environment. The library can be built to be compatible with 4k and 64k page size kernels, for example, when configured with --with-lg-page=16 or env JEMALLOC_SYS_WITH_LG_PAGE=16 (for jemallocator Rust crate). Consequently, a mismatch can occur between the page size of the runtime environment and the page size that was present when compiling binaries that depend on jemalloc. As a result, using a jemalloc-based application triggers the following error:

<jemalloc>: Unsupported system page size

Workaround: To avoid this problem, use one of the following approaches:

For example, you can build the fd-find tool, which also uses jemalloc, with the cargo Rust package manager. In the final 64k environment, trigger a new build of all dependencies to resolve the mismatch in the page size by entering the cargo command:

# cargo install fd-find --force

Jira:RHELPLAN-147783^[1]

Large or moderate sized systems with numerous sockets and large core-counts can experience latency spikes due to lock contentions on xtime_lock, which is used in the timekeeping system. As a consequence, latency spikes and delays in hardware certifications might occur on multiprocessing systems.

Workaround: You can offset the timer tick per CPU to start at a different time by adding the skew_tick=1 boot parameter.

To avoid lock conflicts, enable skew_tick=1:

Note that enabling skew_tick=1 causes a significant increase in power consumption and, therefore, it must be enabled only if you are running latency sensitive real-time workloads.

Jira:RHEL-9318^[1]

Starting with RHEL 9.2, it is no longer possible to disable quota accounting on an XFS filesystem which has been mounted with quotas enabled.

Workaround: Disable quota accounting by remounting the filesystem, with the quota option removed.

Jira:RHELPLAN-145001^[1]

There is a udev rule change for NVMe devices that adds OPTIONS="string_escape=replace" parameter. This leads to a disk by-id naming change for some vendors, if the serial number of your device has leading whitespace.

Jira:RHELPLAN-154195^[1]

The python3.11-lxml package is distributed without the lxml.isoschematron submodule because it is not under an open source license. The submodule implements ISO Schematron support. As an alternative, pre-ISO-Schematron validation is available in the lxml.etree.Schematron class. The remaining content of the python3.11-lxml package is unaffected.

Jira:RHELPLAN-143480^[1]

The default RHEL 9 FIPS cryptographic policy aiming to comply with FIPS 140-3 does not allow the use of the AES HMAC-SHA1 encryption types' key derivation function as defined by RFC3961, section 5.1.

This constraint is a blocker when adding a RHEL 9 Identity Management (IdM) replica in FIPS mode to a RHEL 8 IdM environment in FIPS mode in which the first server was installed on a RHEL 8.6 system or earlier. This is because there are no common encryption types between RHEL 9 and the previous RHEL versions, which commonly use the AES HMAC-SHA1 encryption types but do not use the AES HMAC-SHA2 encryption types.

You can view the encryption type of your IdM master key by entering the following command on the server:

# kadmin.local getprinc K/M | grep -E '^Key:'

For more information, see the AD Domain Users unable to login in to the FIPS-compliant environment KCS solution.

Jira:RHEL-4888

The TLS Extended Master Secret (EMS) extension (RFC 7627) is now mandatory for TLS 1.2 connections on FIPS-enabled RHEL 9.2 and later systems. This is in accordance with FIPS-140-3 requirements. However, the openssl version available in RHEL 7.9 and lower does not support EMS. In consequence, installing a RHEL 7 Identity Management (IdM) client with a FIPS-enabled IdM server running on RHEL 9.2 and later fails.

Workaround: If upgrading the host to RHEL 8 before installing an IdM client on it is not an option, remove the requirement for EMS usage on the RHEL 9 server by applying a NO-ENFORCE-EMS subpolicy on top of the FIPS crypto policy:

# update-crypto-policies --set FIPS:NO-ENFORCE-EMS

Note that this removal goes against the FIPS 140-3 requirements. As a result, you can establish and accept TLS 1.2 connections that do not use EMS, and the installation of a RHEL 7 IdM client succeeds.

Jira:RHEL-4955

If firewalld.service is masked on a RHEL system, the firewall RHEL System Role fails.

Workaround: Unmask the firewalld.service:

systemctl unmask firewalld.service

Jira:RHELPLAN-133165^[1]

The rhc system role fails to register the system when specifying environment names in rhc_environment.

Workaround: Use environment IDs instead of environment names while registering.

Jira:RHEL-1172

Currently, assigning a vCPU to a running virtual machine (VM) with a Windows Server 2016 guest operating system might cause a variety of problems, such as the VM terminating unexpectedly, becoming unresponsive, or rebooting. There is currently no workaround for this issue.

Jira:RHELPLAN-63771^[1]

When using an Intel host machine with a RHEL 9.2 and later operating system, virtual machines (VMs) with a passed through NVDIA GPU device frequently log the following error message:

Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.

However, this error message does not impact the functionality of the VM and can be ignored. For details, see the Red Hat KnoweldgeBase.

Jira:RHELPLAN-141042^[1]

When the Open vSwitch (OVS) service restarts or crashes on a host, virtual machines (VMs) that are running on this host cannot recover the state of the networking device. As a consequence, VMs might be completely unable to receive packets.

This problem only affects systems that use the packed virtqueue format in their virtio networking stack.

Workaround: Use the packed=off parameter in the virtio networking device definition to disable packed virtqueue. With packed virtqueue disabled, the state of the networking device can, in some situations, be recovered from RAM.

Jira:RHEL-333

If a post-copy migration of a virtual machine (VM) is interrupted and then immediately resumed on the same incoming port, the migration might fail with the following error: Address already in use

Workaround: Wait at least 10 seconds before resuming the post-copy migration or switch to another port for migration recovery.

Jira:RHEL-7096

QEMU does not handle NUMA node mapping on AMD EPYC CPUs correctly. As a result, the performance of virtual machines (VMs) with these CPUs might be negatively impacted if using a NUMA node configuration. In addition, the VMs display a warning similar to the following during boot.

sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency.
WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80

Workaround: Do not use AMD EPYC CPUs for NUMA node configurations.

Jira:RHELPLAN-150884^[1]

Currently, using the virsh blkiotune --weight command to set the VM weight does not work as expected. The command fails to set the correct io.bfq.weight value in the cgroup I/O controller interface file. There is no workaround at this time.

Jira:RHELPLAN-83423^[1]

With the release of the RHSA-2023:3722 advisory, the TLS Extended Master Secret (EMS) extension (RFC 7627) is mandatory for TLS 1.2 connections on FIPS-enabled RHEL 9 systems. This is in accordance with FIPS-140-3 requirements. TLS 1.3 is not affected.

Legacy clients that do not support EMS or TLS 1.3 now cannot connect to FIPS servers running on RHEL 9 and 10. Similarly, RHEL 9 and 10 clients in FIPS mode cannot connect to servers that only support TLS 1.2 without EMS. This in practice means that these clients cannot connect to servers on RHEL 6, RHEL 7 and non-RHEL legacy operating systems. This is because the legacy 1.0.x versions of OpenSSL do not support EMS or TLS 1.3.

In addition, connecting from a FIPS-enabled RHEL client to a hypervisor such as VMWare ESX now fails with a Provider routines::ems not enabled error if the hypervisor uses TLS 1.2 without EMS. To work around this problem, update the hypervisor to support TLS 1.3 or TLS 1.2 with the EMS extension. For VMWare vSphere, this means version 8.0 or later.

For more information, see TLS Extension "Extended Master Secret" enforced with Red Hat Enterprise Linux 9.2 and later.

Jira:RHEL-13340^[1]

When deploying rpm-ostree payloads, used for example in a RHEL for Edge installer image, the installation program does not properly create some mount points for custom partitions. As a consequence, the installation stops with the following error:

The command 'mount --bind /mnt/sysimage/data /mnt/sysroot/data' exited with the code 32.

Workaround:

As a result, the installation process finishes successfully.

Jira:RHEL-4741

Starting with RHEL 9.0, Anaconda activates network devices automatically when there is no specific ip= or Kickstart network configuration set. Anaconda creates a default persistent configuration file for each Ethernet device. The connection profile has the ONBOOT and autoconnect value set to true. As a consequence, during the start of the installed system, RHEL activates the network devices, and the networkManager-wait-online service fails.

Workaround: Do one of the following:

Jira:RHELPLAN-130370^[1]

The scp utility changed from the Secure copy protocol (SCP) to the more secure SSH file transfer protocol (SFTP). Consequently, copying a file from a location to the same location erases the file content. The problem affects the following syntax:

scp localhost:/myfile localhost:/myfile

Workaround: Do not copy files to a destination that is the same as the source location using this syntax.

The problem has been fixed for the following syntaxes:

Jira:RHELPLAN-113842^[1]

If you update the iwl7260-firmware or iwl7260-wifi driver to the version provided with RHEL 9.1 or later, the hardware might enter in an incorrect state and report its status incorrectly. Consequently, Intel Wi-Fi 6 cards might fail to function properly and display the following error message:

kernel: iwlwifi 0000:09:00.0: Failed to start RT ucode: -110
kernel: iwlwifi 0000:09:00.0: WRT: Collecting data: ini trigger 13 fired (delay=0ms)
kernel: iwlwifi 0000:09:00.0: Failed to run INIT ucode: -110

Workaround: An unconfirmed workaround is to power off the system completely and then power it back on. Do not perform a reboot.

Jira:RHELPLAN-134771^[1]

The Delayed Accounting functionality, unlike early versions, is disabled by default. Consequently, the iotop application does not show the SWAPIN and IO% statistics columns and displays the following warning:

CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%

The Delay Accounting functionality, using the taskstats interface, provides the delay statistics for all tasks or threads that belong to a thread group. Delays in task execution occur when they wait for a kernel resource to become available, for example, a task waiting for a free CPU to run on. The statistics help in setting a task’s CPU priority, I/O priority, and rss limit values appropriately.

Workaround: You can enable the delayacct boot option either at run time or boot.

As a result, the iotop application displays the SWAPIN and IO% statistics columns.

Jira:RHELPLAN-135779^[1]

On the 64-bit IBM Z systems, the kdump service fails to load the initial RAM disk (initrd) when znet related configuration information such as s390-subchannels reside in an inactive NetworkManager connection profile. Consequently, the kdump mechanism fails with the following error:

dracut: Failed to set up znet
kdump: mkdumprd: failed to make kdump initrd

As a workaround, use one of the following solutions:

Jira:RHELPLAN-115732^[1]

The weak-modules script provided by the kmod package determines which modules are kABI-compatible with installed kernels. However, while checking modules' kernel compatibility, weak-modules processes modules symbol dependencies from higher to lower release of the kernel for which they were built. As a consequence, modules with inter-dependencies built against different kernel releases might be interpreted as non-compatible, and therefore the weak-modules script fails to work in this scenario.

Workaround: Build or put the extra modules against the latest stock kernel before you install the new kernel.

Jira:RHELPLAN-126922^[1]

Establishing a two-way cross-forest trust between Active Directory (AD) and Identity Management (IdM) with FIPS mode enabled fails because the New Technology LAN Manager Security Support Provider (NTLMSSP) authentication is not FIPS-compliant. IdM in FIPS mode does not accept the RC4 NTLM hash that the AD domain controller uses when attempting to authenticate.

Jira:RHEL-12154^[1]

By default, a Heimdal Kerberos client initiates the PKINIT authentication of an IdM user by using Modular Exponential (MODP) Diffie-Hellman Group 2 for Internet Key Exchange (IKE). However, the MIT Kerberos Distribution Center (KDC) on RHEL 9 only supports MODP Group 14 and 16.

Consequently, the pre-autentication request fails with the krb5_get_init_creds: PREAUTH_FAILED error on the Heimdal client and Key parameters not accepted on the RHEL MIT KDC.

Workaround: Ensure that the Heimdal client uses MODP Group 14. Set the pkinit_dh_min_bits parameter in the libdefaults section of the client configuration file to 1759:

[libdefaults]
pkinit_dh_min_bits = 1759

As a result, the Heimdal client completes the PKINIT pre-authentication against the RHEL MIT KDC.

Jira:RHELDOCS-19846^[1]

When installing RHEL using a graphical user interface, the User Creation screen is unresponsive. As a consequence, creating users during installation is more difficult.

Workaround: Use one of the following solutions to create users:

Jira:RHEL-11924^[1]

When live migrating a virtual machine (VM) with a configured virtual function (VF), such as a VMs that uses virtual SR-IOV software, the network of the VM is not visible to other devices and the VM cannot be reached by commands such as ping. After the migration is finished, however, the problem no longer occurs.

Jira:RHEL-7336

If you have used the ipa migrate-ds script to migrate users from one IdM deployment to another, those users might have problems using IdM services because their previously existing Security Identifiers (SIDs) do not have the domain SID of the current IdM environment. For example, those users can retrieve a Kerberos ticket with the kinit utility, but they cannot log in.

Workaround: See the following Knowledgebase article: Migrated IdM users unable to log in due to mismatching domain SIDs.

Jira:RHELPLAN-109613^[1]

Sometimes, Windows virtual machines fail to get an IP address after an automatic network interface reset. As a consequence, the VM fails to connect to the network.

Workaround: Disable and re-enable the network adapter driver in the Windows Device Manager.

Jira:RHEL-11366

When you configure a PCIe Address Translation Services (ATS) device in the XML configuration of virtual machine (VM) with a Windows guest operating system, the guest does not enable the ATS device after booting the VM. This is because Windows currently does not support ATS on virtio devices.

For more information, see the Red Hat KnowledgeBase.

Jira:RHELPLAN-118495^[1]

Currently, booting a RHEL virtual machine (VM) on the Microsoft Azure cloud platform fails if the VM was provisioned by the cloud-init tool and the guest operating system of the VM has an NFSv3 mount entry in the /etc/fstab file. There is currently no workaround for this issue.

Jira:RHELPLAN-120807^[1]

When booting the RHEL installation from a USB that is created using a third party tool, the installation program fails to detect the Local Media installation source (only Red Hat CDN is detected).

This issue occurs because the default boot option int.stage2= attempts to search for iso9660 image format. However, a third party tool might create an ISO image with a different format.

Workaround: Use either of the following solution:

For more information on the steps involved in performing any of the specified workaround, see, Installation media is not auto-detected during the installation of RHEL 8.3.

Jira:RHELPLAN-53644^[1]

While installing RHEL using a graphical user interface, Anaconda fails to verify if the administrator account has been created. As a consequence, users might install a system without any administrator user account.

Workaround: Ensure you configure an administrator user account or the root password is set and the root account is unlocked. As a result, users can perform administrative tasks on the installed system.

Jira:RHELPLAN-110191^[1]

PowerNV IBM POWER systems use a Linux kernel for firmware, and use Petitboot as a replacement for GRUB. This results in the firmware kernel mounting /boot and Petitboot reading the GRUB config and booting RHEL.

The RHEL 9 kernel introduces bigtime=1 and inobtcount=1 features to the XFS filesystem, which kernels with firmware older than version 5.10 do not understand.

Workaround: You can use another filesystem for /boot, for example ext4.

Jira:RHELPLAN-94811^[1]

When you install RHEL, the installation process sometimes becomes unresponsive. The /tmp/packaging.log file displays the following message at the end:

10:20:56,416 DDEBUG dnf: RPM transaction over.

Workaround: Restart the installation process.

Jira:RHELPLAN-118420^[1]

A bug in Anaconda prevents the services --disabled=firewalld command from disabling the firewalld service in Kickstart.

Workaround: Use the firewall --disabled command instead. As a result, the firewalld service is disabled properly.

Jira:RHEL-82566

Installing RHEL by using the kickstart method fails if the ignoredisk command is placed before the iscsi command. This issue occurs because the iscsi command attaches the specified iSCSI device during command parsing, while the ignoredisk command resolves device specifications simultaneously. If the ignoredisk command references an iSCSI device name before it is attached by the iscsi command, the installation fails with an "unknown disk" error.

Workaround: Ensure that the iscsi command is placed before the ignoredisk command in the Kickstart file to reference the iSCSI disk and enable successful installation.

Jira:RHEL-13837

The TLS 1.3 protocol requires support for RSA-PSS signatures. If a PKCS #11 token does not support raw RSA or RSA-PSS signatures, server applications that use the OpenSSL library fail to work with an RSA key if the key is held by the PKCS #11 token. As a result, TLS communication fails in the described scenario.

Workaround: Configure servers and clients to use TLS version 1.2 as the highest TLS protocol version available.

Jira:RHELPLAN-50959^[1]

The OpenSSL library does not detect key-related capabilities of PKCS #11 tokens. Consequently, establishing a TLS connection fails when a signature is created with a token that does not support raw RSA or RSA-PSS signatures.

Workaround: Add the following lines after the .include line at the end of the crypto_policy section in the /etc/pki/tls/openssl.cnf file:

SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384
MaxProtocol = TLSv1.2

As a result, a TLS connection can be established in the described scenario.

Jira:RHELPLAN-48241^[1]

With the replacement of Ansible Engine by the ansible-core package, the list of Ansible modules provided with the RHEL subscription is reduced. As a consequence, running remediations that use Ansible content included within the scap-security-guide package requires collections from the rhc-worker-playbook package.

For an Ansible remediation, perform the following steps:

As a result, the Ansible content is processed correctly.

Jira:RHEL-1800

The default state of the selinuxuser_execstack boolean in the SELinux policy is on, which means that unconfined executables can make their stack executable. Executables should not use this option, and it might indicate poorly coded executables or a possible attack. However, due to compatibility with other tools, packages, and third-party products, Red Hat cannot change the value of the boolean in the default policy. If your scenario does not depend on such compatibility aspects, you can turn the boolean off in your local policy by entering the command setsebool -P selinuxuser_execstack off.

Jira:RHELPLAN-115609^[1]

An update of OpenSSH affected the rules in the following Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) profiles:

In each of these profiles, the following two rules are affected:

Title: Set SSH Client Alive Count Max to zero
CCE Identifier: CCE-90271-8
Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0

Title: Set SSH Idle Timeout Interval
CCE Identifier: CCE-90811-1
Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout

When applied to SSH servers, each of these rules configures an option (ClientAliveCountMax and ClientAliveInterval) that no longer behaves as previously. As a consequence, OpenSSH no longer disconnects idle SSH users when it reaches the timeout configured by these rules.

Workaround: These rules have been temporarily removed from the DISA STIG for RHEL 9 and DISA STIG with GUI for RHEL 9 profiles until a solution is developed.

Jira:RHELPLAN-107318^[1]

The GNU Privacy Guard (GnuPG) cryptographic software can create and verify signatures that use the SHA-1 algorithm regardless of the settings defined by the system-wide cryptographic policies. Consequently, you can use SHA-1 for cryptographic purposes in the DEFAULT cryptographic policy, which is not consistent with the system-wide deprecation of this insecure algorithm for signatures.

Workaround: Do not use GnuPG options that involve SHA-1. As a result, you will prevent GnuPG from lowering the default system security by using the insecure SHA-1 signatures.

Jira:RHELPLAN-117566^[1]

In RHEL 9, certain systemd library dependencies have been converted from dynamic linking to dynamic loading, so that your system opens and uses the libraries at runtime when they are available. With this change, a functionality that depends on such libraries is not available unless you install the necessary library. This also affects setting the keyboard layout on systems with a minimal install. As a result, the localectl --no-convert set-x11-keymap gb command fails.

Workaround: Install the libxkbcommon library:

# dnf install libxkbcommon

Jira:RHEL-6105

A earlier update to NetworkManager changed the handling of team ports to resolve potential race conditions. As a result, when you defined a port configuration within the team controller’s connection profile, NetworkManager might ignore it. Consequently, utilities such as teamdctl might fail to display port-specific metadata, such as priority or sticky status, when you defined these settings in the team controller’s connection profile.

To work around this problem, manually copy the team port configuration from the controller to each individual port connection. For example, to migrate the configuration from the team0 profile to the enp1s0 and enp2s0 port profiles, enter:

for port in enp1s0 enp2s0; do
    # Copy the port configuration to port connections
    nmcli connection modify $port team-port.config "$(nmcli --escape no --get team.config connection show team0 | jq .ports.${port})"
done

# Delete the port configuration from the team connection
nmcli connection modify team0 team.config "$(nmcli --escape no --get team.config connection show team0 | jq 'del(.ports)')"

As a result, NetworkManager correctly applies the port-specific settings and management utilities display them correctly.

Jira:RHEL-87994

Kernel Transport Layer Security (kTLS) does not support offloading of TLS 1.3 to NICs. Consequently, software encryption is used with TLS 1.3 even when the NICs support TLS offload.

Workaround: Disable TLS 1.3 if offload is required. As a result, you can offload only TLS 1.2. When TLS 1.3 is in use, there is lower performance, since TLS 1.3 cannot be offloaded.

Jira:RHELPLAN-96004^[1]

Kernel Transport Layer Security (kTLS) protocol does not support updating the session key, which is used by the symmetric cipher. Consequently, the user cannot update the key, which causes a connection break.

Workaround: Disable kTLS. As a result, with the workaround, it is possible to successfully update the session key.

Jira:RHELPLAN-99859^[1]

On RHEL 9, the initscripts package is not installed by default. Consequently, renaming network interfaces using ifcfg files fails.

Workaround: To solve this problem, Red Hat recommends that you use udev rules or link files to rename interfaces. For further details, see Consistent network interface device naming and the systemd.link(5) man page.

If you cannot use one of the recommended solutions, install the initscripts package.

Jira:RHELPLAN-100926^[1]

By default, the initscripts package is not installed. As a consequence, the ifup and ifdown utilities are not available.

Workaround: As an alternative, use the nmcli connection up and nmcli connection down commands to enable and disable connections. If the suggested alternative does not work for you, report the problem and install the NetworkManager-initscripts-updown package, which provides a NetworkManager solution for the ifup and ifdown utilities.

Jira:RHELPLAN-121205^[1]

The Dynamic Kernel Module Support (dkms) utility does not recognize that the kernel headers for 64-bit ARM CPUs work for both the kernels with 4 kilobytes and 64 kilobytes page sizes. As a result, when the kernel update is performed and the kernel-64k-devel package is not installed, dkms provides an incorrect warning on why the program failed on correctly compiled drivers.

Workaround: Install the kernel-headers package, which contains header files for both types of ARM CPU architectures and is not specific to dkms and its requirements.

Jira:RHEL-25967^[1]

Using Device Mapper Multipath with the nvme-tcp driver can result in the Call Trace warnings and system instability. To work around this problem, NVMe/TCP users must enable native NVMe multipathing and not use the device-mapper-multipath tools with NVMe.

By default, Native NVMe multipathing is enabled in RHEL 9. For more information, see Enabling multipathing on NVMe devices.

Jira:RHELPLAN-105944^[1]

The chkconfig package, which updates and queries runlevel information for system services, is not installed by default in RHEL 9.

To manage services, use the systemctl commands or install the chkconfig package manually.

For more information about systemd, see Introduction to systemd. For instructions on how to use the systemctl utility, see Managing system services with systemctl.

Jira:RHELPLAN-112043^[1]

The --ssl-fips-mode option in MySQL and MariaDB in RHEL works differently than in upstream.

In RHEL 9, if you use --ssl-fips-mode as an argument for the mysqld or mariadbd daemon, or if you use ssl-fips-mode in the MySQL or MariaDB server configuration files, --ssl-fips-mode does not change FIPS mode for these database servers.

Instead:

This is expected because FIPS mode should be enabled or disabled for the whole RHEL system, not for specific components.

Therefore, do not use the --ssl-fips-mode option in MySQL or MariaDB in RHEL. Instead, ensure FIPS mode is enabled on the whole RHEL system:

Jira:RHELPLAN-92864^[1]

The bind and unbound components disable validation support of all RSA/SHA1 (algorithm number 5) and RSASHA1-NSEC3-SHA1 (algorithm number 7) signatures, and the SHA-1 usage for signatures is restricted in the DEFAULT system-wide cryptographic policy.

As a result, certain DNSSEC records signed with the SHA-1, RSA/SHA1, and RSASHA1-NSEC3-SHA1 digest algorithms fail to verify in Red Hat Enterprise Linux 9 and the affected domain names become vulnerable.

To work around this problem, upgrade to a different signature algorithm, such as RSA/SHA-256 or elliptic curve keys.

For more information and a list of top-level domains that are affected and vulnerable, see the DNSSEC records signed with RSASHA1 fail to verify solution.

Jira:RHELPLAN-117492^[1]

BIND does not allow the same writable zone file in multiple zones. Consequently, if a configuration includes multiple zones which share a path to a file that can be modified by the named service, named fails to start.

Workaround: Use the in-view clause to share one zone between multiple views and make sure to use different paths for different zones. For example, include the view names in the path.

Note that writable zone files are typically used in zones with allowed dynamic updates, secondary zones, or zones maintained by DNSSEC.

Jira:RHELPLAN-90604^[1]

The SHA-1 digest algorithm has been deprecated in RHEL 9, and CMS messages for Public Key Cryptography for initial authentication (PKINIT) are now signed with the stronger SHA-256 algorithm.

However, the Active Directory (AD) Kerberos Distribution Center (KDC) still uses the SHA-1 digest algorithm to sign CMS messages. As a result, RHEL 9 Kerberos clients fail to authenticate users by using PKINIT against an AD KDC.

Workaround: Enable support for the SHA-1 algorithm on your RHEL 9 systems with the following command:

 # update-crypto-policies --set DEFAULT:SHA1

Jira:RHELPLAN-114497^[1]

If a RHEL 9 Kerberos agent, either a client or Kerberos Distribution Center (KDC), interacts with a non-RHEL-9 Kerberos agent that is not an Active Directory (AD) agent, the PKINIT authentication of the user fails.

Workaround: Perform one of the following actions:

As a result, the PKINIT authentication of the user works correctly.

Note that for other operating systems, it is the krb5-1.20 release that ensures that the agent signs CMS data with SHA-256 instead of SHA-1.

See also ???TITLE???.

Jira:RHEL-4875

Active Directory (AD) uses AES SHA-1 HMAC encryption types, which are not allowed in FIPS mode on RHEL 9 by default. If you want to use RHEL 9 IdM hosts with an AD trust, enable support for AES SHA-1 HMAC encryption types before installing IdM software.

Since FIPS compliance is a process that involves both technical and organizational agreements, consult your FIPS auditor before enabling the AD-SUPPORT subpolicy to allow technical measures to support AES SHA-1 HMAC encryption types, and then install RHEL IdM:

 # update-crypto-policies --set FIPS:AD-SUPPORT

Jira:RHELPLAN-113281^[1]

After upgrading from RHEL 8 to RHEL 9, the VNC server fails to start, even if it was previously enabled.

Workaround: Manually enable the vncserver service after the system upgrade:

# systemctl enable --now vncserver@:port-number

As a result, VNC is now enabled and starts after every system boot as expected.

Jira:RHELPLAN-114314^[1]

Running xorg -configure to create the Xorg configuration file on virtual machines fails due to the lack of devices to configure. This issue leads to a configuration failure. To work around this issue, construct the xorg.conf file manually according to the guidelines stated in Xorg documentation, or use alternative mechanisms such as an Extended Display Identification Data (EDID) override to tweak display resolutions. With this workaround, the Xorg server functions with the correct configuration.

Jira:RHELDOCS-20196^[1]

Under certain conditions, the proprietary NVIDIA drivers disable the Wayland display protocol and revert to the X.org display server:

Additionally, Wayland is enabled but the desktop session uses X.org by default if the version of the NVIDIA driver is lower than 510.

Jira:RHELPLAN-119001^[1]

When the proprietary NVIDIA drivers are enabled on your system, the Night Light feature of GNOME is not available in Wayland sessions. The NVIDIA drivers do not currently support Night Light.

Jira:RHELPLAN-119852^[1]

X.org utilities for manipulating the screen do not work in the Wayland session. Notably, the xrandr utility does not work under Wayland due to its different approach to handling, resolutions, rotations, and layout.

Jira:RHELPLAN-121049^[1]

Currently, the virt-install utility fails when attempting to install a guest operating system (OS) from an ISO source over a https or ssh connection - for example using virt-install --cdrom https://example/path/to/image.iso. Instead of creating a virtual machine (VM), the described operation ends unexpectedly with an internal error: process exited while connecting to monitor message.

Similarly, using the RHEL 9 web console to install a guest operating system fails and displays an Unknown driver 'https' error if you use an https or ssh URL, or the Download OS function.

Workaround: Install qemu-kvm-block-curl and qemu-kvm-block-ssh on the host to enable https and ssh protocol support. Alternatively, use a different connection protocol or a different installation source.

Jira:RHELPLAN-99854^[1]

Currently, NVIDIA drivers are not compatible with the Wayland graphical session. As a consequence, RHEL guest operating systems that use NVIDIA drivers automatically disable Wayland and load an Xorg session instead. This primarily occurs in the following scenarios:

There is currently no workaround for this issue.

Jira:RHELPLAN-117234^[1]

When running a RHEL 9 guest operating system on a virtual machine (VM) hosted on the Nutanix AHV hypervisor, restoring the VM from a snapshot or cloning the VM currently causes non-root partitions in the VM to disappear if the guest is using Logical Volume Management (LVM). As a consequence, the following problems occur:

To work around these problems, do the following in emergency mode of the VM:

This makes it possible for the cloned or restored VM to boot up correctly.

Alternatively, to prevent the issue from occurring, do the following before cloning a VM or creating a VM snapshot:

Jira:RHELPLAN-114103^[1]

On certain AMD Milan systems, the Enhanced REP MOVSB (erms) and Fast Short REP MOVSB (fsrm) feature flags are disabled in the BIOS by default. Consequently, the Milan CPU type might not be available on these systems. In addition, VM live migration between Milan hosts with different feature flag settings might fail.

Workaround: Manually turn on erms and fsrm in the BIOS of your host.

Jira:RHELPLAN-119655^[1]

After removing a hostdev network interface with failover configuration from a running virtual machine (VM), the interface currently cannot be re-attached to the same running VM. There is currently no workaround for this issue.

Jira:RHEL-7337

Currently, attempting to post-copy migrate a running virtual machine (VM) fails if the VM uses a device with the virtual function (VF) failover capability enabled.

Workaround: Use the standard migration type, rather than post-copy migration.

Jira:RHEL-7335

On a host machine that uses a CPU with Advanced Vector Extensions (AVX) support, attempting to boot a VM with AVX explicitly disabled currently fails, and instead triggers a kernel panic in the VM. There is currently no workaround for this issue.

Jira:RHELPLAN-97394^[1]

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.

Workaround: Verify that the BaseOS and AppStream repositories are available to the installation program or use the authselect Kickstart command during installation.

Jira:RHELPLAN-10061^[1]

When Anaconda is running as an application on an already installed system (for example to perform another installation to an image file using the -image anaconda option), the system is not prohibited to modify the SELinux types and attributes during installation. As a consequence, certain elements of SELinux policy might change on the system where Anaconda is running.

Workaround: Do not run Anaconda on the production system. Instead, run Anaconda in a temporary virtual machine to keep the SELinux policy unchanged on a production system. Running anaconda as part of the system installation process such as installing from boot.iso or dvd.iso is not affected by this issue.

Jira:RHELPLAN-110940^[1]

Installation fails when the USB CD-ROM drive is the source for it and the Kickstart ignoredisk --only-use= command is specified. In this case, Anaconda cannot find and use this source disk.

Workaround: Use the harddrive --partition=sdX --dir=/ command to install from USB CD-ROM drive. As a result, the installation does not fail.

Jira:RHEL-4707

You cannot install RHEL on systems where the hard drive is partitioned with the iso9660 filesystem. This is due to the updated installation code that is set to ignore any hard disk containing a iso9660 file system partition. This happens even when RHEL is installed without using a DVD.

Workaround: Add the following script in the Kickstart file to format the disc before the installation starts.

Note: Before performing the workaround, backup the data available on the disk. The wipefs command formats all the existing data from the disk.

%pre
wipefs -a /dev/sda
%end

As a result, installations work as expected without any errors.

Jira:RHEL-4711

Performing a RHEL installation with the reboot --kexec Kickstart command or the inst.kexec kernel boot parameters do not provide the same predictable system state as a full reboot. As a consequence, switching to the installed system without rebooting can produce unpredictable results.

Note that the kexec feature is deprecated and will be removed in a future release of Red Hat Enterprise Linux.

Jira:RHELDOCS-20471^[1]

A race condition in the storage subsystem causes the installation to fail when writing the partition table to disk. The system displays the following error message:

Partition(s) have been written, but we have been unable to inform the kernel of the change.

This error occurs because the partitions are reported as busy and the changes cannot be synchronized. To work around this problem, restart the installation.

Jira:RHEL-158237

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.

Workaround: You can scan and remediate the system after the kickstart installation. This will fix the service-related issues.

Jira:RHELPLAN-44202^[1]

In systemd, the default block deactivation code does not always handle complex stacks of virtual block devices correctly. In some configurations, virtual devices might not be removed during the shutdown, which causes error messages to be logged.

Workaround: Deactivate complex block device stacks by executing the following command:

# systemctl enable --now blk-availability.service

As a result, complex virtual device stacks are correctly deactivated during shutdown and do not produce error messages.

Jira:RHELPLAN-99108^[1]

When using ldap:// without TLS for identity lookups, it can pose a risk for an attack vector. Particularly a man-in-the-middle (MITM) attack which could allow an attacker to impersonate a user by altering, for example, the UID or GID of an object returned in an LDAP search.

Currently, the SSSD configuration option to enforce TLS, ldap_id_use_start_tls, defaults to false. Ensure that your setup operates in a trusted environment and decide if it is safe to use unencrypted communication for id_provider = ldap. Note id_provider = ad and id_provider = ipa are not affected as they use encrypted connections protected by SASL and GSSAPI.

If it is not safe to use unencrypted communication, enforce TLS by setting the ldap_id_use_start_tls option to true in the /etc/sssd/sssd.conf file. The default behavior is planned to be changed in a future release of RHEL.

Jira:RHELPLAN-155168^[1]

During the integration of SSSD with Active Directory, SSSD retrieves incomplete group member lists when the group size exceeds 1500 members. This issue occurs because Active Directory’s MaxValRange policy, which restricts the number of members retrievable in a single query, is set to 1500 by default.

Workaround: Change the MaxValRange setting in Active Directory to accommodate larger group sizes.

Jira:RHELDOCS-19603^[1]

When running the sos report command on IBM Power Systems, Little Endian with hundreds or thousands of CPUs, the processor plugin reaches its default timeout of 300 seconds when collecting huge content of the /sys/devices/system/cpu directory. As a workaround, increase the plugin’s timeout accordingly:

# sos report -k processor.timeout=1800

[plugin_options]
# Specify any plugin options and their values here. These options take the form
# plugin_name.option_name = value
#rpm.rpmva = off
processor.timeout = 1800

The example value is set to 1800. The particular timeout value highly depends on a specific system. To set the plugin’s timeout appropriately, you can first estimate the time needed to collect the one plugin with no timeout by running the following command:

# time sos report -o processor -k processor.timeout=0 --batch --build

Jira:RHELPLAN-51452^[1]

Running systemd within an older container image, for example, centos:7, does not work:

$ podman run --rm -ti centos:7 /usr/lib/systemd/systemd
 Storing signatures
 Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
 [!!!!!!] Failed to mount API filesystems, freezing.

Workaround: Use the following commands:

# mkdir /sys/fs/cgroup/systemd
# mount none -t cgroup -o none,name=systemd /sys/fs/cgroup/systemd
# podman run --runtime /usr/bin/crun --annotation=run.oci.systemd.force_cgroup_v1=/sys/fs/cgroup --rm -ti centos:7 /usr/lib/systemd/systemd

Jira:RHELPLAN-96940^[1]