Chapter 10. Known issues
This version of Red Hat Enterprise Linux 10.0 is affected by the following newly identified and previously known issues. A known issue is listed in all future release notes until resolved, at which point it is published as a fixed issue. If you encountered an issue that is not listed in this section, please report it by using the button in the top right corner of this page.
10.1. Installer and image creation
Unable to build ISOs from a signed container
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
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
$ 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.
Hostname resolution fails with encrypted DNS and custom CA in boot options
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 installer 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.
Installer becomes unresponsive during final RPM installation stage
An installer may become unresponsive during the RPM installation process at the final stage. Before the issue occurs, you may see the repeated Configuring rootfiles.noarch
messages. Workaround: Restart the installation process.
Jira:RHEL-67865[1]
Disabled keyboard layout switching by using shortcut during installation
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.
Bonding device with LACP takes longer to become operational, causing subscription failures
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 via 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]
The services
Kickstart command fails to disable the firewalld
service
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.
Installation program fails if /boot
partition is not created when using ostreecontainer
When using the ostreecontainer
Kickstart command to install a bootable container, the installation fails if the /boot
partition is not created. This issue occurs because the installation program requires a dedicated /boot
partition to proceed with the container deployment.
Workaround: Ensure that a /boot
partition is defined in the Kickstart file or manually created during the installation process.
Kickstart installation fails with an unknown disk error when 'ignoredisk' command precedes 'iscsi' command
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.
The USB CD-ROM drive is not available as an installation source in Anaconda
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.
Driver disk menu fails to display user inputs on the console
When you start RHEL installation using the inst.dd
option on the kernel command line with a driver disk, the console fails to display the user input. Consequently, it appears that the application does not respond to the user input and stops responding, but displays the output which is confusing for users. However, this behavior does not affect the functionality, and user input gets registered after pressing Enter
.
Workaround: To see the expected results, ignore the absence of user inputs in the console and press Enter
when you finish adding inputs.
Anaconda may not work correctly on s390x
and ppc64le
architectures
Image mode for RHEL supports pp64le
and s390x
architectures besides the already supported x86_64
and ARM architectures. However, Anaconda may not function correctly on s390x and ppc64le architectures.
Jira:RHELDOCS-19496[1]
Anaconda installer appears as unresponsive in the rescue mode
When booting into a rescue mode and selecting the Continue
or Skip to shell
options, you might experience an issue where the Anaconda installer appears to be frozen. Despite the lack of visible response, the installer is still functional and reacting to your inputs; however, the prompt does not display on the screen, leading to confusion.
Continue with your tasks as normal, as the installer is still operational despite the absence of a visible prompt.
Jira:RHEL-58834[1]
10.2. Security
SELinux policy rules for four libvirt
services temporarily changed into permissive mode
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 a lot of scenarios, the following services have been temporarily changed into SELinux permissive mode:
-
virtqemud
-
virtvboxd
-
virtstoraged
-
virtsecretd
To prevent harmless AVC denials, dontaudit
rules have been added to the SELinux policy for these services.
Jira:RHEL-77808[1]
Cryptographic tokens do not work in FIPS mode with pkcs11-provider
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.
Workaround: 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.
10.3. Shells and command-line tools
pass:uname
command produces an unknown output
The uname command displays unknown output with flags pass:--hardware-platform
and pass:--processor
. In the previous RHEL versions, pass:uname -i
and pass:uname -p
were aliases for pass:uname -m
and are not portable even across GNU/Linux distributions.
As a workaround, you can use the pass:-m
flag instead of the pass:-i
and pass:-p
flags.
10.4. Infrastructure services
Nginx does not support PKCS #11 and TPM
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.
Using the incorrect Perl database driver for MariaDB and MySQL can lead to unexpected results
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:
-
The Perl
DBD::MariaDB
driver with a MariaDB database -
The Perl
DBD::mysql
driver with a MySQL database
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]
VMware vCenter cannot correctly remove a SATA disk from a running RHEL VM
When using the VMWare vCenter interface to remove a SATA disk from a running RHEL 10 guest on the VMware ESXi hypervisor, the disk currently does not get removed fully. It stops being functional and disappears from the guest in the vCenter inteface, but the SCSI interface still detects the disk as attached in the guest.
Jira:RHEL-79913[1]
10.5. Networking
The wpa_supplicant
service no longer relies on the OpenSSL Engine API
In RHEL 10, engines are not compatible according to Federal Information Processing Standards (FIPS) therefore the corresponding OpenSSL Engine API has been removed. Consequently, the dependent wpa_supplicant
service cannot load X509 certificates and keys that are stored in PKCS11 URI format. As a result, any EAP-TLS authentication method and variants using PKCS11 will not be able to connect to the relevant network anymore.
The kernel can panic if you reduce the number of SR-IOV VFs at runtime
If all of the following conditions apply, the Linux kernel can panic:
- The host has Input-Output Memory Management Unit (IOMMU) enabled.
- A network driver uses a page pool.
- You reduce the number of Single Root I/O Virtualization (SR-IOV) Virtual Functions (VFs) of the network interface that uses this driver.
Workaround: Do not reduce the number of VFs at runtime. Reboot the machine to reset the number of VFs of all interfaces to 0. Afterwards, you can set a new number of VFs because increasing the number does not cause the kernel panic.
Jira:RHEL-68401[1]
10.6. Kernel
crashkernel
boot parameter does not load in rhel-guest-image
Presently, RHEL cloud image built by osbuild
misses the crashkernel
kernel parameter. As a result, kdump.service
fails to start.
Workaround: Run kdumpctl
manually to set up the crashkernel
kernel parameter and reboot the system. kdump.service
will start successfully.
Jira:RHEL-63071[1]
The kdump service fails during boot
After the installation of registry.redhat.io/rhel9/rhel-bootc
container image to a physical system, the kdump.service
fails.
Workaround: Ensure the PrivateTmp
service is disabled:
cat /etc/systemd/system/kdump.service.d/override.conf [Service] PrivateTmp=no
# cat /etc/systemd/system/kdump.service.d/override.conf
[Service]
PrivateTmp=no
Then rebuild and restart the kdump service:
touch /etc/kdump.conf systemctl restart kdump
# touch /etc/kdump.conf
# systemctl restart kdump
10.7. File systems and storage
Reverse Mapping B+Tree (rmapbt
) performance impact
By default, the XFS file system enables the rmapbt
feature, which has potential performance regressions in write-heavy workloads with small block sizes. Evaluate performance-sensitive applications carefully, particularly those that heavily rely on writing small data blocks.
Workaround: To disable the rmapbt
feature during file system creation, use the -m rmapbt=0
option. This will revert the default behavior.
Jira:RHEL-33653[1]
Inconsistent NVMe device names after reboot
A new kernel feature that enables asynchronous NVMe namespace scans is introduced in RHEL 10, to accelerate NVMe disk detection. As a consequence of the asynchronous scans, the /dev/nvmeXnY
device files might point to different namespaces after each reboot. This can lead to inconsistent device names. At this time, there is no known workaround for this issue.
Jira:RHEL-85845[1]
10.8. High availability and clusters
ACL roles should not reference location constraints with two rules
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.
10.9. Compilers and development tools
The new version of TBB is incompatible
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.
10.10. Identity Management
IdM in FIPS mode does not support using the NTLMSSP protocol to establish a two-way cross-forest trust
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]
Installing a RHEL 7 IdM client with a RHEL 10 IdM server in FIPS mode fails due to EMS enforcement
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]
DNSSEC not working correctly in RHEL IdM
The DNS Security Extensions (DNSSEC) do not function correctly in Identity Management (IdM) in RHEL 10.0 because of multiple unresolved issues stemming from the replacement of the openssl-pkcs11
OpenSSL engine with the pkcs11-provider
OpenSSL provider.
The changes introduced by OpenSSL have impacted the integrated DNS functionality within RHEL IdM. Specifically, the changes are affecting multiple components in IdM, including ipa
, bind
, bind-dyndb-ldap
, softhsm
, and python-cryptography
, and how these components interact with security modules.
Automatic host keytab renewal via adcli
run by SSSD is failing
In direct SSSD-AD integration, SSSD checks daily if the machine account password is older than the configured age in days and, if needed, tries to renew it. The configured age is set by the ad_maximum_machine_account_password_age
value, with a default of 30
days. A value of 0
disables the renewal attempt.
However, currently there is an issue and the automatic renewal of the machine account password fails. If the password expires, this may result in the host losing access to the AD domain.
Workaround: Renew the password manually or via another means. Do not rely on the SSSD automatic renewal.
Jira:RHELDOCS-19172[1]
dsctl healthcheck
can report a wrong database type
If you created an instance with the Lightning Memory-Mapped Database Manager (LMDB) database type, running the dsctl healthcheck
command can result in one of the following error messages, because Directory Server checks a wrong configuration parameter:
-
DSBLE0005
. Backend configuration attributes mismatch. -
DSBLE0006
. BDB is still used as a backend.
Workaround: Set the NSSLAPD_DB_LIB
environment variable to mdb
before running dsctl healthcheck
.
Jira:RHELDOCS-19014[1]
An error message is displayed during migration from BDB to LMDB
When you run the dsctl dblib bdb2mdb
command to migrate from Berkeley Database (BDB) to Lightning Memory-Mapped Database Manager (LMDB) and you have not enabled the replication, the following error message is displayed in the output:
Error: 97 - 1 - 53 - Server is unwilling to perform - [] - Unauthenticated binds are not allowed
Error: 97 - 1 - 53 - Server is unwilling to perform - [] - Unauthenticated binds are not allowed
Note that you can ignore the error message. The error occurs because Directory Server attempts to find the replication_changelog.db
file that is not mandatory when the replication is disabled. This error does not prevent the migration from BDB to LMDB.
There is currently no workaround for this issue.
Jira:RHELDOCS-19016[1]
ldapmodify
does not delete a single specific value from any attribute in cn=config
Currently, when you try to delete a value from any attribute in cn=config
, the value remains in the attribute and the server may 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>
# dsconf <instance_name> config delete <attribute_name>=<undesired_value>
10.11. SSSD
SSSD retrieves incomplete list of members if the group size exceeds 1500 members
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]
10.12. Desktop
Standard mouse cursor is offset in VMs when using Mutter
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.
10.13. Graphics infrastructures
Standard mouse cursor is offset in VMs when using Mutter
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.
10.14. The web console
VNC console in the RHEL web console does not work correctly on ARM64
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]
10.15. Red Hat Enterprise Linux System Roles
ansible-core
does not install sshpass
as a dependency
The ansible-core
package does not install the sshpass
package as a dependency. Consequently, you can not 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]
10.16. Virtualization
Installing the VirtIO-Win bundle cannot be canceled
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 abort 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
Secure Execution VMs cannot boot with file-backed memory backing
If you configure a virtual machines (VMs) with enabled Secure Execution to use file-backed memory backing, the VM currently fails to boot, and instead displays a Protected boot has failed
error.
Workaround: Edit the /etc/libvirt/qemu.conf
file and set the memory_backing_dir
line to the following value:
memory_backing_dir = "/dev/shm/"
memory_backing_dir = "/dev/shm/"
Afterwards, the affected VMs can boot as expected.
VMs sending discard I/O requests might pause when discard_granularity
is not configured
The host kernel fails misaligned discard I/O requests and QEMU uses the werror= policy
parameter to respond to such failures. When werror
is set to stop
: werror=stop
, a failed discard request causes the virtual machine (VM) to pause. This is usually undesirable because there is no way to correct this situation and resume the VM again.
Workaround: Ensure that the discard_granularity
parameter on virtio-blk
and virtio-scsi
disks is set and matches the host’s /sys/block/<blkdev>/queue/discard_granularity
value. This makes the VM aware of the alignment constraints and ensures discard requests will be properly aligned, so they do not fail.
Jira:RHEL-87642[1]
The --migrate-disks-detect-zeroes
option might not work for VM migration
Currently, when migrating virtual machines (VMs) on RHEL 10, the --migrate-disks-detect-zeroes
option might not work and the migration might proceed without zeroed block detection on the specified disk. This problem is caused by a bug in QEMU where mirroring jobs had been relying on punching holes, which results in a sparse destination file.
A virtual machine with a large amount of bootable data disks might fail to start
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>
<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.
Too many open files in a virtiofs
shared directory can crash the vrtiofsd
process
When accessing a virtiofs
shared directory with a large amount of open files from a virtual machine (VM), the operation might fail with the following error: Too many open files
and the virtiofsd
process might crash.
Workaround: Try any of the following steps:
-
Run
virtiofsd
as root and use the--inode-file-handles=mandatory
command-line option. -
Use the
--cache=never
command-line option. -
Increase the number of file descriptors
virtiofsd
is permitted to use with the--rlimit-nofile
command-line option.
Jira:RHEL-87161[1]
VMs with large memory cannot boot on SEV-SNP host with AMD Genoa CPUs
Currently, virtual machines (VMs) cannot boot on hosts that use a 4th Generation AMD EPYC processor (also known as Genoa) and have the AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) feature enabled. Instead of booting, a kernel panic occurs in the VM.
Jira:RHEL-32892[1]
The virtio balloon driver sometimes does not work on Windows 10 and Windows 11 VMs
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.
Windows 11 VMs with a memory balloon device set might close unexpectedly during reboot
Currently, rebooting virtual machines (VMs) that use a Windows 11 guest operating system and a memory balloon device in some cases fails with a DRIVER POWER STAT FAILURE
blue-screen error.
Jira:RHEL-935[1]
Windows VM with VBS and IOMMU device fails to boot
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>
<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]
Windows VM running on Sapphire Rapids CPU with hypervisor launch type set to auto
might fail to boot when restarted
If you set the hypervisor launch type to auto
in a Windows virtual machine (VM) running on a Sapphire Rapids CPU, the VM might fail to boot when it is restarted. For example, you can set the hypervisor launch type to auto
by using the bcdedit /set hypervisorlaunchtype Auto
command.
Workaround: Do not set the hypervisor launch type to auto
in the Windows VM.
Hot-plugging vCPUs and memory to Windows guests with VBS does not work
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
10.17. RHEL in cloud environments
RDMA devices currently do not work on vSphere
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]
The leapp upgrade fails when upgrading from RHEL 9.6 to RHEL 10.0 for the cloud-init network configuration
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:
Modify the connection:
nmcli connection modify "System <enp1s0>" connection.id "cloud-init <enp1s0>"
# nmcli connection modify "System <enp1s0>" connection.id "cloud-init <enp1s0>"
Copy to Clipboard Copied! Migrate the connection:
nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-<enp1s0>
# nmcli connection migrate /etc/sysconfig/network-scripts/ifcfg-<enp1s0>
Copy to Clipboard Copied! Move the connection profile:
sudo mv /etc/NetworkManager/system-connections/"cloud-init <enp1s0>.nmconnection" /etc/NetworkManager/system-connections/cloud-init-<enp1s0>.nmconnection
# sudo mv /etc/NetworkManager/system-connections/"cloud-init <enp1s0>.nmconnection" /etc/NetworkManager/system-connections/cloud-init-<enp1s0>.nmconnection
Copy to Clipboard Copied! Reload the network connection settings:
nmcli conn reload
# nmcli conn reload
Copy to Clipboard Copied!
As a result, the leapp upgrade from RHEL 9.6 to RHEL 10.0 now works with the updated configuration.
Jira:RHEL-82209[1]
Upgrading a RHEL 9.6 guest on VMware ESXi to RHEL 10.0 causes cloud-init
to rewrite the network configuration
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]
Nested VM with KVM virtualization and OVMF fails to boot on Azure or Hyper-V when using AMD EPYC processor
A nested VM with Open Virtual Machine Firmware (OVMF) fails to boot when run on a RHEL VM with KVM virtualization enabled in the Azure cloud or Hyper-V using the AMD EPYC processor. The VM fails to boot up with following log message:
Code=qemu-kvm: ../hw/core/cpu-sysemu.c:76 Aborted (core dumped) .
Code=qemu-kvm: ../hw/core/cpu-sysemu.c:76 Aborted (core dumped) .
Workaround: Try booting without using the AMD EPYC processor.
Jira:RHEL-29919[1]
BIOS or UEFI supported Hyper-V Windows Server 2016 VM fails to boot if a host uses the AMD EPYC CPU processor
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.
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]
10.18. Containers
Podman and bootc do not share the same registry login process
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>
# 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
# 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
Queued for next boot: registry.redhat.io/rhel9/rhel-bootc:9.4
However, an error appears:
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
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]
cloud-init
growpart skips with composefs is enabled
When composefs is enabled, if you generate an image from the generic base image, then the rootfs will note 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'
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.
FIPS bootc image creation fails on FIPS enabled host
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
# 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.
Insufficient disk space can cause deployment failure
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]
RHEL images on Azure marked as LVM require default layout resizing
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]
10.19. Lightspeed
Configuration file changes are not applied immediately
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:
-
Make the changes that you need to the
config.toml
configuration file. - Run the following command:
systemctl restart clad
# systemctl restart clad
Jira:RHELDOCS-19734[1]
10.20. Known issues identified in previous releases
This part describes known issues in Red Hat Enterprise Linux 10.0.
10.20.1. Networking
Failure to update the session key causes the connection to break
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]
kTLS does not support offloading of TLS 1.3 to NICs
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]