6.7. 已知问题
这部分论述了 Red Hat Enterprise Linux 8 中已知的问题。
6.7.1. 安装程序和镜像创建
auth 和 authconfig Kickstart 命令需要 AppStream 软件仓库
auth 和 authconfig Kickstart 命令在安装过程中需要 authselect-compat 软件包。如果没有这个软件包，如果使用了 auth 或 authconfig，则安装会失败。但根据设计，authselect-compat 软件包只包括在 AppStream 仓库中。
要临时解决这个问题，请确定安装程序可使用 BaseOS 和 AppStream 软件仓库，或者在安装过程中使用 authselect Kickstart 命令。
(BZ#1640697)
reboot --kexec 和 inst.kexec 命令不提供可预测的系统状态
使用 reboot --kexec Kickstart 命令或 inst.kexec 内核引导参数执行 RHEL 安装不会提供与完全重启相同的可预期系统状态。因此，在不重启的情况下切换安装的系统可能会导致无法预计的结果。
请注意，kexec 功能已弃用，并将在以后的 Red Hat Enterprise Linux 版本中删除。
(BZ#1697896)
Anaconda 安装包括最小资源设置要求的低限制
Anaconda 以最少的资源设置在系统中启动安装，并且不要提供有关成功执行安装所需的资源的先前消息警告。因此，安装可能会失败，输出错误不会为可能的调试和恢复提供清晰的信息。要临时解决这个问题，请确保系统具有安装所需的最少资源设置：2GB 内存在 PPC64(LE)和 1GB on x86_64 上。因此，应该可以成功执行安装。
(BZ#1696609)
使用 reboot --kexec 命令安装失败
当使用包含 reboot --kexec 命令的 Kickstart 文件时，RHEL 8 安装会失败。为避免问题，请在 Kickstart 文件中使用 reboot 命令而不是 reboot --kexec。
在安装程序中支持 s390x 的安全引导
RHEL 8.1 支持准备引导磁盘，以便在强制使用安全引导的 IBM Z 环境中使用。安装期间使用的服务器和系统管理程序的功能决定了生成的磁盘上格式是否包含安全引导支持。安装期间无法影响磁盘格式。
因此，如果您在一个支持安全引导的环境中安装 RHEL 8.1，则该系统无法在移到没有安全引导支持的环境中引导，因为在有些故障转移场景中会完成此操作。
要临时解决这个问题，您需要配置控制磁盘引导格式的 zipl 工具。zipl 可以配置为写入以前的磁盘上格式，即使运行它的环境支持安全引导。安装完 RHEL 8.1 后，以 root 用户身份执行以下手工步骤：
-
编辑配置文件
/etc/zipl.conf 将含有"secure=0"的行添加到标有"defaultboot"的部分。
Example contents of the `zipl.conf` file after the change:
[defaultboot] defaultauto prompt=1 timeout=5 target=/boot secure=0
-
运行不带
参数的 zipl工具
执行这些步骤后，RHEL 8.1 引导磁盘的磁盘上格式将不再包含安全引导支持。因此，可以在缺乏安全引导支持的环境中引导安装。
(BZ#1659400)
RHEL 8 初始设置无法通过 SSH 执行
目前，当使用 SSH 登录到系统时，RHEL 8 初始设置接口不会显示。因此，无法在通过 SSH 管理的 RHEL 8 机器上执行初始设置。要临时解决这个问题，请在主系统控制台(ttyS0)中执行初始设置，然后再使用 SSH 登录。
(BZ#1676439)
secure= 引导选项的默认值没有设置为 auto
目前，secure= 引导选项的默认值没有设置为 auto。因此，安全引导功能不可用，因为当前的默认被禁用。要临时解决这个问题，在 /etc/zipl.conf 文件的 [defaultboot] 部分中手动设置 secure=auto。因此，可以使用安全引导功能。如需更多信息，请参阅 zipl.conf man page。
(BZ#1750326)
将 Binary DVD.iso 文件的内容复制到分区会省略 .treeinfo 和 .discinfo 文件
在本地安装过程中，当将 RHEL 8 Binary DVD.iso 镜像文件的内容复制到分区时，cp <path>/\* <mounted 分区>/dir 命令中的 * 无法复制 .treeinfo 和 .discinfo 文件。成功安装时需要这些文件。因此，BaseOS 和 AppStream 软件仓库不会被加载，在 anaconda.log 文件中与 debug 相关的日志消息是问题的唯一记录。
要临时解决这个问题，将 missing .treeinfo 和 .discinfo 文件复制到分区中。
(BZ#1687747)
Kickstart 安装无法使用自签名 HTTPS 服务器
目前，当在 kickstart 文件中指定安装源并使用 --noverifyssl 选项时，安装程序无法从自签名的 https 服务器安装：
url --url=https://SERVER/PATH --noverifyssl
要临时解决这个问题，请在开始 kickstart 安装时将 inst.noverifyssl 参数附加到内核命令行中。
例如：
inst.ks=<URL> inst.noverifyssl
(BZ#1745064)
6.7.2. 软件管理
yum repolist 在第一个不可用的库中结束，它带有 skip_if_unavailable=false
存储库配置选项 skip_if_unavailable 默认设置为如下：
skip_if_unavailable=false
此设置强制 yum repolist 命令在第一个不可用存储库中结束，并显示错误并退出状态 1。因此，yum repolist 不会继续列出可用的存储库。
请注意，可以在每个存储库的 *.repo 文件中覆盖此设置。
但是，如果要保留默认设置，您可以使用 yum repolist 并包含以下选项来解决这个问题：
--setopt=*.skip_if_unavailable=True
(BZ#1697472)
6.7.3. 订阅管理
syspurpose addons 对 subscription-manager attach --auto 输出没有影响。
在 Red Hat Enterprise Linux 8 中，添加了 syspurpose 命令行工具的四个属性：role、usage、service_level_agreement 和 addons目前，只有 role、usage 和 service_level_agreement 会影响到运行 subscription-manager attach --auto 命令的输出。试图为 addons 参数设置值的用户不会观察到对自动附加的订阅有任何影响。
(BZ#1687900)
6.7.4. Shell 和命令行工具
使用 Wayland 协议的应用无法转发到远程显示服务器
在 Red Hat Enterprise Linux 8.1 中，大多数应用默认使用 Wayland 协议，而不是 X11 协议。因此，ssh 服务器无法转发使用 Wayland 协议的应用，但能够将使用 X11 协议的应用转发到远程显示服务器。
要临时解决这个问题，请在启动应用程序前设置环境变量 GDK_BACKEND=x11。因此，可以将应用转发到远程显示服务器。
systemd-resolved.service 无法在引导时启动
systemd-resolved 服务偶尔无法在引导时启动。如果发生这种情况，请在引导完成后手动重启该服务：
# systemctl start systemd-resolved
但是，在引导时 解析 systemd 失败不会影响任何其他服务。
(BZ#1640802)
6.7.5. 基础架构服务
在 dnsmasq 中支持 DNSSEC
dnsmasq 软件包引入了域名系统安全扩展(DNSSEC)支持，用于验证从 root 服务器接收的主机名信息。
请注意，dnsmasq 中的 DNSSEC 验证与 FIPS 140-2 不兼容。不要在联邦信息处理标准(FIPS)系统上的 dnsmasq 中启用 DNSSEC，并使用兼容验证解析器作为 localhost 上的转发器。
(BZ#1549507)
6.7.6. 安全性
redhat-support-tool 无法用于 FUTURE 加密策略
因为客户门户网站 API 中的证书使用的加密密钥不满足 FUTURE 系统范围的加密策略的要求，所以 redhat-support-tool 程序目前无法使用这个策略级别。要临时解决这个问题，在连接到客户门户网站 API 时使用 DEFAULT 加密策略。
/etc/selinux/config 中的SELINUX=disabled 无法正常工作
在 /etc/selinux/config 中使用 SELINUX=disabled 选项禁用 SELinux 会导致内核在启用了 SELinux 的情况下引导，并在稍后的引导过程中切换到禁用模式。这可能导致内存泄漏和竞争条件，因此也会导致内核 panic。要临时解决这个问题，请在内核命令行中添加 selinux=0 参数来禁用 SELinux，如 使用 SELinux 中的在引导时更改 SELinux 模式部分所述。
（JIRA:RHELPLAN-34199）
libselinux-python 只能通过其模块提供
libselinux-python 软件包只包含用于开发 SELinux 应用程序的 Python 2 绑定，它用于向后兼容。因此，通过 dnf install libselinux-python 命令，默认的 RHEL 8 软件仓库不再提供 libselinux-python。
要临时解决这个问题，请启用 libselinux-python 和 python27 模块，并使用以下命令安装 libselinux-python 软件包及其相依性软件包：
# dnf module enable libselinux-python # dnf install libselinux-python
或者，使用它的安装配置集在一个命令中安装 libselinux-python:
# dnf module install libselinux-python:2.8/common
因此，您可以使用相关的模块安装 libselinux-python。
(BZ#1666328)
UDICA 仅在使用 --env container=podman 启动时才会处理 UBI 8 容器
Red Hat Universal Base Image 8(UBI 8)容器将 container 环境变量设置为 oci 值，而不是 podman 值。这可以防止 udica 工具分析容器 JavaScript 对象表示法(JSON)文件。
要临时解决这个问题,请使用带有 --env container=podman 参数的 podman 命令启动 UBI 8 容器。因此，只有使用上述临时解决方案时，udica 才 可以为 UBI 8 容器生成 SELinux 策略。
删除 rpm-plugin-selinux 软件包会导致从系统中删除所有 selinux-policy 软件包
删除 rpm-plugin-selinux 软件包会禁用机器中的 SELinux。它还会从系统中删除所有 selinux-policy 软件包。重复安装 rpm-plugin-selinux 软件包后会安装 selinux-policy-minimum SELinux 策略，即使之前系统中存在 selinux-policy-targeted 策略。但是，重复安装不会更新 SELinux 配置文件来考虑策略的改变。因此，即使重新安装 rpm-plugin-selinux 软件包也会禁用 SELinux。
要临时解决这个问题：
-
输入
umount /sys/fs/selinux/命令。 -
手动安装缺少的
selinux-policy-targeted软件包。 -
编辑
/etc/selinux/config文件以便策略等同于SELINUX=enforcing。 -
输入命令
load_policy -i。
因此，SELinux 被启用并运行和以前相同的策略。
(BZ#1641631)
SELinux 会阻止 systemd-journal-gatewayd 在由 corosync创建的共享内存文件中调用 newfstatat（）
SELinux 策略不包含允许 systemd-journal-gatewayd 守护进程访问由 corosync 服务创建的文件的规则。因此，SELinux 拒绝 systemd-journal-gatewayd 在由 corosync 创建的共享内存文件中调用 newfstatat（） 功能。
要临时解决这个问题，请使用启用上述场景的 allow 规则创建一个本地策略模块。有关生成 SELinux 策略 允许 和 dontaudit 规则 的更多信息，请参阅 audit2allow(1) man page。由于前面的临时解决方案，systemd-journal-gatewayd 可以在 enforcing 模式中使用 SELinux 的 corosync 创建的共享内存文件上调用该功能。
(BZ#1746398)
默认日志设置在性能上的负面影响
默认日志环境设置可能会消耗 4 GB 内存甚至更多，当 systemd-journald 使用 rsyslog 运行时，速率限制值的调整会很复杂。
如需更多信息，请参阅 RHEL 默认日志设置对性能的负面影响及环境方案。
（JIRA:RHELPLAN-10431）
在带有 config.enabled的 rsyslog 输出中的 Parameter not known 错误
在 rsyslog 输出中，使用 config.enabled 指令在配置处理错误中出现意外错误。因此，在使用 config.enabled 指令时会显示 参数未知的错误，但 include（） 语句除外。
要临时解决这个问题，请设置 config.enabled=on 或者使用 include（） 语句。
(BZ#1659383)
某些 rsyslog 优先级字符串不能正常工作
对允许精细控制加密的 imtcp 的 GnuTLS 优先级字符串的支持并不完整。因此，以下优先级字符串无法在 rsyslog 中正常工作：
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+DHE-RSA:+AES-256-GCM:+SIGN-RSA-SHA384:+COMP-ALL:+GROUP-ALL
要临时解决这个问题，请只使用正确的优先级字符串：
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+ECDHE-RSA:+AES-128-CBC:+SIGN-RSA-SHA1:+COMP-ALL:+GROUP-ALL
因此，当前的配置必须仅限于可正常工作的字符串。
到带有 SHA-1 签名的服务器的连接无法使用 GnuTLS
GnuTLS 安全通讯库以 insecure 形式拒绝 SHA-1 证书签名。因此，使用 GnuTLS 作为 TLS 后端的应用程序无法建立与提供此类证书的对等的 TLS 连接。这个行为与其他系统加密库不一致。要临时解决这个问题，请升级服务器以使用 SHA-256 或更强大的哈希签名的证书，或切换到 LEGACY 策略。
(BZ#1628553)
TLS 1.3 在 FIPS 模式下不能在 NSS 中正常工作
在使用 FIPS 模式的系统中不支持 TLS 1.3。因此，需要 TLS 1.3 进行互操作性的连接不能在工作在 FIPS 模式下的系统上正常工作。
要启用连接，请禁用系统的 FIPS 模式，或者启用对 peer 中 TLS 1.2 的支持。
OpenSSL 错误处理 PKCS #11 tokens 不支持原始 RSA 或 RSA-PSS 签名
OpenSSL 库不会检测到 PKCS #11 令牌的与键相关的功能。因此，当使用不支持原始 RSA 或 RSA-PSS 签名的令牌创建签名时，建立 TLS 连接会失败。
要临时解决这个问题，请在 /etc/pki/tls/openssl.cnf 文件的 crypto_policy 部分的 .include 行后面添加以下行：
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
因此，可以在描述的场景中建立 TLS 连接。
OpenSSL TLS 库不会检测 PKCS#11 令牌是否支持创建 原始 RSA 或 RSA-PSS 签名
TLS-1.3 协议需要支持 RSA-PSS 签名。如果 PKCS#11 令牌不支持 原始 RSA 或 RSA-PSS 签名，则使用 OpenSSL TLS 库的服务器应用程序如果被 PKCS#11 令牌持有，将无法使用 RSA 密钥。因此，TLS 通信将失败。
要临时解决这个问题，请将服务器或客户端配置为使用 TLS-1.2 版本作为可用最高 TLS 协议版本。
OpenSSL 在 TLS 1.3 中的 CertificateRequest 消息中生成一个不正确的 status_request 扩展
如果启用了 status_request 扩展和基于客户端证书的身份验证，OpenSSL 服务器会在 CertificateRequest 消息中发送错误的 status_request 扩展。在这种情况下，OpenSSL 无法与 RFC 8446 协议兼容的实施互操作。因此，可以正确地验证与 OpenSSL 服务器建立连接的 'CertificateRequest' 消息中的扩展的客户端。要临时解决这个问题，在连接两侧禁用对 TLS 1.3 协议的支持，或者禁用对 OpenSSL 服务器上的 status_request 的支持。这将阻止服务器发送错误的消息。
ssh-keyscan 无法在 FIPS 模式中检索服务器的 RSA 密钥
在 FIPS 模式中的 RSA 签名禁用了 SHA-1 算法，这样可防止 ssh-keyscan 工具程序获取在那个模式下运行的服务器的 RSA 密钥。
要临时解决这个问题，使用 ECDSA 密钥，或者使用服务器中的 /etc/ssh/ssh_host_rsa_key.pub 文件在本地检索密钥。
审计规则的 SCAP-security-guide PCI-DSS 修复无法正常工作
scap-security-guide 软件包包含补救的组合，以及可导致以下情况之一的检查：
- 错误修复审计规则
- 包含误报的扫描评估，其中通过的规则被标记为失败
因此，在 RHEL 8.1 安装过程中，扫描安装的系统会将一些审计规则报告为失败或错误。
要临时解决这个问题，请按照 RHEL-8.1 临时解决方案文档中的说明使用 scap-security-guide PCI-DSS 配置集文档中的内容进行修复和扫描。
某些 SSG 中的规则组可能会失败
由于规则及其依赖项未定义，在基准中修复 SCAP 安全指南 (SSG)规则可能会失败。如果需要以特定顺序执行两个或多个规则，例如，当一条规则安装组件和另一个规则配置同一组件时，它们可按错误的顺序运行，并报告错误。要临时解决这个问题，请执行补救两次，第二次运行会修复依赖规则。
不提供用于容器安全性和合规性扫描的工具
在红帽企业 Linux 7 中，可使用 the oscap-docker 实用程序扫描基于 Atomic 技术的 Docker 容器。在 Red Hat Enterprise Linux 8 中，Docker 和 Atomic 相关的 OpenSCAP 命令不可用。
要临时解决这个问题，请参阅使用 OpenSCAP 在 RHEL 8 中扫描容器。因此，在 RHEL 8 中，您目前只能使用不受支持且有限的方式进行容器的安全性和合规性扫描。
(BZ#1642373)
OpenSCAP 不提供虚拟机和容器的离线扫描
重构 OpenSCAP 代码库会导致某些 RPM 探测无法在离线模式下扫描虚拟机和容器文件系统。因此，以下工具已从 openscap-utils 软件包中删除： oscap-vm 和 oscap-chroot。另外，opens cap-containers 软件包已被完全删除。
(BZ#1618489)
OpenSCAP rpmverifypackage 无法正常工作
rpmverifypackage 探测调用 chdir 和 chroot 系统调用两次。因此，在使用自定义 Open Vulnerability 和评估语言(OVAL)内容的 OpenSCAP 扫描中使用探测时会出现错误。
要临时解决这个问题，请不要在您的内容中使用 rpmverifypackage_test OVAL 测试，或者仅使用未使用 rpmverifypackage_test 的 scap-security-guide 软件包中的内容。
(BZ#1646197)
SCAP Workbench 无法从定制的配置集生成基于结果的补救方法
当尝试使用SCAP Workbench 工具从自定义配置集生成基于结果的补救角色时，会出现以下错误：
Error generating remediation role .../remediation.sh: Exit code of oscap was 1: [output truncated]
要临时解决这个问题，请使用带有 --tailoring-file 选项的 oscap 命令。
(BZ#1640715)
OSCAP Anaconda Addon 不会在文本模式中安装所有软件包
如果安装以文本模式运行，则 OSCAP Anaconda Addon 插件无法修改为系统安装程序安装而选择的软件包列表。因此，当使用 Kickstart 指定安全策略配置集且安装以文本模式运行时，安全策略所需的附加软件包不会在安装过程中安装。
要临时解决这个问题，可以使用图形模式运行安装，或者在 Kickstart 文件的 %packages 部分指定安全策略配置集所需的所有软件包。
因此，在没有描述的一个临时解决方案的情况下，安全策略配置集所需的软件包不会在 RHEL 安装过程中安装，且安装的系统与给定的安全策略配置集不兼容。
OSCAP Anaconda Addon 组件无法正确处理自定义配置集
OSCAP Anaconda Addon 插件无法以独立文件中自定义的方式正确处理安全配置集。因此，即使您在对应的 Kickstart 部分正确指定了自定义配置集，RHEL 图形安装中也不会提供自定义配置集。
要临时解决这个问题，请遵循 从原始 DS 创建单一 SCAP 数据流中的说明,以及一个定制文件 知识库文章。因此，您可以在 RHEL 图形安装中使用自定义的 SCAP 配置集。
(BZ#1691305)
6.7.7. 网络
arptables 详细输出的格式现在与 RHEL 7 上的 实用程序格式匹配
在 RHEL 8 中，iptables-arptables 软件包提供基于 nftables的 arptables 工具替换。在以前的版本中，arptables 分隔的计数器值的详细输出只使用逗号分开，而 RHEL 7 中的 rptables 则使用空格和逗号分开。因此，如果您使用了在 RHEL 7 上创建的脚本来解析 arptables -v -L 命令的输出，则必须调整这些脚本。这个不兼容已被解决。因此，RHEL 8.1 上的 arptables 现在也会使用空格和逗号分开计数器值。
(BZ#1676968)
nftables 不支持多组 IP 设置类型
nftables 数据包过滤框架不支持设置具有串联和间隔的类型。因此，您无法使用多组 IP 设置类型，如 hash:net,port， 且带有 nftables。
要临时解决这个问题，如果您需要多组 IP 设置类型，请将 iptables 框架与 ipset 工具一起使用。
(BZ#1593711)
当禁用 GRO 时，IPsec 网络流量在 IPsec 卸载过程中失败
当在该设备中禁用通用接收 Offload（GRO）时，IPsec 卸载将不会正常工作。如果在一个网络接口中配置了 IPsec 卸载，且在该设备中禁用 GRO，IPsec 网络流量会失败。
要临时解决这个问题，在该设备中启用 GRO。
(BZ#1649647)
6.7.8. 内核
i40iw 模块不会在引导时自动载入
由于许多 i40e NIC 不支持 iWarp，并且 i40iw 模块没有全面支持 suspend/resume，因此此模块默认不会自动加载，以确保暂停/恢复正常工作。要临时解决这个问题，请手动编辑 /lib/udev/rules.d/90-rdma-hw-modules.rules 文件，以启用 i40iw 的自动负载。
另请注意，如果在同一机器上安装了带有 i40e 设备的另一个 RDMA 设备，则非 i40e RDMA 设备会触发 rdma 服务，它会加载所有启用的 RDMA 堆栈模块，包括 i40iw 模块。
(BZ#1623712)
使用 fadump 时，网络接口被重命名为 kdump-<interface-name>
当使用固件辅助的转储(fadump)捕获 vmcore ，并使用 SSH 或 NFS 协议将其保存到远程机器时，网络接口通常被重命名为 kdump-<interface-name> if <interface-name>，如 *eth# 或 net#。这是因为初始 RAM 磁盘(initrd)中的 vmcore 捕获脚本在网络接口名称中添加 kdump- 前缀来保护持久性命名。同一 initrd 也用于常规引导，因此生产内核的接口名称也会更改。
(BZ#1745507)
有大量持久内存的系统在引导过程中出现延迟
有大量持久内存的系统需要很长时间才能引导，因为初始化内存是序列化的。因此，如果 /etc/fstab 文件中列出了持久的内存文件系统，系统在等待设备可用时可能会超时。要临时解决这个问题，请将 /etc/systemd/system.conf 文件中的 DefaultTimeoutStartSec 选项配置为足够大的值。
(BZ#1666538)
KSM 有时会忽略 NUMA 内存策略
当内核共享内存(KSM)功能通过 merge_across_nodes=1 参数启用时，KSM 会忽略 mbind（）函数设置的内存策略，并且可能会将某些内存区域的页面合并到与策略不匹配的非一致性内存访问(NUMA)节点。
要临时解决这个问题，如果使用 NUMA 内存与 QEMU 绑定，请禁用 KSM 或将 merge_across_nodes 参数设置为 0。因此，为 KVM 虚拟机配置的 NUMA 内存策略可以正常工作。
(BZ#1153521)
启用 fadump 时，系统在引导时进入紧急模式
当 initramfs 方案中启用了 fadump( kdump)or dracut squash 模块时，系统进入紧急模式，因为 systemd Manager 无法获取挂载信息并将 LV 分区配置为挂载。要临时解决这个问题，请添加以下内核命令行参数 rd.lvm.lv=<VG>/<LV> 以正确发现并挂载失败的 LV 分区。因此，系统将在上述场景中成功引导。
(BZ#1750278)
在 kdump 内核命令行中使用 irqpoll 会导致 vmcore 生成失败
由于在 Amazon Web Services(AWS)云平台上运行的 64 位 ARM 架构中存在 thenvme 驱动程序 的底层问题，如果第一个内核提供了 irqpoll kdump 命令行参数，vmcore 生成会失败。因此，在内核崩溃后，/var/crash/ 目录中不会转储 vmcore。要临时解决这个问题：
-
将
irqpoll添加到 /etc/sysconfig/kdump 文件的KDUMP_COMMANDLINE_REMOVE键。 -
运行
systemctl restart kdump命令重启kdump服务。
因此，第一个内核可以正确引导，在内核崩溃时 vmcore 应该会被捕获。
(BZ#1654962)
Debug 内核无法在 RHEL 8 的崩溃捕获环境中引导
由于 debug 内核的内存需求特性，会在使用 debug 内核并触发内核 panic 时出现问题。因此，调试内核无法作为捕获内核引导，而是生成一个堆栈追踪。要临时解决这个问题，相应地增大崩溃内核内存。因此，debug 内核可以在崩溃捕获环境中成功引导。
(BZ#1659609)
softirq 更改可能会导致 localhost 接口在负载过重时丢弃 UDP 数据包
对 Linux 内核的软件中断(softirq)处理进行了更改，以减少拒绝服务(DOS)影响。因此，在 localhost 接口高负载下丢弃 User Datagram Protocol(UDP)数据包时，会出现这样的情况。
要临时解决这个问题，将网络设备积压缓冲的大小增加到值 6000：
echo 6000 > /proc/sys/net/core/netdev_max_backlog
在红帽进行的测试中，这个值足以防止数据包丢失。负载较大的系统可能需要更大的积压值。增加的积压会导致潜在的延迟在 localhost 接口上增加。
结果是增加缓冲区并允许更多数据包等待处理，这降低了丢弃 localhost 数据包的几率。
(BZ#1779337)
6.7.9. 硬件启用
在某些情况下，HP NMI watchdog 不会生成崩溃转储
HP NMI watchdog 的 hpwdt 驱动程序有时无法声明由 HPE watchdog 计时器生成的不可屏蔽中断(NMI)，因为 NMI 被 perfmon 驱动程序使用。因此，hpwdt 在某些情况下无法调用 panic 来生成崩溃转储。
(BZ#1602962)
在配置了 QL41000 卡的测试系统中安装 RHEL 8.1 会导致内核 panic
在配置了 a QL41000 卡的测试系统上安装 RHEL 8.1 时，系统无法处理位于 000000000000003c 卡的内核 NULL pointer dereference。因此，这会导致内核 panic 错误。这个问题没有可用的工作。
(BZ#1743456)
cxgb4 驱动会导致 kdump 内核崩溃
在 vmcore 文件中保存信息时 kdump 内核会崩溃。因此，cxgb4 驱动程序可防止 kdump 内核保存内核以便稍后进行分析。要临时解决这个问题，在 kdump 内核命令行中添加 "novmcoredd" 参数以允许保存核心文件。
(BZ#1708456)
6.7.10. 文件系统和存储
某些 SCSI 驱动程序有时可能会使用过多的内存
某些 SCSI 驱动程序使用的内存比 RHEL 7 中的内存更大。在某些情况下，比如在光纤通道主机总线适配器(HBA)上创建 vPort，内存用量可能会过大，具体取决于系统配置。
内存用量增加是由块层中内存预分配造成的。多队列块设备调度(BLK-MQ)和多队列 SCSI 堆栈(SCSI-MQ)预分配 RHEL 8 中每个 I/O 请求的内存，从而提高了内存用量。
(BZ#1698297)
在 UDS 完成重建前，VDO 无法挂起
当虚拟数据优化器(VDO)卷在未清除系统关闭后启动时，它会重建通用重复数据删除服务(UDS)索引。如果您在重新构建 UDS 索引时尝试使用 dmsetup suspend 命令挂起 VDO 卷，则挂起命令可能会变得无响应。该命令仅在重新构建完成后完成。
仅在带有大型 UDS 索引的 VDO 卷中明显没有响应，这会导致重建需要更长的时间。
NFS 4.0 补丁可能会导致 open-heavy 工作负载性能降低。
在以前的版本中，存在一个程序错误，在某些情况下，可能会导致 NFS 打开操作覆盖文件已被删除或重命名在服务器中的事实。但是，这个修复可能会在需要很多打开操作的工作负载中造成性能下降。要临时解决这个问题，您可能需要使用 NFS 版本 4.1 或更高版本，这些版本已被改进为客户端在本地、快速和安全地执行开放操作。
(BZ#1748451)
6.7.11. 动态编程语言、网页和数据库服务器
nginx 无法从硬件安全令牌加载服务器证书
nginx web 服务器支持直接从 PKCS#11 模块的硬件安全令牌加载 TLS 私钥。但是，目前无法通过 PKCS#11 URI 从硬件安全令牌加载服务器证书。要临时解决这个问题，在文件系统中存储服务器证书
当使用 PHP 7.2 安装 php-opcache 时，php-fpm 会导致 SELinux AVC 拒绝
安装 php-opcache 软件包后，FastCGI Process Manager(php-fpm)会导致 SELinux AVC 拒绝。要临时解决这个问题，将 /etc/php.d/10-opcache.ini 文件中的默认配置改为：
opcache.huge_code_pages=0
请注意，此问题仅影响 php:7.2 流，而非 php:7.3 流。
6.7.12. 编译器和开发工具
ltrace 工具不报告函数调用
由于改进了应用于所有 RHEL 组件的二进制强化，ltrace 工具 无法再检测 RHEL 组件的二进制文件中的功能调用。因此，lt race 输出 为空，因为它不会报告在此类二进制文件上使用任何检测到的调用。目前还没有可用的临时解决方案。
请注意，lt race 可以 正确地报告构建的自定义二进制文件中的调用，而不使用相应的强化标志。
(BZ#1618748)
6.7.13. 身份管理
使用 GSSAPI 身份验证时，允许带有过期帐户的 AD 用户登录
SSSD 用于查看帐户是否已过期的 accountExpires 属性默认情况下是否不复制到全局目录。因此，帐户过期的用户在使用 GSSAPI 身份验证时可以登录。要临时解决这个问题，可以通过在 sssd.conf 文件中指定 ad_enable_gc=False 来禁用全局目录支持。使用这个设置时，帐户过期的用户在使用 GSSAPI 身份验证时将被拒绝访问。
请注意，SSSD 在此场景中单独连接到每个 LDAP 服务器，这样可以增加连接数。
(BZ#1081046)
将 cert-fix 程序与 --agent-uid pkidbuser 选项一同使用会破坏证书系统
使用带有 --agent-uid pkidbuser 选项的 cert-fix 工具可破坏证书系统的 LDAP 配置。因此,，证系统可能会变得不稳定，需要手动步骤才能恢复该系统。
更改 /etc/nsswitch.conf 需要手动重启系统
对 /etc/nsswitch.conf 文件的任何更改（例如运行 authselect select profile_id 命令）都需要重启系统，以便所有相关进程使用更新版本的 /etc/nsswitch.conf 文件。如果无法重新启动系统，请重新启动将您的系统加入 Active Directory 的服务，即 系统安全服务后台程序 (SSSD)或 winbind。
在 IdM 中启用 AD 信任时，没有显示有关所需 DNS 记录的信息
当通过外部 DNS 管理启用对 Red Hat Enterprise Linux Identity Management(IdM)安装中的 Active Directory(AD)信任时，不会显示有关所需 DNS 记录的信息。只有添加所需的 DNS 记录后，林信任才会成功。要临时解决这个问题，请运行 'ipa dns-update-system-records --dry-run' 命令，以获取 IdM 所需的所有 DNS 记录列表。当 IdM 域的外部 DNS 定义所需的 DNS 记录时，有可能建立对 AD 的林信任。
SSSD 为本地用户返回不正确的 LDAP 组成员资格
如果系统安全服务守护进程(SSSD)从本地文件为用户提供服务，则文件提供商不包含来自其他域的组成员资格。因此，如果本地用户是 LDAP 组的成员，id local_user 命令不会返回用户的 LDAP 组成员资格。要临时解决这个问题，请恢复系统在 /etc/nsswitch.conf 文件中查找用户组成员资格的数据库顺序，使用 文件替换 sss 文件， 或通过添加 来禁用隐式 文件 域
enable_files_domain=False
到 /etc/sssd/sssd.conf 文件中的 [sssd] 部分：
因此，id local_user 会为本地用户返回正确的 LDAP 组成员资格。
RHEL 8 中已更改了 systemd-user 的默认 PAM 设置，这可能会影响 SSSD 行为
Red Hat Enterprise Linux 8 中更改了可插拔验证模块(PAM)堆栈。例如，systemd 用户会话现在使用 systemd -user PAM 服务启动 PAM 对话。此服务现在递归包含 system-auth PAM 服务，其可能包括 pam_sss.so 接口。这意味着始终调用 SSSD 访问控制。
请注意为 RHEL 8 系统设计访问控制规则时的更改。例如，您可以将 systemd-user 服务添加到允许的服务列表中。
请注意，对于某些访问控制机制，如 IPA HBAC 或 AD GPOs，默认情况下 systemd-user 服务已添加到允许的服务列表中，您不需要进行任何操作。
SSSD 无法正确处理具有相同优先级的多个证书匹配规则
如果给定证书与多个具有相同优先级的证书匹配规则匹配，系统安全服务守护进程(SSSD)只使用其中一个规则。作为临时解决方案，请使用单个证书匹配规则，该规则 LDAP 过滤器由与 | （或）运算符串联的单独规则的过滤器组成。有关证书匹配规则的示例，请参阅 sss-certamp(5)man page。
(BZ#1447945)
当定义了多个域时，无法使用 auto_private_group = 混合创建专用组
如果定义了多个域，并且第一个域以外的任何域使用混合选项，则专用组无法通过选项 auto_private_group = 混合创建。如果隐式文件域与 sssd.conf' 文件中的 AD 或 LDAP 域一起定义，且未标记为"MPG_HYBRID ），那么 SSSD 无法为具有 uid=gid 的用户创建私有组，并且 AD 或 LDAP 中不存在具有此 gid 的组。
sssd_nss 响应程序仅检查第一个域中 auto_private_groups 选项的值。因此，在配置多个域的设置中，在 RHEL 8 中包括默认设置的设置中，选项 auto_private_group 无效。
要临时解决这个问题，请在 sssd .conf 的 sssd 部分中设置 enable_files_domain = false。因此，如果 enable_files_domain 选项被设置为 false，则 sssd 不会在活跃域列表的开头添加 id_provider=files 的域，因此不会出现这个程序错误。
(BZ#1754871)
python-ply 不兼容 FIPS
python-ply 软件包的 YACC 模块使用 MD5 哈希算法来生成 YACC 签名的指纹。但是，FIPS 模式会阻止使用 MD5，只有非安全上下文中才允许这样做。因此，python-ply 不兼容 FIPS。在 FIPS 模式中的系统中，对 ply.yacc.yacc（） 的所有调用都会失败，并显示错误消息：
"UnboundLocalError: local variable 'sig' referenced before assignment"
问题会影响 python-pycparser 和 python-cffi 的一些用例。要临时解决这个问题，修改 /usr/lib/python3.6/site-packages/ply/yacc.py 文件的第 2966 行，将 sig = md5（） 替换为 sig = md5(usedforsecurity=False)。因此，python -ply 可以在 FIPS 模式中使用。
6.7.14. Desktop
Wayland 会话的限制
在 Red Hat Enterprise Linux 8 中，GNOME 环境和 GNOME 显示管理器(GDM)使用 Wayland 作为默认会话类型，而不是 X11 会话，这些会话与之前的 RHEL 主要版本一起使用。
当前无法使用以下功能，或者在 Wayland 下无法正常工作：
- Wayland 不支持多GPU设置。
-
X11 配置实用程序（如
xrandr）因为处理、解决方案、轮转和布局的方法不同而无法在 Wayland 下工作。您可以使用 GNOME 设置配置显示功能。 - 屏幕记录和远程桌面需要应用程序来支持 Wayland 上的门户 API。某些传统应用程序不支持门户 API。
- Wayland 上不提供指针可访问性。
- 没有可用的剪贴板管理器。
Wayland 上的 GNOME Shell 忽略了大多数传统 X11 应用发布的键盘粒度。您可以使用
/org/gnome/mutter/wayland/xwayland-grab-access-rulesGSettings 键启用 X11 应用程序发布键盘 grabs。默认情况下，Wayland 上的 GNOME Shell 允许以下应用发布键盘 grabs：- GNOME Boxes
- vinagre
- Xephyr
-
virt-manager、virt-viewer和remote-viewer -
vncviewer
- 客户机虚拟机(VM)中的 Wayland 具有稳定性和性能问题。在虚拟机中运行时，RHEL 会自动回退到 X11 会话。
如果您从使用 X11 GNOME 会话的 RHEL 7 系统升级到 RHEL 8，您的系统将继续使用 X11。当以下图形驱动程序在使用时，系统还会自动回退到 X11 ：
- 专有 NVIDIA 驱动程序
-
cirrus驱动程序 -
mga驱动程序 -
一个速度驱动程序
您可以手动禁用 Wayland 的使用：
-
要在 GDM 中禁用 Wayland，请在
/etc/gdm/custom.conf文件中设置WaylandEnable=false选项。 - 要在 GNOME 会话中禁用 Wayland，请在输入登录名称后使用登录屏幕上的 cogwheel 菜单来选择旧的 X11 选项。
有关 Wayland 的详情，请参考 https://wayland.freedesktop.org/。
在桌面和应用程序间进行拖放操作无法正常工作
由于 gnome-shell-extensions 软件包中的一个 bug，drag-and-drop 功能目前在桌面和应用程序间无法正常工作。以后的发行版本中将重新添加对这个功能的支持。
无法从软件仓库中禁用 flatpak 程序库
目前，在 GNOME 软件工具中的软件程序库工具中无法禁用或删除 flatpak 程序库。
第二代 RHEL 8 虚拟机有时无法在 Hyper-V Server 2016 主机上引导
当使用 RHEL 8 作为在 Microsoft Hyper-V Server 2016 主机上运行的虚拟机(VM)中的客户机操作系统时，虚拟机在某些情况下无法引导，并返回到 GRUB 引导菜单。另外，会在 Hyper-V 事件日志中记录以下错误：
The guest operating system reported that it failed with the following error code: 0x1E
这个错误是由 Hyper-V 主机上的 UEFI 固件错误造成的。要临时解决这个问题,，使用 Hyper-V Server 2019 作为主机。
(BZ#1583445)
当使用软件渲染器时，Wayland 上的 GNOME Shell 的执行缓慢
使用软件渲染器时，GNOME Shell 作为 Wayland 合成器（Wayland 上的 GNOME Shell）不会使用缓存帧缓冲器来呈现屏幕。因此，Wayland 上的 GNOME Shell 速度较慢。要解决这个问题，请进入 GNOME 显示管理器(GDM)登录屏幕，切换到使用 X11 协议的 会话。因此，使用了使用可缓存内存的 Xorg 显示服务器，而 Xorg 上的 GNOME Shell 与 Wayland 上的 GNOME Shell 相比 运行更快。
(BZ#1737553)
系统崩溃可能会导致 fadump 配置丢失
在启用了固件辅助转储(fadump)且引导分区位于 XFS 等日志记录文件系统中的系统中会出现此问题。系统崩溃可能会导致引导装载程序加载未启用转储捕获支持的较早 initrd。因此，恢复后，系统不会捕获 vmcore 文件，这会导致 fadump 配置丢失。
要临时解决这个问题：
如果
/boot是一个独立的分区，请执行以下操作：- 重启 kdump 服务
以 root 用户身份运行以下命令，或使用具有 CAP_SYS_ADMIN 权限的用户帐户：
# fsfreeze -f # fsfreeze -u
-
如果
/boot不是单独的分区，请重启该系统。
(BZ#1723501)
当对 ldap_id_use_start_tls 选项使用默认值时，会有潜在的风险
当使用没有 TLS 的 ldap:// 进行身份查找时，可能会给攻击向量带来风险。特别是中间人(MITM)攻击，其使攻击者可以通过更改例如 LDAP 搜索中返回的对象的 UID 或 GID 来冒充用户。
目前，强制 TLS 的 SSSD 配置选项 ldap_id_use_start_tls 默认为 false。确保您的设置在可信环境中操作，并决定是否可以对 id_provider = ldap 使用未加密的通信。注意 id_provider = ad 和 id_provider = ipa 不受影响，因为它们使用 SASL 和 GSSAPI 保护的加密连接。
如果使用未加密的通信不安全，请在 /etc/sssd/sssd.conf 文件中将 ldap_id_use_start_tls 选项设置为 true 来强制使用 TLS。计划在以后的 RHEL 版本中更改的默认行为。
(JIRA:RHELPLAN-155168)
6.7.15. 图形基础结构
radeon 无法正确重置硬件
radeon 内核驱动程序目前没有在 kexec 上下文中正确重置硬件。相反，radeon 无法工作，从而导致剩余的 kdump 服务失败。
要临时解决这个问题，在 kdump 中通过在 /etc/kdump.conf 文件中添加以下行来使用 blacklis Trade on ：
dracut_args --omit-drivers "radeon" force_rebuild 1
重启机器和 kdump。启动 kdump 后，force_rebuild 1 行可能会从配置文件中删除 。
请注意，在这种情况下，kdump 不会提供图形，但 kdump 可成功运行。
(BZ#1694705)
6.7.16. Web 控制台
非特权用户可以访问订阅页面
如果非管理员导航到 Web 控制台的 Subscriptions 页面，Web 控制台会显示一个通用错误消息"Cockpit has a unexpected internal error"。
要临时解决这个问题，使用特权用户登录到 web 控制台，并选择 Reuse my password for privileged tasks 复选框。
6.7.17. 虚拟化
使用 cloud-init 在 Microsoft Azure 上置备虚拟机失败
目前，无法使用 cloud-init 工具在 Microsoft Azure 平台上置备 RHEL 8 虚拟机(VM)。要临时解决这个问题，请使用以下方法之一：
-
使用
WALinuxAgent软件包而不是cloud-init 在Microsoft Azure 上调配虚拟机。 在
/etc/NetworkManager/NetworkManager.conf文件中的[main]部分添加以下设置：[main] dhcp=dhclient
(BZ#1641190)
在某些情况下，RHEL 7 主机上的 RHEL 8 虚拟机无法在高于 1920x1200 的分辨率中查看
目前，当使用在 RHEL 7 主机系统中运行的 RHEL 8 虚拟机(VM)时，显示虚拟机图形输出的特定方法（如在 kiosk 模式下运行应用程序）不能超过 1920x1200。因此，使用这些方法显示虚拟机只能在 1920x1200 的解决方案中正常工作，即使主机硬件支持更高的分辨率。
(BZ#1635295)
Windows Server 2019 主机上的 RHEL 8 虚拟机中的低 GUI 显示性能
当在 Windows Server 2019 主机上以图形模式使用 RHEL 8 作为客户机操作系统时，GUI 显示性能较低，并连接到客户机的控制台输出所需的时间比预期的要长得多。
这是 Windows 2019 主机上的已知问题，并由 Microsoft 解决。要临时解决这个问题，请使用 SSH 连接到客户端，或使用 Windows Server 2016 作为主机。
(BZ#1706541)
安装 RHEL 虚拟机有时会失败
在某些情况下，如果使用 --location 选项，使用 virt-install 工具创建的 RHEL 7 和 RHEL 8 虚拟机将无法引导。
要临时解决这个问题，使用 --extra-args 选项并指定网络可访问的安装树，例如：
--extra-args="inst.repo=https://some/url/tree/path"
这样可确保 RHEL 安装程序正确找到安装文件。
(BZ#1677019)
无法通过 QXL 显示多个使用 Wayland 的虚拟机的监控器
使用 remote-viewer 工具来显示使用 Wayland 显示服务器的虚拟机(VM)的多个显示器，会导致 VM 变得无响应，并永久显示 Waiting for display 状态信息。
要临时解决这个问题，使用 virtio-gpu 而不是 qxl 作为使用 Wayland 的虚拟机的 GPU 设备。
(BZ#1642887)
virsh iface-\* 命令无法一致性地工作
因为配置的依赖关系，目前virsh iface-* 命令（如 virsh iface-start 和 virsh iface-destroy 会经常失败。因此，建议您不要使用 virsh iface-\* 命令配置和管理主机网络连接。反之，使用 NetworkManager 程序及其相关管理程序。
(BZ#1664592)
使用 cloud-init 自定义 ESXi 虚拟机并重启虚拟机会导致 IP 设置丢失，并导致引导虚拟机非常慢
目前，如果 cloud-init 服务用于修改在 VMware ESXi 管理程序上运行的虚拟机(VM)，以使用静态 IP，然后克隆虚拟机，则新的克隆虚拟机在某些情况下需要很长时间才能重新引导。这是因为 cloud-init 将虚拟机的静态 IP 重写为 DHCP，然后搜索可用的数据源。
要临时解决这个问题，您可以在虚拟机第一次引导后卸载 cloud-init。因此，后续重启不会减慢。
(BZ#1666961, BZ#1706482)
RHEL 8 虚拟机有时无法引导至 Witherspoon 主机
在某些情况下，使用 pseries-rhel7.6.0-sxxm 机器类型的 RHEL 8 虚拟机(VM)无法针对使用 DD2.2 或 DD2.3 CPU 的 HPC 主机（也称为 Witherspoon）在 Power9 S922LC 上启动。
尝试引导这样的虚拟机会生成以下出错信息：
qemu-kvm: Requested safe indirect branch capability level not supported by kvm
要临时解决这个问题，请按如下方式配置虚拟机的 XML 配置：
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<qemu:commandline>
<qemu:arg value='-machine'/>
<qemu:arg value='cap-ibs=workaround'/>
</qemu:commandline>IBM POWER 虚拟机无法在零内存 NUMA 节点中正常工作
目前，当在 RHEL 8 主机上运行的 IBM POWER 虚拟机(VM)配置为使用零内存(memory='0')的 NUMA 节点时，虚拟机将无法引导。因此，红帽强烈建议不要在 RHEL 8 中使用零内存 NUMA 节点的 IBM POWER 虚拟机。
(BZ#1651474)
将 POWER9 客户端从 RHEL 7-ALT 主机迁移到 RHEL 8 会失败
目前，将 POWER9 虚拟机从 RHEL 7-ALT 主机系统迁移到 RHEL 8 变得无响应，并带有 "Migration status: active" 状态。
要临时解决这个问题，在 RHEL 7-ALT 主机上禁用 Transparent Huge Pages（THP），这样可使迁移成功完成。
(BZ#1741436)
当在 AMD EPYC 上使用主机透传模式时，虚拟机不会检测到 SMT CPU 拓扑
当在 AMD EPYC 主机上使用 CPU 主机 passthrough 模式引导虚拟机(VM) 时，TOPOEXT CPU 功能标志不存在。因此，虚拟机无法检测到每个内核有多个线程的虚拟 CPU 拓扑。要临时解决这个问题，使用 EPYC CPU 模型而不是主机透传引导虚拟机。
当使用很多 virtio-blk 磁盘时，虚拟机有时无法启动
在虚拟机(VM)中添加大量 virtio-blk 设备可能会耗尽平台中可用的中断向量。如果发生了这种情况，VM 的客户机操作系统无法引导，并显示 dracut-initqueue[392]: Warning: Could not boot 错误。
