Este conteúdo não está disponível no idioma selecionado.
Chapter 8. Known Issues
This chapter documents known problems in Red Hat Enterprise Linux 7.7.
8.1. Authentication and Interoperability
Inconsistent warning message when applying an ID range change
In RHEL Identity Management (IdM), you can define multiple identity ranges (ID ranges) associated with a local IdM domain or a trusted Active Directory domain. The information about ID ranges is retrieved by the SSSD daemon on all enrolled systems.
A change to ID range properties requires restart of SSSD. Previously, there was no warning about the need to restart SSSD. RHEL 7.7 adds a warning that is displayed when ID range properties are modified in a way that requires restart of SSSD.
The warning message currently uses inconsistent wording. The purpose of the warning message is to ask for a restart of SSSD on any IdM system that consumes the ID range. To learn more about ID ranges, see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/managing-unique_uid_and_gid_attributes
Potential risk when using the default value for ldap_id_use_start_tls option
When using ldap:// without TLS for identity lookups, it can pose a risk for an attack vector. Particularly a man-in-the-middle (MITM) attack which could allow an attacker to impersonate a user by altering, for example, the UID or GID of an object returned in an LDAP search.
Currently, the SSSD configuration option to enforce TLS, ldap_id_use_start_tls, defaults to false. Ensure that your setup operates in a trusted environment and decide if it is safe to use unencrypted communication for id_provider = ldap. Note id_provider = ad and id_provider = ipa are not affected as they use encrypted connections protected by SASL and GSSAPI.
If it is not safe to use unencrypted communication, enforce TLS by setting the ldap_id_use_start_tls option to true in the /etc/sssd/sssd.conf file. The default behavior is planned to be changed in a future release of RHEL.
(JIRA:RHELPLAN-155168)
8.2. Compiler and Tools
GCC thread sanitizer included in RHEL no longer works
Due to incompatible changes in kernel memory mapping, the thread sanitizer included with the GNU C Compiler (GCC) compiler version in RHEL no longer works. Additionally, the thread sanitizer cannot be adapted to the incompatible memory layout. As a result, it is no longer possible to use the GCC thread sanitizer included with RHEL.
As a workaround, use the version of GCC included in Red Hat Developer Toolset to build code which uses the thread sanitizer.
(BZ#1569484)
Context variables in SystemTap not always accessible
The generation of debug information in the GCC compiler has some limitations. As a consequence, when analyzing the resulting executable files with the SystemTap tool, context variables listed in the form $foo are often inaccessible. To work around this limitation, add the -P option to the $HOME/.systemtap/rc file. This causes SystemTap to always select prologue-searching heuristics. As a result, some of the context variables can become accessible.
(BZ#1714480)
ksh with the KEYBD trap mishandles multibyte characters
The Korn Shell (KSH) is unable to correctly handle multibyte characters when the KEYBD trap is enabled. Consequently, when the user enters, for example, Japanese characters, ksh displays an incorrect string. To work around this problem, disable the KEYBD trap in the /etc/kshrc file by commenting out the following line:
trap keybd_trap KEYBD
For more details, see a related Knowledgebase solution.
Error while upgrading PCP from the RHEL 7.6 version
When you upgrade the pcp packages from the RHEL 7.6 to the RHEL 7.7 version, yum returns the following error message:
Failed to resolve allow statement at /etc/selinux/targeted/tmp/modules/400/pcpupstream/cil:83 semodule: Failed!
It is safe to ignore this harmless message, which is caused by a bug in the RHEL 7.6 build of pcp and not by the updated package. The PCP functionality in RHEL 7.7 is not affected.
8.3. Desktop
Gnome Documents cannot display some documents when installed without LibreOffice
Gnome Documents uses libraries provided by the LibreOffice suite for rendering certain types of documents, such as OpenDocument Text or Open Office XML formats. However, the required libreoffice-filters libraries are missing from the dependency list of the gnome-documents package. Therefore, if you install Gnome Documents on a system that does not have LibreOffice, these document types cannot be rendered.
To work around this problem, install the libreoffice-filters package manually, even if you do not plan to use LibreOffice itself.
GNOME Software cannot install packages from unsigned repositories
GNOME Software cannot install packages from repositories that have the following setting in the *.repo file:
gpgcheck=0
If you attempt to install a package from such repository, GNOME software fails with a generic error. Currently, there is no workaround available.
Nautilus does not hide icons in the GNOME Classic Session
The GNOME Tweak Tool setting to show or hide icons in the GNOME session, where the icons are hidden by default, is ignored in the GNOME Classic Session. As a result, it is not possible to hide icons in the GNOME Classic Session even though the GNOME Tweak Tool displays this option.
8.4. Installation and Booting
RHEL 7.7 and later installations add spectre_v2=retpoline to Intel Cascade Lake systems
RHEL 7.7 and later installations add the spectre_v2=retpoline kernel parameter to Intel Cascade Lake systems, and as a consequence, system performance is affected. To work around this problem and ensure the best performance, complete the following steps.
Remove the kernel boot parameter on Intel Cascade Lake systems:
# grubby --remove-args="spectre_v2=retpoline" --update-kernel=DEFAULT
Reboot the system:
# reboot
(BZ#1767612)
8.5. Kernel
RHEL 7 virtual machines sometimes fail to boot on ESXi 5.5
When running Red Hat Enterprise Linux 7 guests with 12 GB RAM or above on a VMware ESXi 5.5 hypervisor, certain components currently initialize with incorrect memory type range register (MTRR) values or incorrectly reconfigure MTRR values across boots. This sometimes causes the guest kernel to panic or the guest to become unresponsive during boot.
To work around this problem, add the disable_mtrr_trim option to the guest’s kernel command line, which enables the guest to continue booting when MTRRs are configured incorrectly. Note that with this option, the guest prints WARNING: BIOS bug messages during boot, which you can safely ignore.
(BZ#1429792)
Certain NIC firmware can become unresponsive with bnx2x
Due to a bug in the unload sequence of the pre-boot drivers, the firmware of some internet adapters can become unresponsive after the bnx2x driver takes over the device. The bnx2x driver detects the problem and returns the message "storm stats were not updated for 3 times" in the kernel log. To work around this problem, apply the latest NIC firmware updates provided by your hardware vendor. As a result, unloading of the pre-boot firmware now works as expected and the firmware no longer hangs after bnx2x takes over the device.
(BZ#1315400)
The i40iw module does not load automatically on boot
Some i40e NICs do not support iWarp and the i40iw module does not fully support suspend and resume operations. Consequently, the i40iw module is not automatically loaded by default to ensure suspend and resume operations work properly. To work around this problem, edit the /lib/udev/rules.d/90-rdma-hw-modules.rules file to enable automated load of i40iw.
Also note that if there is another RDMA device installed with an i40e device on the same machine, the non-i40e RDMA device triggers the rdma service, which loads all enabled RDMA stack modules, including the i40iw module.
(BZ#1622413)
The non-interleaved persistent memory configurations cannot use storage
Previously, systems with persistent memory aligned to 64 MB boundaries, prevented creating of namespaces. As a consequence, the non-interleaved persistent memory configurations in some cases were not able to use storage. To work around this problem, use the interleaved mode for the persistent memory. As a result, most of the storage is available for use, however, with limited fault isolation.
(BZ#1691868)
System boot might fail due to persistent memory file systems
Systems with a large amount of persistent memory take a long time to boot. If the /etc/fstab file configures persistent memory file systems, the system might time out waiting for the devices to become available. The boot process then fails and presents the user with an emergency prompt.
To work around the problem, increase the DefaultTimeoutStartSec value in the /etc/systemd/system.conf file. Use a sufficiently large value, such as 1200s. As a result, the system boot no longer times out.
(BZ#1666535)
radeon fails to reset hardware correctly
The radeon kernel driver currently does not reset hardware in the kexec context correctly. Instead, radeon terminates unexpectedly, which causes the rest of the kdump service to fail.
To work around this bug, blacklist radeon in kdump by adding the following line to the /etc/kdump.conf file:
dracut_args --omit-drivers "radeon"
Afterwards, restart the machine and kdump.
Note that in this scenario, no graphics will be available during kdump, but kdump will complete successfully.
(BZ#1509444)
Certain eBPF tools can cause the system to become unresponsive on IBM Z
Due to a bug in the JIT compiler, running certain eBPF tools contained in the bcc-tools package on IBM Z might cause the system to become unresponsive. To work around this problem, avoid using the dcsnoop, runqlen, and slabratetop tools from bcc-tools on IBM Z until a fix is released.
(BZ#1724027)
Concurrent SG_IO requests in /dev/sg might cause data corruption
The /dev/sg device driver is missing synchronization of kernel data. Concurrent requests in the driver access the same data at the same time.
As a consequence, the ioctl system call might sometimes erroneously use the payload of an SG_IO request for a different command that was sent at the same time as the correct one. This might lead to disk corruption in certain cases. Red Hat has observed this bug in Red Hat Virtualization (RHV).
To work around the problem, use either of the following solutions:
-
Do not send concurrent requests to the
/dev/sgdriver. As a result, eachSG_IOrequest sent to/dev/sgis guaranteed to use the correct data. -
Alternatively, use the
/dev/sdor the/dev/bsgdrivers instead of/dev/sg. The bug is not present in these drivers.
(BZ#1710533)
Incorrect order for inner and outer VLAN tags
The system receives the inner and outer VLAN tags in a swapped order when using QinQ (IEEE802.1Q in IEEE802.1Q standard) over representor devices when using the mlx5 driver. That happens because the rxvlan offloading switch is not effective on this path and it causes Open vSwitch (OVS) to push this error forward. There is no known workaround.
(BZ#1701502)
kdump fails to generate vmcore on Azure instances in RHEL 7
An underlying problem with the serial console implementation on Azure instances booted through the UEFI bootloader causes that the kdump kernel is unable to boot. Consequently, the vmcore of the crashed kernel cannot be captured in the /var/crash/ directory. To work around this problem:
-
Add the
console=ttyS0andearlyprintk=ttyS0parameters to theKDUMP_COMMANDLINE_REMOVEcommand line in the/etc/sysconfig/kdumpdirectory. -
Restart the
kdumpservice.
As a result, the kdump kernel should correctly boot and vmcore is expected to be captured upon crash.
Make sure there is enough space in /var/crash/ to save the vmcore, which can be up to the size of system memory.
(BZ#1724993)
The kdumpctl service fails to load crash kernel if KASLR is enabled
An inappropriate setting of the kptr_restrict kernel tunable causes that contents of the /proc/kcore file are generated as all zeros. As a consequence, the kdumpctl service is not able to access /proc/kcore and to load the crash kernel if Kernel Address Space Layout Randomization (KASLR) is enabled. To work around this problem, keep kptr_restrict set to 1. As a result, kdumpctl is able to load the crash kernel in the described scenario.
For details, refer to the /usr/share/doc/kexec-tools/kexec-kdump-howto.txt file.
(BZ#1600148)
Kdump fails in the second kernel
The kdump initramfs archive is a critical component for capturing the crash dump. However, it is strictly generated for the machine it runs on and has no generality. If you did a disk migration or installed a new machine with a disk image, kdump might fail in the second kernel.
To work around this problem, if you did a disk migration, rebuild initramfs manually by running the following commands:
# touch /etc/kdump.conf # kdumpctl restart
If you are creating a disk image for installing new machines, it is strongly recommended not to include the kdump initramfs in the disk image. It helps to save space and kdump will build the initramfs automatically if it is missing.
(BZ#1723492)
8.6. Networking
Verification of signatures using the MD5 hash algorithm is disabled in Red Hat Enterprise Linux 7
It is impossible to connect to any Wi-Fi Protected Access (WPA) Enterprise Access Point (AP) that requires MD5 signed certificates. To work around this problem, copy the wpa_supplicant.service file from the /usr/lib/systemd/system/ directory to the /etc/systemd/system/ directory and add the following line to the Service section of the file:
Environment=OPENSSL_ENABLE_MD5_VERIFY=1
Then run the systemctl daemon-reload command as root to reload the service file.
Note that MD5 certificates are highly insecure and Red Hat does not recommend using them.
(BZ#1062656)
Booting from a network device fails when the network driver is restarted
Currently, if the boot device is mounted over the network when using iSCSI or Fibre Channel over Ethernet (FCoE), Red Hat Enterprise Linux (RHEL) fails to boot when the underlying network interface driver is restarted.
For example, RHEL restarts the bnx2x network driver when the libvirt service starts its first virtual network and enables IP forwarding. To work around the problem in this specific example, enable IPv4 forwarding earlier in the boot sequence:
# echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/90-forwarding.conf # dracut -f
Note that this workaround works only in the mentioned scenario.
(BZ#1574536)
freeradius might fail when upgrading from RHEL 7.3
A new configuration property, correct_escapes, in the /etc/raddb/radiusd.conf file was introduced in the freeradius version distributed since RHEL 7.4. When an administrator sets correct_escapes to true, the new regular expression syntax for backslash escaping is expected. If correct_escapes is set to false, the old syntax is expected where backslashes are also escaped. For backward compatibility reasons, false is the default value.
When upgrading, configuration files in the /etc/raddb/ directory are overwritten unless modified by the administrator, so the value of correct_escapes might not always correspond to which type of syntax is used in all the configuration files. As a consequence, authentication with freeradius might fail.
To prevent the problem from occurring, after upgrading from freeradius version 3.0.4 (distributed with RHEL 7.3) and earlier, make sure all configuration files in the /etc/raddb/ directory use the new escaping syntax (no double backslash characters can be found) and that the value of correct_escapes in /etc/raddb/radiusd.conf is set to true.
For more information and examples, see the solution Authentication with Freeradius fails since upgrade to version >= 3.0.5.
(BZ#1489758)
RHEL 7 shows the status of an 802.3ad bond as "Churned" after a switch was unavailable for an extended period of time
Currently, when you configure an 802.3ad network bond and the switch is down for an extended period of time, Red Hat Enterprise Linux properly shows the status of the bond as "Churned", even after the connection returns to a working state. However, this is the intended behavior, as the "Churned" status aims to tell the administrator that a significant link outage occurred. To clear this status, restart the network bond or reboot the host.
(BZ#1708807)
Using client-identifier leads to IP address conflict
If the client-identifier option is used, certain network switches ignore the ciaddr field of a dynamic host configuration protocol (DHCP) request. Consequently, the same IP address is assigned to multiple clients, which leads to an IP address conflict. To work around the problem, include the following line in the dhclient.conf file:
send dhcp-client-identifier = "";
As a result, the IP address conflict does not occur under the described circumstances.
8.7. Security
Libreswan does not work properly with seccomp=enabled on all configurations
The set of allowed syscalls in the Libreswan SECCOMP support implementation is currently not complete. Consequently, when SECCOMP is enabled in the ipsec.conf file, the syscall filtering rejects even syscalls needed for the proper functioning of the pluto daemon; the daemon is killed, and the ipsec service is restarted.
To work around this problem, set the seccomp= option back to the disabled state. SECCOMP support must remain disabled to run ipsec properly.
PKCS#11 devices not supporting RSA-PSS cannot be used with TLS 1.3
The TLS protocol version 1.3 requires RSA-PSS signatures, which are not supported by all PKCS#11 devices, such as hardware security modules (HSM) or smart cards. Currently, server applications using NSS do not check the PKCS#11 module capabilities before negotiating TLS 1.3. As a consequence, attempts to authenticate using PKCS#11 devices that do not support RSA-PSS fail. To work around this problem, use TLS 1.2 instead.
TLS 1.3 does not work in NSS in FIPS mode
TLS 1.3 is not supported on systems working in FIPS mode. As a consequence, connections that require TLS 1.3 for interoperability do not function on a system working in FIPS mode.
To enable the connections, disable the system’s FIPS mode or enable support for TLS 1.2 in the peer.
(BZ#1710372)
OpenSCAP inadvertently accesses remote file systems
The OpenSCAP scanner cannot correctly detect whether the scanned file system is a mounted remote file system or a local file system, and the detection part contains also other bugs. Consequently, the scanner reads mounted remote file systems even if an evaluated rule applies to a local file-system only, and it might generate unwanted traffic on remote file systems.
To work around this problem, unmount remote file systems before scanning. Another option is to exclude affected rules from the evaluated profile by providing a tailoring file.
8.8. Servers and Services
Manual initialization of MariaDB using mysql_install_db fails
The mysql_install_db script for initializing the MariaDB database calls the resolveip binary from the /usr/libexec/ directory, while the binary is located in /usr/bin/. Consequently, manual initialization of the database using mysql_install_db fails.
To work around this problem, create a symbolic link to the actual location of the resolveip binary:
ln -s /usr/bin/resolveip /usr/libexec/resolveip
When the symlink is created, mysql_install_db successfully locates resolveip, and the manual database initialization is successful.
Alternatively, use mysql_install_db with the --rpm option. In this case, mysql_install_db does not call the resolveip binary, and therefore does not fail.
(BZ#1731062)
mysql-connector-java does not work with MySQL 8.0
The mysql-connector-java database connector provided in RHEL 7 does not work with the MySQL 8.0 database server. To work around this problem, use the rh-mariadb103-mariadb-java-client database connector from Red Hat Software Collections.
Harmless error messages occur when the balanced Tuned profile is used
The balanced Tuned profile has been changed in the way that the cpufreq_conservative kernel module loads when this profile is applied. However, cpufreq_conservative is built-in in the kernel, and it is not available as a module. Consequently, when the balanced profile is used, the following error messages occasionally appear in /var/log/tuned/tuned.log file:
tuned.utils.commands: Executing modinfo error: modinfo: ERROR: Module cpufreq_conservative not found. tuned.plugins.plugin_modules: kernel module 'cpufreq_conservative' not found, skipping it tuned.plugins.plugin_modules: verify: failed: 'module 'cpufreq_conservative' is not loaded'
Such error messages are harmless, so you can safely ignore them. However, to eliminate the errors, you can override the balanced profile, so that Tuned does not attempt to load the kernel module.
For example, create the /etc/tuned/balanced/tuned.conf file with the following contents:
[main] include=balanced [modules] enabled=0
The php-mysqlnd database connector does not work with MySQL 8.0
The default character set has been changed to utf8mb4 in MySQL 8.0 but this character set is unsupported by the php-mysqlnd database connector. Consequently, php-mysqlnd fails to connect in the default configuration. To work around this problem, specify a known character set as a parameter of the MySQL server configuration. For example, modify the /etc/opt/rh/rh-mysql80/my.cnf.d/mysql-server.cnf file to read:
[mysqld] character-set-server=utf8
8.9. Storage
The system halts unexpectedly when using scsi-mq with software FCoE
The host system halts unexpectedly when it is configured to use both multiqueue scheduling (scsi-mq) and software Fibre Channel over Ethernet (FCoE) at the same time.
To work around the problem, disable scsi-mq when using software FCoE. As a result, the system no longer crashes.
(BZ#1712664)
The system boot sometimes fails on large systems
During the boot process, the udev device manager sometimes generates too many rules on large systems. For example, the problem has manifested on a system with 32 TB of memory and 192 CPUs. As a consequence, the boot process becomes unresponsive or times out and switches to the emergency shell.
To work around the problem, add the udev.children-max=1000 option to the kernel command line. You can experiment with different values of udev.children-max to see which value results in the fastest boot on your system. As a result, the system boots successfully.
(BZ#1722855)
When an image is split off from an active/active cluster mirror, the resulting new logical volume has no active component
When you split off an image from an active/active cluster mirror, the resulting new logical appears active but it has no active component. To activate the newly split-off logical volume, deactivate the volume and then activate it with the following commands:
lvchange -an _vg_/_newly_split_lv_ lvchange -ay _vg_/_newly_split_lv_
8.10. Virtualization
Virtual machines sometimes enable unnecessary CPU vulnerability mitigation
Currently, the MDS_NO CPU flags, which indicate that the CPU is not vulnerable to the Microarchitectural Data Sampling (MDS) vulnerability, are not exposed to guest operating systems. As a consequence, the guest operating system in some cases automatically enables CPU vulnerability mitigation features that are not necessary for the current host.
If the host CPU is known not to be vulnerable to MDS and the virtual machine is not going to be migrated to hosts vulnerable to MDS, MDS vulnerability mitigation can be disabled in Linux guests by using the "mds=off" kernel command-line option. Note, however, that this option disables all MDS mitigations on the guest. Therefore, it should be used with care and should never be used if the host CPU is vulnerable to MDS.
(BZ#1708465)
Modifying a RHEL 8 virtual image on a RHEL 7 host sometimes fails
On RHEL 7 hosts, using virtual image manipulation utilities such as guestfish, virt-sysprep, or virt-customize in some cases fails if the utility targets a virtual image that is using a RHEL 8 file system. This is because RHEL 7 is not fully compatible with certain file-system features in RHEL 8.
To work around the problem, you can disable the problematic features when creating the guest file systems using the mkfs utility:
- For XFS file systems, use the "-m reflink=0" option.
- For ext4 file systems, use the "-O ^metadata_csum" option.
Alternatively, use a RHEL 8 host instead of a RHEL 7 one, where the affected utilities will work as expected.
(BZ#1667478)
Slow connection to RHEL 7 guest console on a Windows Server 2019 host
When using RHEL 7 as a guest operating system in multi-user mode on a Windows Server 2019 host, connecting to a console output of the guest currently takes significantly longer than expected. To work around this problem, connect to the guest using SSH or use Windows Server 2016 as the host.
(BZ#1706522)
SMT works only on AMD EPYC CPU models
Currently, only the AMD EPYC CPU models support the simultaneous multithreading (SMT) feature. As a consequence, manually enabling the topoext feature when configuring a virtual machine (VM) with a different CPU model causes the VM not to detect the vCPU topology correctly, and the vCPU does not perform as configured. To work around this problem, do not enable topoext manually and do not use the threads vCPU option on AMD hosts unless the host is using the AMD EPYC model
