Chapter 12. Known issues


This version of Red Hat Enterprise Linux 10.0 Beta 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.

12.1. Installer and image creation

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]

Unable to register RHEL-10 beta systems with Red Hat Satellite

Currently, Red Hat Satellite does not support RHEL-10 clients. As a result, attempting to register your system to a Satellite instance during the RHEL-10 beta installation fails. As a consequence, your system remains unregistered to Satellite after installation, which might impact further system management through Satellite. At the moment, there is no workaround.

Jira:RHELDOCS-18815[1]

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

This happens because the system fails to get the image source signatures. To work around this issue, 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-beta/rhel-bootc:9.4 containers-storage:registry.redhat.io/rhel9-beta/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-beta/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

12.2. Subscription management

The Red Hat Insights remediations service is not available to execute playbooks in RHEL 10-beta for directly connected systems

Due to a missing RPM package (rhc-worker-playbook), the remediations service cannot execute playbooks in RHEL 10-beta for systems that are directly connected with the remote host configuration (rhc) client.

There is currently no workaround for this known issue in RHEL 10-beta.

Jira:RHELDOCS-18991

12.3. 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.

Jira:RHEL-33742

12.4. 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.

To work around this issue, 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.

To work around this problem, ensure the PrivateTmp service is disabled:

# 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

Jira:RHEL-50736

12.5. 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.

Jira:RHEL-33633

12.6. Identity Management

The IdM server functions only partially or not at all

In this release, changes introduced by OpenSSL have impacted the integrated DNS functionality within Identity Management (IdM). Most notably, the OpenSSL PKCS #11 engine is replaced by a new pkcs11-provider. This shift affects multiple components in IdM, including ipa, bind, bind-dyndb-ldap, softhsm, and python-cryptography.

The transition from the openssl-pkcs11 engine to the pkcs11-provider changes the way these components interact with security modules. As a result, all IdM components relying on the previous OpenSSL engine require updates to remain compatible with the new pkcs11-provider.

To support the new pkcs11-provider, a migration to Bind 9.20 is necessary. Bind 9.20 is the first version that provides compatibility with the pkcs11-provider, but it also introduces substantial architectural changes. These changes require a major rewrite of the bind-dyndb-ldap plugin to ensure that it continues functioning properly with the updated Bind and OpenSSL configurations.

Consequently, the IdM server functions only partially or not at all in RHEL 10-Beta. Specifically, you cannot install the ipa-server-dns package, and the embedded DNS server cannot be configured using the --setup-dns option. Until the necessary updates to bind-dyndb-ldap and other impacted components are completed, the integrated DNS feature remains unavailable.

Jira:RHEL-30556

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]

Migrating an IdM deployment may result in duplicate HBAC rules

Migrating from one Identity Management (IdM) deployment to another by using the ipa-migrate utility may lead to duplicate host-based access control (HBAC) rules on the destination server. Consequently, the allow_all and allow_systemd-user HBAC rules appear twice when running the ipa hbacrule-find command on that server.

To work around the problem:

  1. Identify the distinguished name of the duplicate HBAC rule by using the ipa hbacrule-find --all --raw command.
  2. Delete the duplicate rule by using the ldapdelete command.

Jira:RHEL-59265[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.

To work around the problem, upgrade the host to RHEL 8 or later before installing an IdM client on it.

Jira:RHELDOCS-19015[1]

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 on 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.

To work around this issue, 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

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]

Installing an IdM replica fails in FIPS mode

In RHEL 10-beta, the installation of an Identity Management (IdM) replica fails in FIPS mode. The installation fails when the import of the Registration Authority (RA) key is attempted.

Jira:RHEL-58067[1]

12.7. 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]

12.8. Virtualization

Using SEV-SNP is not possible

Currently, when attempting to start an AMD SEV-SNP enabled virtual machine (VM), QEMU checks the incorrect capability of KVM, and the guest fails to start. As a consequence, running VMs with AMD SEV-SNP configured is not possible with RHEL10 Beta. There is no workaround for the issue.

Jira:RHEL-58928[1]

IP address is not assigned to ARM64 Azure VMs at boot time

When you boot a RHEL-10.0-Beta VM with the ARM64 CPU on Microsoft Azure, no IP address is assigned to the VM. Consequently, you cannot access the VM through the network. As a workaround, follow the steps below to edit a NetworkManager.conf file:

# mkdir -p /etc/NetworkManager/conf.d
# cat > /etc/NetworkManager/conf.d/99-azure-unmanaged-devices.conf << EOF
# Ignore SR-IOV interface on Azure, since it's transparently bonded to the synthetic interface
[keyfile]
unmanaged-devices=driver:mlx4_core;driver:mlx5_core
EOF

After adding this configuration, if you enable single root I/O virtualization (SR-IOV), you can use Mellanox Virtual Function Network Interface Controller (VF NIC) to assign an IP to the VM.

Jira:RHEL-40417[1]

IP address assigned to VF NIC makes VMs inaccessible from external networks

When you boot a RHEL-10.0 beta VM with Microsoft Azure Network Adapter (MANA) on Microsoft Azure, an IP address gets assigned to the Virtual Function Network Interface Controller (VF NIC). As a consequence, the VM becomes inaccessible through the external network. As a workaround, add driver:mana to the /etc/NetworkManager/conf.d/99-azure-unmanaged-devices.conf file:

[keyfile]
unmanaged-devices=driver:mlx4_core;driver:mlx5_core;driver:mana

Jira:RHEL-50544[1]

12.9. RHEL in cloud environments

RHEL 10 Beta guests in some cases terminate unexpectedly on GCP and Alibaba

When using a RHEL 10 Beta instance on Google Cloud Platform or the Alibaba Cloud, restarting the instance currently causes a kernel panic in the guest operating system if the virtio-net driver is in use. There is no known workaround.

Jira:RHEL-56981[1]

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]

12.10. 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>

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

To work around this issue, 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'

As a 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

12.11. Known issues identified in previous releases

This part describes known issues in Red Hat Enterprise Linux 10.0 Beta.

12.11.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. To work around this problem, disable kTLS. As a result, with the workaround, it is possible to successfully update the session key.

Bugzilla:2013650[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. To work around this problem, 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.

Bugzilla:2000616[1]

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.