Chapter 11. Known issues

By default, crash dumps do not occur for default installation methods using RHEL Image Mode, because the crashkernel= kernel argument is not set. To work around this problem, set a crashkernel= kernel argument at build or during installation time.

Jira:RHEL-82380

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 sq utility from the Sequoia PGP toolset uses the deprecated OpenSSL API for key generation. Consequently, you cannot generate keys with sq on the system running in FIPS mode.

Jira:RHEL-85985

GnuTLS lacks an algorithm to convert a private ML-DSA key in the expanded form to a public ML-DSA key. Consequently, operations requiring both keys fail when only the expanded private key is provided.

Workaround: Use the openssl command to convert such a private key to a public key: openssl dsa -in <private_key> -pubout -out <public_key>. As a result, the public key is available for use in other operations.

Jira:RHEL-102992

In RHEL 10.1, the rpm-sequoia 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 hard-coded on the crypto-policies level. As a result, PQ algorithms for rpm-sequoia are enabled regardless of any settings in crypto-policies.

Jira:RHEL-112392

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-114861^[1]

During installation, a logical volume spanning a local disk and an iSCSI device can fail to activate the iSCSI device in the installed system. This occurs where a non-root filesystem LVM logical volume is located both on a local disk and on an iSCSI device, which results in the iSCSI device not getting configured with node.startup=onboot by the installation program. As a result, the system cannot access the volume after reboot, because it doesn’t get automatically activated upon boot.

Workaround: Manually create the logical volume after the installation or update the iSCSI node configuration by setting node.startup=automatic in the relevant file in the /var/lib/iscsi/nodes/ directory.

Jira:RHEL-53719

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

Jira:RHELDOCS-21374^[1]

Plymouth, an application which provides a graphical boot experience for Red Hat Enterprise Linux, has a "console syndication" feature that outputs log messages to all configured consoles during boot. The kernel can natively output log messages only to the last configured console. In the default configuration, the kernel is muted, but removing the quiet argument from the kernel command line unmutes the kernel, and causes both Plymouth and the kernel to send the boot log messages to the last-configured console. As a result, log messages might be duplicated on the last-configured console (for example ttyS0). Plymouth further duplicates these log entries by replaying the entire contents of the kernel log ring buffer during boot and shutdown. To work around this problem, disable Plymouth.

Jira:RHEL-60198^[1]

RHEL 10.1 uses the Red Hat RPM signing key extended with a post-quantum public key and stored in the /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release file in the OpenPGP v6 format. Because the Ansible rpm_key modules use the GnuPG tools, which cannot handle post-quantum keys and OpenPGP v6, the modules fail to work with this key.

Jira:RHEL-126844

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]

Virtual machines (VMs) with SEV-SNP enabled fail to boot when using the arch-capabilities=on CPU flag.

To work around this problem, disable the arch-capabilities feature in the CPU section of the VM’s configuration:

<cpu mode='host-passthrough' check='none'>
  <feature name='arch-capabilities' policy='disable'/>
</cpu>

Jira:RHEL-100313^[1]

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]

Do not use unsupported models. Changing the RHEL Offline Container model to unsupported models might allow the execution of arbitrary code or compromise the integrity of Red Hat Enterprise Linux (RHEL).

No known workaround exists.

Jira:RHELDOCS-21726^[1]

Podman and bootc use different registry login processes when pulling images. As a consequence, if you login to an image by using Podman, logging to a registry for bootc will not work on that image. When you install an image mode for RHEL system, and login to registry.redhat.io by using the following command:

# podman login registry.redhat.io <username_password>

And then you attempt to switch to the registry.redhat.io/rhel9/rhel-bootc image with the following command:

# bootc switch registry.redhat.io/rhel9/rhel-bootc:9.4

You should be able to see the following message:

Queued for next boot: registry.redhat.io/rhel9/rhel-bootc:9.4

However, an error is displayed:

ERROR Switching: Pulling: Creating importer: Failed to invoke skopeo proxy method OpenImage: remote error: unable to retrieve auth token: invalid username/password: unauthorized: Please login to the Red Hat Registry using your Customer Portal credentials. Further instructions can be found here: https://access.redhat.com/RegistryAuthentication

Workaround: Follow the steps Configuring container pull secrets to use authenticated registries with bootc.

Jira:RHELDOCS-18471^[1]

When composefs is enabled, if you generate an image from the generic base image, then the rootfs will not grow the filesystem, prompting an error similar to:

2024-04-30 17:27:53,543 - cc_growpart.py[DEBUG]: '/' SKIPPED: stat of 'overlay' failed: [Errno 2] No such file or directory: 'overlay'

