Chapter 5. Bug fixes

This part describes bugs fixed in Red Hat Enterprise Linux 8.5 Beta that have a significant impact on users.

5.1. Installer and image creation

RHEL-Edge container image now uses nginx and serves on port 8080

Previously, the edge-container image type was unable to run in non-root mode. As a result, Red Hat OpenShift 4 was unable to use the edge-container image type. With this enhancement, the container now uses nginx HTTP server to serve the commit and a configuration file that allows the server to run as a non-root user inside the container, enabling its use on Red Hat OpenShift 4. The internal web server now uses the port 8080 instead of 80.


RHEL installation no longer aborts when Insights client fails to register system

Previously, the RHEL installation failed with an error at the end if the Red Hat Insights client failed to register the system during the installation. With this update, the system completes the installation even if the insights client fails. The user is notified about the error during installation so the error can be handled later independently.


5.2. Shells and command-line tools

opal-prd rebased to version 6.7.1

opal-prd has been upgraded to version 6.7.1. Notable bug fixes and enhancements include:

  • Fixed xscom error logging issues caused due to xscom OPAL call.
  • Fixed possible deadlock with the DEBUG build.
  • Fallback to full_reboot if fast-reboot fails in core/platform.
  • Fixed next_ungarded_primary in core/cpu.
  • Improved rate limit timer requests and the timer state in Self-Boot Engine (SBE).


libservicelog rebased to version 1.1.19

libservicelog has been upgraded to version 1.1.19. Notable bug fixes and enhancements include:

  • Fixed output alignment issue.
  • Fixed segfault on servicelog_open() failure.


ipmitool sol activate command no longer crashes

Previously, after upgrading from RHEL 7 to RHEL 8 the ipmitool sol activate command would crash while trying to access the remote console on an IBM DataPower appliance.

With this update, the bug has been fixed and one can use ipmitool to access the remote console again.


Relax-and-Recover (ReaR) package now depends on the bootlist executable

Previously, ReaR could produce a rescue image without the bootlist executable on the IBM Power Systems, Little Endian architecture. Consequently, if the powerpc-utils-core package is not installed, the rescue image did not contain the bootlist executable.

With this update, the ReaR package now depends on the bootlist executable. The dependency ensures that the bootlist executable is present. ReaR does not create a rescue image if the bootlist executable is missing. This avoids creating an invalid rescue image.


rsync with an unprivileged remote user can now be used in ReaR

Previously, when rsync was used to back up and restore the system data (BACKUP=RSYNC), the parameters to rsync were incorrectly quoted, and the --fake-super parameter was not passed to the remote rsync process. Consequently, the file metadata was not correctly saved and restored.

With this update following bugs have been fixed:

  • ReaR uses the correct parameters for rsync.
  • Improved rsync code for error detection during backup and restore:

    • If there is a rsync error detected during the backup, ReaR aborts with an error message.
    • If there is a rsync error detected during the restore, ReaR displays a warning message.

In the /etc/rear/local.conf file set BACKUP_INTEGRITY_CHECK=1 to turn the warning into an error message.


Loss of backup data on network shares when using ReaR does not occur anymore

Previously, when a network file system like NFS was used to store the ReaR backups, in case of an error ReaR removed the directory where the NFS was mounted. Consequently, this caused backup data loss.

With this update, ReaR now uses a new method to unmount network shares. This new method does not remove the content of the mounted filesystem when it is removes the mount point. The loss of backup data on network shares when using ReaR is now fixed.


ReaR can now be used to back up and recover machines that use ESP

Previously, ReaR did not create Extensible Firmware Interface (EFI) entries when software RAID (MDRAID) is used for the EFI System Partition on machines with Unified Extensible Firmware Interface (UEFI) firmware. When a system with UEFI firmware and EFI System Partition on software RAID were recovered using ReaR; the recovered system was unbootable and required manual intervention to fix the boot EFI variables.

With this update, the support for creating boot EFI entries for software RAID devices is added to ReaR. ReaR can now be used to back up and recover machines that use EFI System Partition (ESP) on software RAID, without manual post-recovery intervention.


/etc/slp.spi file added to openslp package

Previously, the /etc/slp.spi file was missing in the openslp package. Consequently, the /usr/bin/slptool command did not generate output. With this update, /etc/slp.spi has been added to openslp.


BM Power Systems, Little Endian architecture machines with multipath can now be safely recovered using ReaR

