5.7. 已知问题

这部分论述了 Red Hat Enterprise Linux 8.2 中已知的问题。

5.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。

(BZ#1672405)

RHEL 8 初始设置无法通过 SSH 执行

目前，当使用 SSH 登录到系统时，RHEL 8 初始设置接口不会显示。因此，无法在通过 SSH 管理的 RHEL 8 机器上执行初始设置。要临时解决这个问题，请在主系统控制台(ttyS0)中执行初始设置，然后再使用 SSH 登录。

(BZ#1676439)

在安装程序中不默认启用网络访问

几个安装功能需要网络访问，例如：使用 Content Delivery Network(CDN)、NTP 服务器支持和网络安装源注册系统。但默认情况下不启用网络访问，因此在启用网络访问前无法使用这些功能。

要临时解决这个问题，请添加 ip=dhcp 在启动安装时启用网络访问。另外，使用引导选项传递 Kickstart 文件或位于网络中的库也会解决这个问题。因此可以使用基于网络的安装功能。

(BZ#1757877)

属于多个机构的用户帐户注册失败

目前，当试图使用属于多个机构的用户帐户注册系统时，注册过程会失败并显示出错信息, You must specify an organization for new units。

要临时解决这个问题，您可以：

  • 使用不属于多个机构的不同用户帐户。
  • 使用 GUI 和 Kickstart 安装的的 Connect to Red Hat 中的Activation Key 验证方法。
  • 跳过连接到红帽的注册步骤，并使用 Subscription Manager 在安装后注册您的系统。

(BZ#1822880)

在没有 CDN 注册的情况下，有时无法进行使用 Binary DVD ISO 镜像的 GUI 安装

当使用 Binary DVD ISO 镜像文件执行 GUI 安装时，安装程序的竞争条件有时可能会阻止安装进行，直到您使用连接到红帽功能注册系统。要临时解决这个问题，请完成以下步骤：

  1. 在 GUI 安装的 安装概述 窗口中选择 安装源。
  2. 验证是否选择了自动探测的安装介质。
  3. 点击 完成 确认选择并返回 安装概述 窗口。
  4. 验证 Local Media 在 Installation Summary 窗口中是否显示为 Installation Source 状态。

因此，您可以继续安装，而不必使用连接到红帽的功能注册系统。

(BZ#1823578)

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

如果在仓库刷新完成前尝试使用 CDN 取消注册，则 GUI 安装可能会失败

在 RHEL 8.2 中，当使用 Content Delivery Network(CDN)注册您的系统并附加订阅时，GUI 安装程序会启动对仓库元数据的刷新。刷新过程不是注册和订阅过程的一部分，因此在 Connect to Red Hat 窗口中启用了 Unregister 按钮。根据网络连接，刷新过程可能需要一分钟以上的时间完成。如果您在刷新过程完成前点 Unregister 按钮，则 GUI 安装可能会失败，因为未注册过程会删除 CDN 仓库文件和安装程序与 CDN 通信所需的证书。

要临时解决这个问题，点 连接到红帽 窗口中的 Register 按钮后在 GUI 安装中完成以下步骤：

  1. 在 连接到红帽的 窗口中点 完成 返回 安装概述 窗口。
  2. 在 安装概述 窗口中验证 安装源 和 软件选择状态 信息是否以斜体显示任何处理信息。
  3. 当安装源和软件选择类别准备好后，点 连接到红帽。
  4. 点 Unregister 按钮。

执行这些步骤后，您可以在 GUI 安装过程中安全地取消注册系统。

(BZ#1821192)

5.7.2. 订阅管理

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)

使用 Kickstart 文件安装 RHEL 时，多路径存储设备中的数据会丢失

使用 Kickstart 文件安装 RHEL 时，附加到主机的多路径存储设备中的数据会丢失。出现这个问题的原因是，安装程序无法忽略您使用 ignoredisk --drives 命令指定的多路径存储设备。因此，设备中的数据会丢失。

要临时解决这个问题，请在安装前分离设备，或使用 ignoredisk --only-use 命令指定设备进行安装。

(BZ#1862131)

5.7.3. Shell 和命令行工具

使用 Wayland 协议的应用无法转发到远程显示服务器

在 Red Hat Enterprise Linux 8 中，大多数应用程序默认使用 Wayland 协议，而不是 X11 协议。因此，ssh 服务器无法转发使用 Wayland 协议的应用，但能够将使用 X11 协议的应用转发到远程显示服务器。

要临时解决这个问题，请在启动应用程序前设置环境变量 GDK_BACKEND=x11。因此，可以将应用转发到远程显示服务器。

(BZ#1686892)

systemd-resolved.service 无法在引导时启动

systemd-resolved 服务偶尔无法在引导时启动。如果发生这种情况，请在引导完成后手动重启该服务： 

# systemctl start systemd-resolved

但是，在引导时 解析 systemd 失败不会影响任何其他服务。

(BZ#1640802)

5.7.4. 安全性

可执行审核监控在符号链接上无法正常工作

由 -w 选项提供的文件监控无法直接跟踪路径。它需要解析到设备的路径以及内节点，才能与已执行程序进行比较。监控可执行符号链接的观察监控将监控设备和符号链接本身的索引节点，而不是内存中执行的程序，这些程序可从符号链接的解析中找到。即使监视解析了符号链接以获取生成的可执行程序，规则也会对从不同符号链接调用的多调用二进制文件触发。这会导致大量日志带有假的正状态。因此，可执行的审计监控符号链接无法正常工作。

要临时解决这个问题，请为可执行程序的解析路径设置一个监视，并使用 comm= 或 proctitle= 字段中列出的最后一个组件过滤生成的日志消息。

(BZ#1846345)

/etc/selinux/config 中的SELINUX=disabled 无法正常工作

在 /etc/selinux/config 中使用 SELINUX=disabled 选项禁用 SELinux 会导致内核在启用了 SELinux 的情况下引导，并在稍后的引导过程中切换到禁用模式。这可能导致内存泄漏。

要临时解决这个问题，请在内核命令行中添加 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 策略。

(BZ#1763210)

删除 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。

要临时解决这个问题：

  1. 输入 umount /sys/fs/selinux/ 命令。
  2. 手动安装缺少的 selinux-policy-targeted 软件包。
  3. 编辑 /etc/selinux/config 文件以便策略等同于 SELINUX=enforcing。
  4. 输入命令 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)

SELinux 会阻止 auditd 停止或关闭系统

SELinux 策略不包含允许 Audit 守护进程启动 power_unit_file_t systemd 单元的规则。因此，在日志记录磁盘分区没有剩余空间的情况下，audit d 也无法停止或关闭系统。

要临时解决这个问题，请创建自定义 SELinux 策略模块。因此，只有应用了临时解决方案，audit d 才可以正确地停止或关闭系统。

(BZ#1826788)

锁定用户可以运行 sudo 命令

在使用 ALL 关键字定义 sudoers 权限的系统中，拥有 权限的 sudo 用户可以作为帐户被锁定的用户运行 sudo 命令。因此，仍然可以使用锁定的和过期的帐号来执行命令。

要临时解决这个问题，请启用新实现的 runas_check_shell 选项，并在 /etc/shells 中正确设置有效 shell。这样可防止攻击者在比如 bin 的系统帐户中运行命令。

(BZ#1786990)

默认日志设置在性能上的负面影响

默认日志环境设置可能会消耗 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

因此，当前的配置必须仅限于可正常工作的字符串。

(BZ#1679512)

到带有 SHA-1 签名的服务器的连接无法使用 GnuTLS

GnuTLS 安全通讯库以 insecure 形式拒绝 SHA-1 证书签名。因此，使用 GnuTLS 作为 TLS 后端的应用程序无法建立与提供此类证书的对等的 TLS 连接。这个行为与其他系统加密库不一致。要临时解决这个问题，请升级服务器以使用 SHA-256 或更强大的哈希签名的证书，或切换到 LEGACY 策略。

(BZ#1628553)

在 FIPS 模式下，TLS 1.3 无法在 NSS 中工作

在使用 FIPS 模式的系统中不支持 TLS 1.3。因此，需要 TLS 1.3 进行互操作性的连接无法在 FIPS 模下工作的系统上正常工作。

要启用连接，请禁用系统的 FIPS 模式，或者启用对 peer 中 TLS 1.2 的支持。

(BZ#1724250)

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 连接。

(BZ#1685470)

OpenSSL 在 TLS 1.3 中的 CertificateRequest 消息中生成一个不正确的 status_request 扩展

如果启用了 status_request 扩展和基于客户端证书的身份验证，OpenSSL 服务器会在 CertificateRequest 消息中发送错误的 status_request 扩展。在这种情况下，OpenSSL 无法与 RFC 8446 协议兼容的实施互操作。因此，正确验证 CertificateRequest 消息中的扩展的客户端会中止与 OpenSSL 服务器的连接。要临时解决这个问题，在连接两侧禁用对 TLS 1.3 协议的支持，或者禁用对 OpenSSL 服务器上的 status_request 的支持。这将阻止服务器发送错误的消息。

(BZ#1749068)

ssh-keyscan 无法在 FIPS 模式中检索服务器的 RSA 密钥

在 FIPS 模式中的 RSA 签名禁用了 SHA-1 算法，这样可防止 ssh-keyscan 工具程序获取在那个模式下运行的服务器的 RSA 密钥。

要临时解决这个问题，使用 ECDSA 密钥，或者使用服务器中的 /etc/ssh/ssh_host_rsa_key.pub 文件在本地检索密钥。

(BZ#1744108)

Libreswan 在所有配置中使用 seccomp=enabled 无法正常工作

Libreswan SECCOMP 支持实施中的允许系统调用集合目前还不完整。因此，当 ipsec.conf 文件中启用 SECCOMP 时，syscall 过滤也会拒绝 pluto 守护进程正常工作所需的 syscalls；守护进程已被终止，ipsec 服务重启。

要临时解决这个问题，将 seccomp= 选项设置回 disabled 状态。为了正确运行 ipsec，SECCOMP 支持必须保持禁用状态。

(BZ#1777474)

某些 SSG 中的规则组可能会失败

由于规则及其依赖项未定义，在基准中修复 SCAP 安全指南 (SSG)规则可能会失败。如果需要以特定顺序执行两个或多个规则，例如，当一条规则安装组件和另一个规则配置同一组件时，它们可按错误的顺序运行，并报告错误。要临时解决这个问题，请执行补救两次，第二次运行会修复依赖规则。

(BZ#1750755)

SCAP Workbench 无法从定制的配置集生成基于结果的补救方法

当尝试使用SCAP Workbench 工具从自定义配置集生成基于结果的补救角色时，会出现以下错误： 

Error generating remediation role .../remediation.sh: Exit code of oscap was 1: [output truncated]

要临时解决这个问题，请使用带有 --tailoring-file 选项的 oscap 命令。

(BZ#1640715)

Kickstart 在 RHEL 8 中使用 org_fedora_oscap 而不是 com_redhat_oscap

Kickstart 将 Open Security Content Automation Protocol(OSCAP)Anaconda 附加组件作为 org_fedora_oscap 而不是 com_redhat_oscap 来 引用，这可能会导致混淆。这样做可以保持与 Red Hat Enterprise Linux 7 的向后兼容性。

(BZ#1665082)

OSCAP Anaconda Addon 不会在文本模式中安装所有软件包

如果安装以文本模式运行，则 OSCAP Anaconda Addon 插件无法修改为系统安装程序安装而选择的软件包列表。因此，当使用 Kickstart 指定安全策略配置集且安装以文本模式运行时，安全策略所需的附加软件包不会在安装过程中安装。

要临时解决这个问题，可以使用图形模式运行安装，或者在 Kickstart 文件的 %packages 部分指定安全策略配置集所需的所有软件包。

因此，在没有描述的一个临时解决方案的情况下，安全策略配置集所需的软件包不会在 RHEL 安装过程中安装，且安装的系统与给定的安全策略配置集不兼容。

(BZ#1674001)

OSCAP Anaconda Addon 组件无法正确处理自定义配置集

OSCAP Anaconda Addon 插件无法以独立文件中自定义的方式正确处理安全配置集。因此，即使您在对应的 Kickstart 部分正确指定了自定义配置集，RHEL 图形安装中也不会提供自定义配置集。

要临时解决这个问题，请遵循 从原始 DS 创建单一 SCAP 数据流中的说明,以及一个定制文件 知识库文章。因此，您可以在 RHEL 图形安装中使用自定义的 SCAP 配置集。

(BZ#1691305)

gnutls 无法恢复使用 NSS 服务器的当前会话

当恢复 TLS（传输层安全）1.3 会话时，GnuTLS 客户端会等待 60 毫秒，加上服务器发送会话恢复数据的预计往返时间。如果服务器没有在此时间内发送恢复数据，客户端会创建一个新的会话，而不是恢复当前会话。这不会造成严重的负面影响，只会对常规会话协商的性能有小的影响。

(BZ#1677754)

当使用 --sudo 扫描远程系统时，oscap-ssh 工具会失败

在使用带 --sudo 选项的 oscap-ssh 工具对远程系统执行安全内容自动化协议(SCAP)扫描时，远程系统上的 oscap 工具将扫描结果文件保存并报告到一个临时目录中，以 root 用户身份将文件报告到一个临时目录中。如果远程计算机上的 umask 设置已被更改，oscap-ssh 可能无法访问这些文件。要临时解决这个问题，请修改 oscap-ssh 工具，如本解决方案 "oscap-ssh --sudo" 错误所述，检索 "scp: …​: Permission denied" 错误的结果文件。因此，oscap 会以目标用户身份保存文件，oscap-ssh 会 正常访问这些文件。

(BZ#1803116)

OpenSCAP 会在从 YAML 多行字符串中删除空白行时生成假的正数

当 OpenSCAP 从 datastream 中生成 Ansible 修复时，它会从 YAML 多行字符串中删除空白行。由于某些 Ansible 修复包含字面配置文件内容，因此删除空行会影响对应的修复。这会导致 openscap 实用程序无法进行相应的 Open Vulnerability 和评估语言(OVAL)检查，即使空白行没有任何作用。要临时解决这个问题，请检查规则描述并跳过因为缺少空白行而失败的扫描结果。或者，使用 Bash 修复而不是 Ansible 修复，因为 Bash 修复不会生成这些假的正结果。

(BZ#1795563)

基于 OSPP 的配置集与 GUI 软件包组不兼容。

服务器安装的 GUI 软件包组的GNOME 软件包需要 nfs-utils 软件包，该软件包与操作系统保护配置集(OSPP)不兼容。因此，在安装带有 OSPP 或 OSPP 配置集的系统（例如安全技术实施指南(STIG)）的过程中，选择 Server with GUI 软件包组。如果在安装后应用了基于 OSPP 的配置集，则系统将无法引导。要临时解决这个问题,请不要在使用 OSPP 配置集和基于 OSPP 的配置集时使用 Server with GUI 或者其它安装 GUI 的组。在使用 Server 或 Minimal Install 软件包组时，系统不会有任何问题并可正常工作。

(BZ#1787156)

无法使用 e8 配置集修复 Server with Server with GUI 软件包组的 RHEL8 系统

使用 OpenSCAP Anaconda 附加组件强化 Server with GUI 软件包组上的系统，带配置文件（从 Verify Integrity with RPM 组中选择规则）需要系统中的超大 RAM。这个问题是由 OpenSCAP 扫描程序造成的。如需更多详情，请参阅 扫描大量使用 OpenSCAP 的文件,从而导致系统运行内存不足。因此，使用 RHEL8 Essential Eight(e8)配置集强化系统将无法成功。要临时解决这个问题，请选择一个较小的软件包组，如 Server，并在安装后安装您需要的附加软件包。因此，该系统会使用较少的软件包，扫描需要较少的内存，因此可自动强化该系统。

(BZ#1816199)

使用 OpenSCAP 扫描大量文件会导致系统内存不足

OpenSCAP 扫描程序将所有收集的结果存储在内存中，直到扫描完成为止。因此,系统在扫描大量文件时，比如从大软件包组 Server with GUI 和 Workstation 中进行扫描时，系统可能会出现系统没有足够的问题。要临时解决这个问题，在内存较小的系统中，使用较小的软件包组，如 Server 和 Minimal Install。如果您需要使用大的软件包组，测试您的系统在虚拟或临时环境中是否有足够内存。或者，您可以将扫描配置集定制为取消选择涉及整个 / 文件系统递归的规则：

  • rpm_verify_hashes
  • rpm_verify_permissions
  • rpm_verify_ownership
  • file_permissions_unauthorized_world_writable
  • no_files_unowned_by_user
  • dir_perms_world_writable_system_owned
  • file_permissions_unauthorized_suid
  • file_permissions_unauthorized_sgid
  • file_permissions_ungroupowned
  • dir_perms_world_writable_sticky_bits

这可防止 OpenSCAP 扫描造成系统内存不足。

(BZ#1824152)

5.7.5. 网络

当禁用 GRO 时，IPsec 网络流量在 IPsec 卸载过程中失败

当在该设备中禁用通用接收 Offload（GRO）时，IPsec 卸载将不会正常工作。如果在一个网络接口中配置了 IPsec 卸载，且在该设备中禁用 GRO，IPsec 网络流量会失败。

要临时解决这个问题，在该设备中启用 GRO。

(BZ#1649647)

如果指定链类型未知，则 iptables 不会为更新链的命令请求模块加载

注意：如果您使用服务默认配置，则此问题会在停止 iptables systemd 服务时导致无功能隐患的错误。

当使用 iptables-nft 设置链策略时，发送到内核的更新链命令将失败（如果尚未加载相关的内核模块）。要临时解决这个问题，请使用以下命令使模块载入：

+ 

# iptables -t nat -n -L
# iptables -t mangle -n -L

(BZ#1812666)

nft_compat 模块自动加载特定于地址系列的 LOG 后端模块可能会挂起

当 nft_compat 模块 同时 加载网络命名空间(netns)上的操作时，可能会发生锁定冲突。因此，载入特定于地址的 LOG 目标后端可能会挂起。要临时解决这个问题，请在执行 iptables-restore 工具之前手动加载相关的 LOG 目标后端，如 nf_log_ipv4.ko 和 nf_log_ipv6.ko。因此，载入 LOG 目标后端不会挂起。但是，如果在系统引导过程中出现问题，则没有可用的临时解决方案。

请注意，libvirt d 等其他服务也执行 iptables 命令，这可能会导致问题发生。

(BZ#1757933)

5.7.6. 内核

意外删除补丁会导致 huge_page_setup_helper.py 显示错误

更新 huge_page_setup_helper.py 脚本的补丁被意外删除。因此，执行 huge_page_setup_helper.py 脚本后会出现以下出错信息： 

SyntaxError: Missing parentheses in call to 'print'

要临时解决这个问题，从 RHEL 8.1 中复制 huge_page_setup_helper.py 脚本并将其安装到 /usr/bin/ 目录中：

  1. 从 RHEL-8.1.0 安装介质或从 红帽客户门户网站 下载 libhugetlbfs-utils-2.21-3.el8.x86_64.rpm 软件包。

  2. 执行 rpm2cpio 命令： 

    # rpm2cpio libhugetlbfs-utils-2.21-3.el8.x86_64.rpm | cpio -D / -iduv '*/huge_page_setup_helper.py'

    该命令从 RHEL 8.1 RPM 中提取 huge_page_setup_helper.py 脚本并将其保存到 /usr/bin/ 目录中。

因此，huge_page_setup_helper.py 脚本可以正常工作。

(BZ#1823398)

有大量持久内存的系统在引导过程中出现延迟

有大量持久内存的系统需要很长时间才能引导，因为初始化内存是序列化的。因此，如果 /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)

Debug 内核无法在 RHEL 8 的崩溃捕获环境中引导

由于 debug 内核的内存需求特性，会在使用 debug 内核并触发内核 panic 时出现问题。因此，调试内核无法作为捕获内核引导，而是生成一个堆栈追踪。要临时解决这个问题，相应地增大崩溃内核内存。因此，debug 内核可以在崩溃捕获环境中成功引导。

(BZ#1659609)

zlib 可能会在某些压缩功能中减慢 vmcore 捕获速度

kdump 配置文件默认使用 lzo 压缩格式（makedumpfile -l）。当您修改使用 zlib 压缩格式（makedumpfile -c）的配置文件时，可能会带来更好的压缩效果，但会牺牲 vmcore 捕获过程的速度。因此，与 lzo 相比，捕获有 zlib 的 vmcore 文件所需的时间最多可能比使用 kdump 要长四倍。

因此，如果速度对您非常重要，红帽推荐使用默认的 lzo。但是，如果目标机器在可用空间中较低， zlib 就是一个更好的选项。

(BZ#1790635)

在内存热插拔或拔出操作后，vmcore 捕获失败

执行内存 hot-plug 或 hot-unplug 操作后，会更新包含内存布局信息的设备树。因此，makedumpfile 实用程序会尝试访问不存在的物理地址。如果以下条件都满足，就会出现问题：

  • IBM Power System 的 little-endian 变体运行 RHEL 8。
  • 在系统中启用了 kdump 或者 fadump 服务。

因此，如果在内存 hot-plug 或 hot-unplug 操作后触发了内核崩溃，捕获内核将无法保存 vmcore。

要临时解决这个问题，在 hot-plug 或 hot-unplug 后重启 kdump 服务： 

# systemctl restart kdump.service

因此，vmcore 在上述场景中被成功保存。

(BZ#1793389)

fadump 转储机制将网络接口重命名为 kdump-<interface-name>

当使用固件辅助转储(fadump)捕获 vmcore 并使用 SSH 或 NFS 协议将其保存到远程机器时，请将网络接口重命名为 kdump-<interface-name>。当 <interface-name> 为通用时（如 *eth# 或 net# 等等）进行重命名。这是因为初始 RAM 磁盘(initrd)中的 vmcore 捕获脚本在网络接口名称中添加 kdump- 前缀来保护持久性命名。由于同一 initrd 也用于常规启动，因此生产内核的接口名称也会更改。

(BZ#1745507)

启用 fadump 时，系统在引导时进入紧急模式

当 initramfs 方案中启用了 fadump( kdump)or dracut squash 模块时，系统进入紧急模式，因为 systemd Manager 无法获取挂载信息并将 LV 分区配置为挂载。要临时解决这个问题，请添加以下内核命令行参数 rd.lvm.lv=<VG>/<LV> 以正确发现并挂载失败的 LV 分区。因此，系统将在上述场景中成功引导。

(BZ#1750278)

使用 irqpoll 会导致 vmcore 生成失败

由于在 Amazon Web Services(AWS)云平台上运行的 64 位 ARM 架构中的 nvme 驱动程序存在问题，在第一个内核提供了 irqpoll 内核命令行参数时 vmcore 生成会失败。因此，在内核崩溃后，/var/crash/ 目录中不会转储 vmcore 文件。要临时解决这个问题：

  1. 在 /etc/sysconfig/kdump 文件的 KDUMP_COMMANDLINE_REMOVE 键里添加 irqpoll。
  2. 运行 systemctl restart kdump 命令重启 kdump 服务。

因此，第一个内核会正确引导，在内核崩溃时可以捕获 vmcore 文件。

请注意，kdump 服务可能会使用大量崩溃内核内存转储 vmcore 文件。确定捕获内核有足够的内存可用于 kdump 服务。

(BZ#1654962)

使用 vPMEM 内存作为转储目标会延迟内核崩溃捕获过程

当您将 Virtual Persistent Memory(vPEM)命名空间用作 kdump 或 fadump 目标时，papr_scm 模块必须取消 map 并重新 map 由 vPMEM 支持的内存，并将内存重新添加到其线性映射中。因此，这个行为会向 POWER Hypervisor(HCalls)触发 Hypervisor(HCalls)，从而大大缩短捕获内核引导的速度。因此，建议您不要将 vPMEM 命名空间用作 kdump 或 fadump 的转储目标。

如果您必须使用 vPMEM，要解决这个问题请执行以下命令：

  1. 创建 /etc/dracut.conf.d/99-pmem-workaround.conf 文件并添加： 

    add_drivers+="nd_pmem nd_btt libnvdimm papr_scm"

  2. 重建初始 RAM 磁盘(initrd)文件系统： 

    # touch /etc/kdump.conf
# systemctl restart kdump.service

(BZ#1792125)

HP NMI 监视器并不总是生成崩溃转储

在某些情况下，HP NMI watchdog 的 hpwdt 驱动无法声明一个由 HPE watchdog timer 生成的不可屏蔽中断（NMI），因为 NMI 被 perfmon 驱动所消耗。

缺少的 NMI 是由以下两个条件之一引发的：

  1. Integrated Lights-Out (iLO) 服务器管理软件中的 Generate NMI 按钮。这个按钮由用户触发。
  2. hpwdt watchdog。默认过期会向服务器发送一个 NMI。

在系统无响应时通常会出现这两个序列。在一般情况下，用于这两种情况的 NMI 处理程序调用 kernel panic() 功能，如果配置了, kdump 服务会生成 vmcore 文件。

由于缺少 NMI，没有调用 kernel panic() 且不收集 vmcore。

第一种情况(1.)，如果系统不响应，它会一直处于这个状态。要临时解决这种情况，请使用虚拟 Power 按钮来重置或者启用服务器。

在第二个示例中（2.），缺少的 NMI 之后会在 9 秒后被自动系统恢复（ASR）重置。

HPE Gen9 服务器行以单位数字显示这个问题。Gen10 频率更小。

(BZ#1602962)

tuned-adm profile powerave 命令会导致系统变得无响应

执行 tuned-adm 配置集 powersave 命令会导致 Penguin Valkyrie 2000 2-socket 系统具有较旧 Thunderx(CN88x)处理器的无响应状态。因此，需要重启系统以便恢复工作。要临时解决这个问题，如果您的系统符合上述说明，请避免使用 powersave 配置集。

(BZ#1609288)

cxgb4 驱动会导致 kdump 内核崩溃

在 vmcore 文件中保存信息时 kdump 内核会崩溃。因此，cxgb4 驱动程序可防止 kdump 内核保存内核以便稍后进行分析。要临时解决这个问题，在 kdump 内核命令行中添加 novmcoredd 参数以便保存核心文件。

(BZ#1708456)

尝试将 ICE 驱动程序 NIC 端口添加到模式 5(balance-tlb)绑定 master 接口可能会导致失败

尝试将 ICE 驱动程序 NIC 端口添加到模式 5(balance-tlb)绑定 master 接口可能会导致失败，并显示 Master 'bond0', Slave 'ens1f0': Error: Enslave failed。因此，您会出现将 NIC 端口添加到绑定 master 接口的间歇性失败的情况。要解决这个问题，请尝试重试添加接口。

(BZ#1791664)

将虚拟功能附加到接口 type='hostdev' 可能会有时失败

使用 .XML 文件将虚拟功能(VF)附加到虚拟机时，可能会按照 带有 <interface type='hostdev'> 方法的 Assignment 方法失败。这是因为，使用带有 <interface type='hostdev'> 方法的 Assignment 可以防止虚拟机附加到显示在此虚拟机的 VF NIC 中。要解决这个问题，请使用 Assignment with <hostdev> 方法使用 .XML 文件将 VF 附加到虚拟机。因此，vir sh attach-device 命令可以 成功且没有错误。有关 Assignment with <hostdev> 和 Assignment with <interface type='hostdev'>（仅限 SRIOV 设备）之间区别的详情，请参阅 主机网络设备的 PCI Passthrough。

(BZ#1792691)

5.7.7. 文件系统和存储

无法将 /boot 文件系统放在 LVM 中

您不能将 /boot 文件系统放在 LVM 逻辑卷中。这种限制的原因如下：

  • 在 EFI 系统中，EFI 系统分区 通常充当 /boot 文件系统。uEFI 标准要求有特定的 GPT 分区类型和具体文件系统类型。
  • RHEL 8 在系统引导条目中使用 Boot Loader 规格 (BLS)。这个规格要求 /boot 文件系统可由平台固件可读。在 EFI 系统中，平台固件只能读取 uEFI 标准定义的 /boot 配置。
  • 在 GRUB 2 引导装载程序中不支持 LVM 逻辑卷。红帽没有计划进行改进，因为如 uEFI 和 BLS 的标准，这个功能的使用情况正在下降。

红帽不计划在 LVM 中支持 /boot。反之，红帽提供了管理系统快照和回滚的工具，这些工具不需要将 /boot 文件系统放在 LVM 逻辑卷中。

(BZ#1496229)

LVM 不再允许使用混合块大小创建卷组

LVM 工具（如 vgcreate 或 vgextend）不再允许您创建有不同逻辑块大小的物理卷（PV）的卷组(VG)。LVM 启用了这个更改，因为如果您使用不同块大小的 PV 扩展了基本逻辑卷（LV），文件系统将无法挂载。

要重新创建带有混合块大小的 VG，在 lvm.conf 文件中设置 allow_mixed_block_sizes=1 选项。

(BZ#1768536)

当连接太多 LUN 时，DM 多路径可能无法启动

如果太多逻辑单元(LUN)连接到系统，multipathd 服务可能会超时且无法启动。造成此问题的确切 LUN 数量取决于多个因素，包括设备数量、存储阵列的响应时间、内存和 CPU 配置以及系统负载。

要临时解决这个问题，在 multipathd 单元文件中增加超时值：

  1. 在单元编辑器中打开 multipathd 单元： 

    # systemctl edit multipathd

  2. 输入以下配置来覆盖超时值： 

    [Service]
TimeoutSec=300

    红帽建议将默认值从默认值 90 增加到 300，但您也可以测试 90 以上的其他值。

  3. 在编辑器中保存文件。

  4. 重新载入 systemd 单元以应用更改： 

    # systemctl daemon-reload

现在，multipathd 可以从更多 LUN 成功启动。

(BZ#1797660)

LVM writecache 的限制

writecache LVM 缓存方法有以下限制，这些限制不会出现在 cache 方法中：

  • 当逻辑卷使用 writecache 时，您无法为逻辑卷生成快照。
  • 当逻辑卷处于活跃状态时，您无法附加或分离 writecache。

  • 将 writecache 附加到不活跃的逻辑卷时，您必须使用与现有文件系统块大小匹配的 writecache 块大小。

    详情请查看 lvmcache(7) man page。

  • 您不能在附加 writecache 时调整逻辑卷的大小。
  • 您不能对与 writecache 一起使用的设备使用 pvmove 命令。
  • 您不能将带有 writecache 的逻辑卷与精简池或 VDO 结合使用。

（JIRA:RHELPLAN-27987、BZ#1798631、BZ#1808012）

保存一个 LUKS 卷的 LVM mirror 设备有时将变为无响应

在某些情况下，保存 LUKS 卷的片段类型的 mirror LVM 设备可能会变得无响应。无响应设备会拒绝所有 I/O 操作。

要解决这个问题，红帽建议在有弹性软件定义的存储之上使用带 raid1 的片段类型的 LVM RAID 1 设备而不是镜像( mirror )。

raid1 segment 类型是默认的 RAID 配置类型，它作为推荐的解决方案替换 mirror。

要将 mirror 设备转换为 raid，请参阅 将镜像 LVM 设备转换为 RAID1 逻辑卷。

(BZ#1730502)

NFS 4.0 补丁可能会导致 open-heavy 工作负载性能降低。

在以前的版本中，存在一个程序错误，在某些情况下，可能会导致 NFS 打开操作覆盖文件已被删除或重命名在服务器中的事实。但是，这个修复可能会在需要很多打开操作的工作负载中造成性能下降。要临时解决这个问题，您可能需要使用 NFS 版本 4.1 或更高版本，这些版本已被改进为客户端在本地、快速和安全地执行开放操作。

(BZ#1748451)

5.7.8. 动态编程语言、网页和数据库服务器

当有 32 位应用程序调用 getpwnam() 时，可能会失败

当 NIS 用户使用32 位应用程序调用 getpwnam() 函数时，如果没有 nss_nis.i686 软件包，则调用会失败。要临时解决这个问题，使用 yum install nss_nis.i686 手动安装缺少的软件包。

(BZ#1803161)

nginx 无法从硬件安全令牌加载服务器证书

nginx web 服务器支持直接从 PKCS#11 模块的硬件安全令牌加载 TLS 私钥。但是，目前无法通过 PKCS#11 URI 从硬件安全令牌加载服务器证书。要临时解决这个问题，在文件系统中存储服务器证书

(BZ#1668717)

当使用 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 流。

(BZ#1670386)

作为依赖项安装时，mod _wsgi 软件包名称缺失

随着 mod_wsgi 安装中的更改（如 BZ#1779705 所述），python3-mod_wsgi 软件包不再提供名称 mod_wsgi。安装 mod_wsgi 模块时，您必须指定完整的软件包名称。此更改会导致第三方软件包依赖项出现问题。

如果您尝试安装需要名为 mod_wsgi 的依赖项的第三方软件包，则会返回类似如下的错误： 

Error:
 Problem: conflicting requests
  - nothing provides mod_wsgi needed by package-requires-mod_wsgi.el8.noarch

要临时解决这个问题，请选择以下之一：

  1. 重新构建软件包（或向第三方供应商询问新构建），以要求完整软件包名称 python3-mod_wsgi。

  2. 创建一个带有缺失软件包名称的 meta 软件包：

    1. 构建自己的空 meta 软件包，它提供名称 mod_wsgi。
    2. 将 module_hotfixes=True 行添加到包含 meta 软件包的存储库的 .repo 配置文件。
    3. 手动安装 python3-mod_wsgi。

(BZ#1829692)

5.7.9. 编译器和开发工具

GCC confuse SystemTap 生成的复合功能

GCC 优化可以为其他函数的部分内嵌副本生成复合函数。SystemTap 和 GDB 等工具无法将这些复合功能与实际功能区分开来。因此，SystemTap 将探测放置在复合和实际函数入口点上，因此为单个实际函数调用注册多个探测命中。

要临时解决这个问题，修改 SystemTap 脚本以检测递归并防止放置与内联部分功能相关的探测。

这个示例脚本 

probe kernel.function("can_nice").call { }

可以通过这种方式修改： 

global in_can_nice%

probe kernel.function("can_nice").call {
  in_can_nice[tid()] ++;
  if (in_can_nice[tid()] > 1) { next }
  /* code for real probe handler */
}

probe kernel.function("can_nice").return {
  in_can_nice[tid()] --;
}

请注意，这个示例脚本不会考虑所有可能的情况，如错过的 kprobes 或 kretprobes 或真正的预期递归。

(BZ#1169184)

5.7.10. Identity Management

更改 /etc/nsswitch.conf 需要手动重启系统

对 /etc/nsswitch.conf 文件的任何更改（例如运行 authselect select profile_id 命令）都需要重启系统，以便所有相关进程使用更新版本的 /etc/nsswitch.conf 文件。如果无法重新启动系统，请重新启动将您的系统加入 Active Directory 的服务，即 系统安全服务后台程序 (SSSD)或 winbind。

(BZ#1657295)

启用 文件 域时，SSSD 为本地用户返回不正确的 LDAP 组成员资格

如果系统安全服务守护进程(SSSD)从本地文件和 ldap_rfc2307_fallback_to_local_users 属性的 sssd.conf 文件的 [domain/LDAP] 部分为用户提供服务，则文件提供程序不包含来自其他域的组成员资格。因此，如果本地用户是 LDAP 组的成员，id local_user 命令不会返回用户的 LDAP 组成员资格。要临时解决这个问题，请通过添加 来禁用隐式 文件 域 

enable_files_domain=False

到 /etc/sssd/sssd.conf 文件中的 [sssd] 部分：

因此，id local_user 会为本地用户返回正确的 LDAP 组成员资格。

(BZ#1652562)

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 且具有此 gid 的组在 AD 或 LDAP 中创建私有组。

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 模式中使用。

(BZ#1747490)

FreeRADIUS 会默默地截断大于 249 个字符的 Tunnel-Password

如果 Tunnel-Password 大于 249 个字符，则 FreeRADIUS 服务会默默地截断它。这可能导致无法预期的，与其它系统不兼容的密码。

要临时解决这个问题，请选择 249 个字符或更少的密码。

(BZ#1723362)

如果所有 KRA 成员都是隐藏的副本，则安装 KRA 会失败

如果在隐藏的副本中安装第一个 KRA 实例，ip a-kra-install 工具程序会在已存在密钥恢复授权(KRA)的集群中失败。因此，您无法向集群添加更多 KRA 实例。

要临时解决这个问题，请在添加新的 KRA 实例前，清除具有 KRA 角色的隐藏副本。ipa-kra-install 成功完成后您可以再次隐藏它。

(BZ#1816784)

如果在搜索过滤器中使用了这些属性，目录服务器会警告 schema 中缺少的属性

如果您将 then sslapd-verify-filter-schema 参数设置为 warn-invalid，Directory Server 将处理搜索操作（带有架构中未定义的属性），并记录警告。使用这个设置时，Directory 服务器会在搜索结果中返回请求的属性，无论这些属性是否在架构中定义。

目录服务器的未来版本将更改默认设置 nsslapd-verify-filter-schema 来强制进行更严格的检查。新默认值将针对架构中缺少的属性发出警告，并且拒绝请求或仅返回部分结果。

(BZ#1790259)

ipa-healthcheck-0.4 没有过时的 ipa-healthcheck的旧版本

Healthcheck 工具已分成两个子软件包：ipa -healthcheck 和 ipa-healthcheck-core。但是，只有 ipa-healthcheck-core 子软件包被正确设置为过时的 ipa-healthcheck 版本。因此，更新 Healthcheck 只会安装 ipa-healthcheck-core，ipa-healthcheck 命令在更新后无法正常工作。

要临时解决这个问题，使用 yum install ipa-healthcheck-0.4 手动安装 ipa-healthcheck-0.4 子软件包。

(BZ#1852244)

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

5.7.11. Desktop

Wayland 会话的限制

在 Red Hat Enterprise Linux 8 中，GNOME 环境和 GNOME 显示管理器(GDM)使用 Wayland 作为默认会话类型，而不是 X11 会话，这些会话与之前的 RHEL 主要版本一起使用。

当前无法使用以下功能，或者在 Wayland 下无法正常工作：

  • X11 配置实用程序（如 xrandr ）因为处理、解决方案、轮转和布局的方法不同而无法在 Wayland 下工作。您可以使用 GNOME 设置配置显示功能。
  • 屏幕记录和远程桌面需要应用程序来支持 Wayland 上的门户 API。某些传统应用程序不支持门户 API。
  • Wayland 上不提供指针可访问性。
  • 没有可用的剪贴板管理器。

  • Wayland 上的 GNOME Shell 忽略了大多数传统 X11 应用发布的键盘粒度。您可以使用 /org/gnome/mutter/wayland/xwayland-grab-access-rules GSettings 键启用 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/。

(BZ#1797409)

在桌面和应用程序间进行拖放操作无法正常工作

由于 gnome-shell-extensions 软件包中的一个 bug，drag-and-drop 功能目前在桌面和应用程序间无法正常工作。以后的发行版本中将重新添加对这个功能的支持。

(BZ#1717947)

无法从软件仓库中禁用 flatpak 程序库

目前，在 GNOME 软件工具中的软件程序库工具中无法禁用或删除 flatpak 程序库。

(BZ#1668760)

第二代 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)

系统崩溃可能会导致 fadump 配置丢失

在启用了固件辅助转储(fadump)且引导分区位于 XFS 等日志记录文件系统中的系统中会出现此问题。系统崩溃可能会导致引导装载程序加载未启用转储捕获支持的较早 initrd。因此，恢复后，系统不会捕获 vmcore 文件，这会导致 fadump 配置丢失。

要临时解决这个问题：

  • 如果 /boot 是一个独立的分区，请执行以下操作：

    1. 重启 kdump 服务

    2. 以 root 用户身份运行以下命令，或使用具有 CAP_SYS_ADMIN 权限的用户帐户： 

      # fsfreeze -f
# fsfreeze -u
  • 如果 /boot 不是单独的分区，请重启该系统。

(BZ#1723501)

5.7.12. 图形基础结构

无法使用 sudo 命令运行图形应用程序

当试图以具有更高权限的用户运行图形应用程序时，应用程序无法打开并带有一个出错信息。发生故障的原因是 Xwayland 被 Xauthority 文件限制，为使用常规用户凭证进行验证。

要临时解决这个问题，使用 sudo -E 命令以 root 用户运行图形程序。

(BZ#1673073)

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)

多个 HDR 显示在单个 MST 拓扑上可能无法打开

在使用带有 nouveau 驱动程序的 NVIDIA Turing GPU 的系统上，使用带有多个监视器的 DisplayPort hub（如便携式计算机 dock）支持 HDR 插入的多个监视器可能会导致所有显示无法打开，尽管之前的 RHEL 版本上仍然这样做。这是因为系统错误地认为 hub 中没有足够的带宽来支持所有显示器。

(BZ#1812577)

5.7.13. Web 控制台

非特权用户可以访问订阅页面

如果非管理员访问 web 控制台的 Subscriptions 页面，Web 控制台会显示一个通用错误消息 Cockpit had an unexpected internal error。

要临时解决这个问题，使用特权用户登录到 web 控制台，并选择 Reuse my password for privileged tasks 复选框。

(BZ#1674337)

5.7.14. 虚拟化

Windows Server 2019 主机上的 RHEL 8 虚拟机中的低 GUI 显示性能

当在 Windows Server 2019 主机上以图形模式使用 RHEL 8 作为客户机操作系统时，GUI 显示性能较低，并连接到客户机的控制台输出所需的时间比预期的要长得多。

这是 Windows 2019 主机上的已知问题，并由 Microsoft 解决。要临时解决这个问题，请使用 SSH 连接到客户端，或使用 Windows Server 2016 作为主机。

(BZ#1706541)

无法通过 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)

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>

(BZ#1732726,BZ#1751054)

IBM POWER 虚拟机无法在空 NUMA 节点中正常工作

目前，当在 RHEL 8 主机上运行的 IBM POWER 虚拟机(VM)配置为使用零内存(memory='0')和零 CPU 的 NUMA 节点时，虚拟机将无法启动。因此，红帽强烈建议不要在 RHEL 8 中使用具有空 NUMA 节点的 IBM POWER 虚拟机。

(BZ#1651474)

当在 AMD EPYC 上使用主机透传模式时，虚拟机不会检测到 SMT CPU 拓扑

当在 AMD EPYC 主机上使用 CPU 主机 passthrough 模式引导虚拟机(VM) 时，TOPOEXT CPU 功能标志不存在。因此，虚拟机无法检测到每个内核有多个线程的虚拟 CPU 拓扑。要临时解决这个问题，使用 EPYC CPU 模型而不是主机透传引导虚拟机。

(BZ#1740002)

RHEL 8.2 虚拟机中的磁盘标识符可能会在虚拟机重启时改变。

当将带有 RHEL 8.2 的虚拟机(VM)用作 Hyper-V 管理程序中的客户机操作系统时，虚拟机虚拟磁盘的设备标识符在某些情况下会在虚拟机重启时改变。例如，最初标识为 /dev/sda 的磁盘可能会变为 /dev/sdb。因此，虚拟机可能无法引导，引用 VM 磁盘的脚本可能会停止工作。

为避免这个问题，红帽强烈建议为虚拟机中的磁盘设置持久名称。详情请参阅 Microsoft Azure 文档：

(BZ#1777283)

当使用很多 virtio-blk 磁盘时，虚拟机有时无法启动

在虚拟机(VM)中添加大量 virtio-blk 设备可能会耗尽平台中可用的中断向量。如果发生了这种情况，VM 的客户机操作系统无法引导，并显示 dracut-initqueue[392]: Warning: Could not boot 错误。

(BZ#1719687)

使用 virtio-blk 将 LUN 设备附加到虚拟机中无法正常工作

q35 机器类型不支持 virtio 1.0 设备，因此 RHEL 8 不支持 virtio 1.0 中弃用的功能。特别是，RHEL 8 主机无法从 virtio-blk 设备发送 SCSI 命令。因此，使用 virtio-blk 控制器时，将物理磁盘作为 LUN 设备附加到虚拟机会失败。

请注意，物理磁盘仍可被传递给客户端操作系统，但应该使用 device='disk' 选项而不是 device='lun' 选项进行配置。

(BZ#1777138)

将 POWER9 客户端从 RHEL 7-ALT 主机迁移到 RHEL 8 会失败

目前，将 POWER9 虚拟机从 RHEL 7-ALT 主机系统迁移到 RHEL 8 变得无响应，并带有 "Migration status: active" 状态。

要临时解决这个问题，在 RHEL 7-ALT 主机上禁用 Transparent Huge Pages（THP），这样可使迁移成功完成。

(BZ#1741436)

5.7.15. 支持性

redhat-support-tool 无法用于 FUTURE 加密策略

因为客户门户网站 API 中的证书使用的加密密钥不满足 FUTURE 系统范围的加密策略的要求，所以 redhat-support-tool 程序目前无法使用这个策略级别。

要临时解决这个问题，在连接到客户门户网站 API 时使用 DEFAULT 加密策略。

(BZ#1802026)

5.7.16. 容器

UDICA 无法与 1.0 稳定流工作

UDICA 是为容器生成 SELinux 策略的工具，不能与通过 container-tools:1.0 模块流中的 podman 1.0.x 运行的容器一起使用。

(JIRA:RHELPLAN-25571)

关于 Podman 支持 FIPS 的备注

联邦信息处理标准(FIPS)要求使用经过认证的模块。在以前的版本中，Podman 通过在启动时启用正确的标记在容器中正确安装认证模块。但是，在此发行版本中，Podman 没有以 FIPS 系统范围 crypto-policy 的形式正确设置系统通常提供的额外应用程序帮助程序。尽管认证模块不需要设置系统范围的 crypto-policy，但它确实提高了应用程序以兼容方式使用加密模块的能力。要临时解决这个问题，请在执行任何其他应用程序代码前更改容器以运行 update-crypto-policies --set FIPS 命令。

(BZ#1804193)