Workaround: You can add a custom growpart, by specifying the rootfs default size in the container, instead of dynamically choosing 100G at instance creation time to be able to write a partitioning config in the container.

Jira:RHEL-34859

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

An installation program might become unresponsive during the RPM installation process at the final stage. Before the issue occurs, you might see the repeated Configuring rootfiles.noarch messages. Workaround: Restart the installation process.

Jira:RHEL-67865^[1]

To prevent confusion caused by a broken keyboard shortcut to change keyboard layout, this feature has been disabled in Anaconda. You cannot change keyboard layouts by using shortcuts during installation. Workaround: Use the keyboard layout icon on the top bar to switch layouts.

Jira:RHEL-74504

Previously, the RHEL installation program ignored the BOOTIF=<MAC> boot argument and activated all the available network interfaces. With this fix, the installation program now properly processes the BOOTIF argument and ensures that only the designated network device is activated during the installation process.

Jira:RHEL-69400^[1]

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-19853^[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-83577

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-58829

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]

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]

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

Previously, the SELinux policy was changed to reflect the replacement of the legacy monolithic libvirtd daemon with a new set of modular daemons. Because this change requires testing of many scenarios, the following services have been temporarily changed into SELinux permissive mode:

To prevent harmless AVC denials, dontaudit rules have been added to the SELinux policy for these services.

Jira:RHEL-77808^[1]

When the system runs in FIPS mode, the pkcs11-provider OpenSSL provider does not work correctly and the OpenSSL TLS toolkit falls back to the default provider. Consequently, OpenSSL fails to load PKCS #11 keys, and cryptographic tokens do not work in this scenario.

To work around this problem, set the pkcs11-module-assume-fips = true parameter in the PKCS #11 section of the openssl.cnf file. See the pkcs11-provider(7) man page on your system for more information. With this configuration change, pkcs11-provider works in FIPS mode.

Jira:RHEL-68621

In RHEL 10.0, the open quantum-safe provider for OpenSSL (oqsprovider) generated private keys in a format that did not conform to any of the file formats proposed by the IETF LAMPS work group. Consequently, the key files were unreadable by other applications that follow the IETF standard and could not be handled by applications that require providing the key in the seed format for import. With this update, OpenSSL no longer uses oqsprovider and its post-quantum cryptography (PQC) implementation generates the keys in standard formats. As a result, you can use OpenSSL ML-KEM and ML-DSA keys for storing long-term secrets.

Jira:RHEL-72719

The uname command displays unknown output with flags --hardware-platform and --processor. In the previous RHEL versions, uname -i and uname -p were aliases for uname -m and are not portable even across GNU or Linux distributions.

As a workaround, you can use the -m flag instead of the -i and -p flags.

Jira:RHEL-74146

The OpenSSL engines API was deprecated in RHEL 9 and removed from Nginx in RHEL 10. The corresponding functionality using the current OpenSSL providers API is not yet available. As a consequence, the Nginx HTTP server does not work with hardware security modules (HSMs) through PKCS #11 and Trusted Platform Module (TPM) devices.

Jira:RHEL-33742

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-19770^[1]

When using the VMware vCenter interface to remove a SATA disk from a running RHEL 10 guest on the VMware ESXi hypervisor, the disk previously did not get removed fully. It stopped being functional and disappeared from the guest in the vCenter interface, but the SCSI interface still detected the disk as attached in the guest. This update fixes the issue, and the SATA disk is fully removed in the described scenario.

Jira:RHEL-79913^[1]

In Red Hat Enterprise Linux 10, more than one top-level rule in a location constraint is not supported. When upgrading from RHEL 9 to RHEL 10, verify that any ACL roles you have configured do not reference a location constraint with two rules and are still valid.

Jira:RHEL-62722

RHEL 10 includes the Threading Building Blocks (TBB) library version 2021.11.0, which is incompatible with the versions distributed with previous releases of RHEL. You must rebuild applications that use TBB to make them run on RHEL 10.

Jira:RHEL-33633

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]

The TLS Extended Master Secret (EMS) extension (RFC 7627) is now mandatory for TLS 1.2 connections on FIPS-enabled RHEL 10 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 10 fails.

Workaround: Upgrade the host to RHEL 8 or later before installing an IdM client on it.

Jira:RHELDOCS-19015^[1]

Currently, when you try to delete a value from any attribute in cn=config, the value remains in the attribute and the server might require a restart to fully remove it.