Previously, the /sys file system was not mounted in the chroot when ReaR was recovering the system. The ofpathname executable on the IBM Power Systems, Little Endian architecture failed when installing the boot loader. Consequently, the error remained undetected and the recovered system was unbootable.

With this update, ReaR now mounts the /sys file system in the recovery chroot. ReaR ensures that ofpathname is present in the rescue system on Power Systems, Little Endian architecture machines.


5.3. Infrastructure services

Permissions of the /var/lib/chrony have changed

Previously, enterprise security scanners would flag the /var/lib/chrony directory for having world-readable and executable permissions. With this update, the permissions of the /var/lib/chrony directory have changed to limit access only to the root and chrony users.


5.4. Security

GnuTLS no longer rejects SHA-1-signed CAs if they are explicitly trusted

Previously, the GnuTLS library checked signature hash strength of all certificate authorities (CA) even if the CA was explicitly trusted. As a consequence, chains containing CAs signed with the SHA-1 algorithm were rejected with the error message certificate’s signature hash strength is unacceptable. With this update, GnuTLS excludes trusted CAs from the signature hash strength checks and therefore no longer rejects certificate chains containing CAs even if they are signed using weak algorithms.


SELinux policy did not allow GDM to set the GRUB boot_success flag

Previously, SELinux policy did not allow the GNOME Display Manager (GDM) to set the GRUB boot_success flag during the power-off and reboot operations. Consequently, the GRUB menu appeared on the next boot. With this update, the SELinux policy introduces a new xdm_exec_bootloader boolean that allows the GDM to set the GRUB boot_success flag, and which is enabled by default. As a result, the GRUB boot menu is shown on the first boot and the flicker-free boot support feature works correctly.


OSCAP Anaconda Addon now handles customized profiles

Previously, the OSCAP Anaconda Addon plugin did not correctly handle security profiles with customizations in separate files. Consequently, the customized profiles were not available in the RHEL graphical installation even when you specified them in the corresponding Kickstart section. The handling has been fixed, and you can use customized SCAP profiles in the RHEL graphical installation.


OpenSCAP no longer fails during evaluation of the STIG profile and other SCAP content

Previously, initialization of the cryptography library in OpenSCAP was not performed properly in OpenSCAP, specifically in the filehash58 probe. As a consequence, a segmentation fault occurred while evaluating SCAP content containing the filehash58_test Open Vulnerability Assessment Language (OVAL) test. This affected in particular the evaluation of the STIG profile for Red Hat Enterprise Linux 8. The evaluation failed unexpectedly and results were not generated. The process of initializing libraries has been fixed in the new version of the openscap package. As a result, OpenSCAP no longer fails during the evaluation of the STIG profile for RHEL 8 and other SCAP content that contains the filehash58_test OVAL test.


Ansible updates banner files only when needed

Previously, the playbook used for banner remediation always removed the file and recreated it. As a consequence, the banner file inodes were always modified regardless of need. With this update, the Ansible remediation playbook has been improved to use the copy module, which first compares existing content with the intended content and only updates the file when needed. As a result, banner files are only updated when the existing content differs from the intended content.


USB devices now work correctly with the DISA STIG profile

Previously, the DISA STIG profile enabled the USBGuard service but did not configure any initially connected USB devices. Consequently, the USBGuard service blocked any device that was not specifically allowed. This made some USB devices, such as smart cards, unreachable. With this update, the initial USBGuard configuration is generated when applying the DISA STIG profile and allows the use of any connected USB device. As a result, USB devices are not blocked and work correctly.


OSCAP Anaconda Addon now installs all selected packages in text mode

Previously, the OSCAP Anaconda Addon plugin did not evaluate rules that required certain partition layout or package installations and removals before the installation started when running in text mode. Consequently, when a security policy profile was specified using Kickstart and the installation was running in text mode, any additional packages required by a selected security profile were not installed. OSCAP Anaconda Addon now performs the required checks before the installation starts regardless of whether the installation is graphical or text-based, and all selected packages are installed also in text mode.


rpm_verify_permissions removed from the CIS profile

The rpm_verify_permissions rule, which compares file permissions to package default permissions, has been removed from the Center for Internet Security (CIS) Red Hat Enterprise Linux 8 Benchmark. With this update, the CIS profile is aligned with the CIS RHEL 8 benchmark, and as a result, this rule no longer affects users who harden their systems according to CIS.


leftikeport and rightikeport options work correctly

Previously, Libreswan ignored the leftikeport and rightikeport options in any host-to-host Libreswan connections. As a consequence, Libreswam used the default ports regardless of any non-default options settings. With this update, the issue is now fixed and you can use leftikeport and rightikeport connection options over the default options.


5.5. Kernel

Certain BCC utilities do not display the "macro redefined" warning anymore

Macro redefinitions in some compiler-specific kernel headers caused some BPF Compiler Collection (BCC) utilities to display the following zero-impact warning:

warning: '__no_sanitize_address' macro redefined [-Wmacro-redefined]

With this update, the problem has been fixed by removing the macro redefinitions. As a result, the relevant BCC utilities no longer display the warning in this scenario.


kdump no longer fails to dump vmcore on SSH or NFS targets

Previously, when configuring a network interface card (NIC) port to a static IP address and setting kdump to dump vmcore on SSH or NFS dump targets, the kdump service started with the following error message:

ipcalc: command not found

Consequently, a kdump on SSH or NFS dump targets eventually failed.

This update fixes the problem and the kexec-tools utility no longer depends on the ipcalc tool for IP address and netmask calculation. As a result, the kdump works as expected when you use SSH or NFS dump targets.


Certain networking kernel drivers now properly display their version

The behavior for module versioning of many networking kernel drivers changed in RHEL 8.4. Consequently, those drivers did not display their version. Alternatively, after executing the ethtool -i command, the drivers displayed the kernel version instead of the driver version. This update fixes the bug by providing the kernel module strings. As a result, users can determine versions of the affected kernel drivers.


The hwloc commands now return correct data on single CPU Power9 and Power10 logical partitions

With the hwloc utility of version 2.2.0, any single-node Non-Uniform Memory Access (NUMA) system that ran a Power9 or Power10 CPU was considered to be "disallowed". Consequently, all hwloc commands did not work, because NODE0 (socket 0, CPU 0) was offline and the hwloc source code expected NODE0 to be online. The following error message was displayed:

Topology does not contain any NUMA node, aborting!

With this update, hwloc has been fixed so that its source code checks to see if NODE0 is online before querying it. If NODE0 is not online, the code proceeds to the next online NODE.

As a result, the hwloc command does not return any errors in the described scenario.


5.6. High availability and clusters

The ocf:heartbeat:pgsql resource agent and some third-party agents no longer fail to stop during a shutdown process

In the RHEL 8.4 GA release, Pacemaker’s crm_mon command-line tool was modified to display a "shutting down" message rather than the usual cluster information when Pacemaker starts to shut down. As a consequence, shutdown progress, such as the stopping of resources, could not be monitored. In this situation, resource agents that parse crm_mon output in their stop operation (such as the ocf:heartbeat:pgsql agent distributed with the resource-agents package, or some custom or third-party agents) could fail to stop, leading to cluster problems. This bug has been fixed, and the described problem no longer occurs.


5.7. Dynamic programming languages, web and database servers

pyodbc works again with MariaDB 10.3

The pyodbc module did not work with the MariaDB 10.3 server included in the RHEL 8.4 release. The root cause in the mariadb-connector-odbc package has been fixed, and pyodbc now works with MariaDB 10.3 as expected.

Note that earlier versions of the MariaDB 10.3 server and the MariaDB 10.5 server were not affected by this problem.


5.8. Compilers and development tools

GCC Toolset 11: GCC 11 now defaults to DWARF 4

While upstream GCC 11 defaults to using the DWARF 5 debugging format, GCC of GCC Toolset 11 defaults to DWARF 4 to stay compatible with RHEL 8 components, for example, rpmbuild.


The tunables framework now parses GLIBC_TUNABLES correctly

Previously, the tunables framework did not parse the GLIBC_TUNABLES environment variable correctly for non-setuid children of setuid programs. As a consequence, in some cases all tunables remained in non-setuid children of setuid programs. With this update, tunables in the GLIBC_TUNABLES environment variable are correctly parsed. As a result, only a restricted subset of identified tunables are now inherited by non-setuid children of setuid programs.


The semctl system call wrapper in glibc now treats SEM_STAT_ANY like SEM_STAT