Workaround: Remove the entire attribute, including all its values, by performing a modify operation without specifying any values. Then re-add the values you need. Alternatively, use the following dsconf command to remove a specific value without a server restart:

# dsconf <instance_name> config delete <attribute_name>=<undesired_value>

Jira:RHEL-25071

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 you use a standard mouse within a virtual machine (VM) configuration in the Mutter compositing window manager, you might notice an offset between the physical mouse cursor and the actual pointer within the virtual environment. The actual pointer might not even be visible in the virtual environment.

Workaround: If your scenario requires precise input, use a tablet as an input device in the VM configuration.

Jira:RHEL-69291

When you use a standard mouse within a virtual machine (VM) configuration in the Mutter compositing window manager, you might notice an offset between the physical mouse cursor and the actual pointer within the virtual environment. The actual pointer might not even be visible in the virtual environment.

Workaround: If your scenario requires precise input, use a tablet as an input device in the VM configuration.

Jira:RHEL-45898

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]

The ansible-core package does not install the sshpass package as a dependency. Consequently, you cannot use Ansible to manage systems over SSH with an SSH password.

Workaround: On the control node, manually install sshpass after you install ansible-core. As a result, you can use Ansible in the scenario described above.

Jira:RHEL-86829^[1]

Previously, when attempting to start a virtual machine (VM) with AMD SEV-SNP enabled, QEMU checked the incorrect capability of KVM, and the guest failed to start. As a consequence, running VMs with AMD SEV-SNP configured was not possible with RHEL10. This problem has been fixed, and running VMs with SEV-SNP works as expected now.

Jira:RHEL-58928^[1]

Previously, when a virtual machine (VM) did not have an RNG device configured and its CPU model did not support the RDRAND feature, it was not possible to boot the VM from the network. With this update, the problem has been fixed, and VMs that do not support RDRAND can boot from the network even without an RNG device configured.

Note, however, that adding an RNG device is highly encouraged for VMs that use a CPU model that does not support RDRAND, in order to increase security when booting from the network.

Jira:RHEL-66234

When using a RHEL 10.0 instance on Google Cloud or the Alibaba Cloud, restarting the instance previously caused a kernel panic in the guest operating system if the virtio-net driver was in use. This issue has been fixed and RHEL 10 guests no longer crash in the described scenario.

Jira:RHEL-56981^[1]

Previously, if you configured a virtual machine (VM) with enabled Secure Execution to use file-backed memory backing, the VM failed to boot, and instead displayed a Protected boot has failed error. Now, the VM boots as expected.

Jira:RHEL-58218

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

Previously, virtual machines (VMs) could not boot on hosts that used a 4th Generation AMD EPYC processor (also known as Genoa) and had the AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) feature enabled. Instead of booting, a kernel panic occurred in the VM. This issue has now been fixed.

Jira:RHEL-32892^[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

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]

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

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-82685

Prior to this update, if you selected the Enable 3D support option in VMware ESXI for installing a RHEL 10 guest operating system, the installation did not start correctly, and instead showed a blank screen. This issue has been fixed, and you can now install RHEL 10 guests in the described scenario.

Jira:RHEL-88668^[1]

When using a RHEL 10 instance on the VMware vSphere platform, the vmw_pvrdma module currently does not install properly. As a consequence, VMware paravirtual remote direct memory access (PVRDMA) devices do not work on the affected instances.

Jira:RHEL-41133^[1]

If you deploy RHEL 9.6 with the cloud-init default configuration and with sysconfig as the default network configuration directory, the sysconfig configuration files do not support the ifcfg legacy format for RHEL 10.0. Consequently, the leapp upgrade fails when upgrading from RHEL 9.6 to RHEL 10.0 for the legacy network configuration files, such as ifcfg-<enp1s0>.

Workaround: Convert the sysconfig configuration files into the NetworkManager native keyfile format:

As a result, the leapp upgrade from RHEL 9.6 to RHEL 10.0 now works with the updated configuration.

Jira:RHEL-82209^[1]

After a upgrading a RHEL guest on the VMware ESXi hypervisor from RHEL 9.6 to RHEL 10.0, the cloud-init tool currently cannot detect the VMware data source and cannot restore its configuration from the cache. As a consequence, cloud-init reverts to the None data source, and rewrites the network configuration of the guest.

Workaround: Remove the disable_vmware_customization flag from the /etc/cloud/cloud.cfg file before you reboot the guest during the upgrade process. As a result, the upgraded guest will retain its previous network configuration.

Jira:RHEL-82210^[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]

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]

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:RHELDOCS-20686^[1]

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:RHELDOCS-20687^[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]