Previously, the semctl system call wrapper in glibc did not treat the kernel argument SEM_STAT_ANY like SEM_STAT. As a result, glibc did not pass the address of the result object struct semid_ds to the kernel, so that the kernel failed to update it. With this update, glibc now treats SEM_STAT_ANY like SEM_STAT`, and as a result, applications can obtain struct semid_ds data using SEM_STAT_ANY.



Previously, the Glibc system library headers (/usr/include/netinet/in.h) did not include definitions of IPPROTO_ETHERNET, IPPROTO_MPTCP, and INADDR_ALLSNOOPERS_GROUP. As a consequence, applications needing these definitions failed to compile. With this update, the system library headers now include the new network constant definitions for IPPROTO_ETHERNET, IPPROTO_MPTCP, and INADDR_ALLSNOOPERS_GROUP resulting in correctly compiling applications.


gcc rebased to version 8.5

The GNU Compiler Collection (GCC) has been rebased to upstream version 8.5, which provides a number of bug fixes over the previous version.


Incorrect file decryption using OpenSSL aes-cbc mode

The OpenSSL EVP aes-cbc mode did not decrypt files correctly, because it expects to handle padding while the Go CryptoBlocks interface expects full blocks. This issue has been fixed by disabling padding before executing EVP operations in OpenSSL.


Using CryptBlocks multiple times over the same input stream leads to incorrect encryption

When Go FIPS mode is enabled, AES CBC CryptBlocks incorrectly re-initializes the initialization vector. As a result, using CryptBlocks multiple times over the input stream encrypts files incorrectly. To work around this issue, do not reinitialize IV in the aes-cbc interface. This action allows files to be encrypted correctly.


5.9. Identity Management

FreeRADIUS no longer incorrectly generating default certificates when the bootstrap script is run

A bootstrap script runs each time FreeRADIUS is started. Previously, this script generated new testing certificates in the /etc/raddb/certs directory and as a result, the FreeRADIUS server sometimes failed to start as these testing certificates were invalid. For example, the certificates might have expired. With this update, the bootstrap script checks the /etc/raddb/certs directory and if it contains any testing or customer certificates, the script is not run and the FreeRADIUS server should start correctly.

Note that the testing certificates are only for testing purposes during the configuration of FreeRADIUS and should not be used in a real environment. The bootstrap script should be deleted once the users' certificates are used.


SSSD correctly evaluates the default setting for the Kerberos keytab name in /etc/krb5.conf

Previously, if you defined a non-standard location for your krb5.keytab file, SSSD did not use this location and used the default /etc/krb5.keytab location instead. As a result, when you tried to log into the system, the login failed as the /etc/krb5.keytab contained no entries.

With this update, SSSD now evaluates the default_keytab_name variable in the /etc/krb5.conf and uses the location specified by this variable. SSSD only uses the default /etc/krb5.keytab location if the default_keytab_name variable is not set.


Running sudo commands no longer exports the KRB5CCNAME environment variable

Previously, after running sudo commands, the environment variable KRB5CCNAME pointed to the Kerberos credential cache of the original user, which might not be accessible to the target user. As a result Kerberos related operations might fail as this cache is not accessible. With this update, running sudo commands no longer sets the KRB5CCNAME environment variable and the target user can use their default Kerberos credential cache.


Kerberos now only requests permitted encryption types

Previously, RHEL did not apply permitted encryption types specified in the permitted_enctypes parameter in the /etc/krb5.conf file if the default_tgs_enctypes or default_tkt_enctypes parameters were not set. Consequently, Kerberos clients were able to request deprecated cipher suites, such as RC4, which might cause other processes to fail. With this update, RHEL applies the encryption types set in permitted_enctypes to the default encryption types as well, and processes can only request permitted encryption types.

If you use Red Hat Identity Management (IdM) and want to set up a trust with Active Directory (AD), note that the RC4 cipher suite, which is deprecated in RHEL 8, is the default encryption type for users, services, and trusts between AD domains in an AD forest. You can use one of the following options:


🚧 Changelog cache can upload updates from a wrong starting point (CSN) |


🚧 Internal unindexed searches in syncrepl |


🚧 Internal unindexed searches in syncrepl |


🚧 Internal unindexed searches in syncrepl |


🚧 Internal unindexed searches in syncrepl |


5.10. Red Hat Enterprise Linux System Roles

Role tasks no longer change when running the same output

Previously, several of the role tasks would report as CHANGED when running the same input once again, even if there were no changes. Consequently, the role was not acting idempotent. To fix the issue, perform the following actions:

  • Check if configuration variables change before applying them. You can use the option --check for this verification.
  • Do not add a Last Modified: $date header to the configuration file.

As a result, the role tasks are idempotent.


relayhost parameter no longer incorrectly defined in the Postfix documentation

Previously, the relayhost parameter of the Postfix RHEL System Role was defined as relay_host in the doc /usr/share/doc/rhel-system-roles/postfix/ documentation provided by rhel-system-roles. This update fixes the issue and the relayhost parameter is now correctly defined in the Postfix documentation.


Postfix RHEL System Role no longer missing variables under the "Role Variables" section

Previously, the Postfix RHEL system role variables, such as postfix_check, postfix_backup, postfix_backup_multiple were not available under the "Role Variables" section. Consequently, users were not able to consult the Postfix role documentation. This update adds role variable documentation to the Postfix README section. The role variables are documented and available for users in the doc/usr/share/doc/rhel-system-roles/postfix/ documentation provided by rhel-system-roles.


Postfix role README no longer uses plain role name

Previously, the examples provided in the /usr/share/ansible/roles/rhel-system-roles.postfix/ used the plain version of the role name, postfix, instead of using rhel-system-roles.postfix. Consequently, users would consult the documentation and incorrectly use the plain role name instead of Full Qualified Role Name (FQRN). This update fixes the issue, and the documentation contains examples with the FQRN, rhel-system-roles.postfix, enabling users to correctly write playbooks.


The output log of timesync only reports harmful errors

Previously, the timesync RHEL System Role used the ignore_errors directive with separate checking for task failure in many tasks. Consequently, the output log of the successful role run was full of harmless errors. The users were safe to ignore those errors, but still they were distressing to see. In this update, the relevant tasks have been rewritten not to use ignore_errors. As a result, the output log is now clean, and only role-stopping errors are reported.


The requirements.txt file no longer missing in the Ansible collection

Previously, the requirements.txt file, responsible for specifying the python dependencies, was missing in the Ansible collection. This fix adds the missing file with the correct dependencies at the /usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/requirements.tx path.


Traceback no longer observed when set type: partition for storage_pools

Previously, when setting the variable type as partition for storage_pools in a playbook, running this playbook would fail and indicate traceback. This update fixes the issue and the Traceback error no longer appears.


SElinux role no longer perform unnecessary reloads

Previously, the SElinux role would not check if changes were actually applied before reloading the SElinux policy. As a consequence, the SElinux policy was being reloaded unnecessarily, which had an impact on the system resources. With this fix, the SElinux role now uses ansible handlers and conditionals to ensure that the policy is only reloaded if there is a change. As a result, the SElinux role runs much faster.


5.11. RHEL in cloud environments

nm-cloud-setup utility now sets the correct default route on Microsoft Azure

Previously, on Microsoft Azure, the nm-cloud-setup utility failed to detect the correct gateway of the cloud environment. As a consequence, the utility set an incorrect default route, and connectivity failed. This update fixes the problem. As a result, nm-cloud-setup utility now sets the correct default route on Microsoft Azure.


SSH keys are now generated correctly on EC2 instances created from a backup AMI

Previously, when creating a new Amazon EC2 instance of RHEL 8 from a backup Amazon Machine Image (AMI), cloud-init deleted existing SSH keys on the VM but did not create new ones. Consequently, the VM in some cases could not connect to the host.

This problem has been fixed for newly created RHEL 8.5 VMs. For VMs that were upgraded from RHEL 8.4 or earlier, you must work around the issue manually.

To do so, edit the cloud.cfg file and changing the ssh_genkeytypes: ~ line to ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519']. This makes it possible for SSH keys to be deleted and generated correctly when provisioning a RHEL 8 VM in the described circumstances.


RHEL 8 running on AWS ARM64 instances can now reach the specified network speed

When using RHEL 8 as a guest operating system in a virtual machine (VM) that runs on an Amazon Web Services (AWS) ARM64 instance, the VM previously had lower than expected network performance when the iommu.strict=1 kernel parameter was used or when no iommu.strict parameter was defined.

This problem no longer occurs in RHEL 8.5 Amazon Machine Images (AMIs) provided by Red Hat. In other types of images, you can work around the issue by changing the parameter to iommu.strict=0. This includes:

  • RHEL 8.4 and earlier images
  • RHEL 8.5 images upgraded from an earlier version using yum update
  • RHEL 8.5 images not provided by Red Hat


Core dumping RHEL 8 virtual machines with certain NICs to a remote machine on Azure no longer takes an excessive amount of time

Previously, using the kdump utility to save the core dump file of a RHEL 8 virtual machine (VM) on a Microsoft Azure hypervisor to a remote machine did not work correctly when the VM was using a NIC with enabled accelerated networking. As a consequence, the dump file was saved after approximately 200 seconds, instead of immediately. In addition, the following error message was logged on the console before the dump file is saved.

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

With this update, the underlying code has been fixed, and in the described circumstances, dump files are now saved immediately.