5.7. 已知问题

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

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)

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

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

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

(BZ#1757877)

新的 osbuild-composer 后端不会在升级时从 lorax-composer 复制蓝图状态

对于从 lorax-composer 后端升级到新 osbuild-composer 后端的 Image Builder 用户，蓝图可能会消失。因此，升级完成后，蓝图不会自动显示。要临时解决这个问题，请执行以下步骤。

先决条件

composer-cli CLI 工具已安装。

流程

运行该命令，将之前基于 lorax-composer 的蓝图加载到新 osbuild-composer 后端：

$ for blueprint in $(find /var/lib/lorax/composer/blueprints/git/workspace/master -name '*.toml'); do composer-cli blueprints push "${blueprint}"; done

因此，相同的蓝图现在可在 osbuild-composer 后端提供。

其它资源

有关此已知问题的详情，请参阅镜像构建器蓝图在 Red Hat Enterprise Linux 8.3 的更新后不再存在。

(BZ#1897383)

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 安装中完成以下步骤：

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

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

(BZ#1821192)

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

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

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

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

(BZ#1822880)

当使用安装程序引导选项配置 InfiniBand 网络接口时，RHEL 安装程序无法启动

当您使用安装程序引导选项（例如：使用 PXE 服务器下载安装程序镜像）在 RHEL 安装的早期配置 InfiniBand 网络接口时，安装程序无法激活网络接口。

这是因为 RHEL NetworkManager 无法识别 InfiniBand 模式中的网络接口，而是为接口配置以太网连接。

因此，连接激活会失败，且在早期需要 InfiniBand 界面的连接，RHEL 安装程序无法启动安装。

要解决这个问题，使用 Lorax 工具创建一个包括更新的 Anaconda 和 NetworkManager 软件包的新安装介质。

有关创建新安装介质（包括更新的 Anaconda 和 NetworkManager 软件包，使用 Lorax 工具）的详情，请参考使用 InfiniBand 网络接口安装 Red Hat Enterprise Linux 8.3.0。

(BZ#1890261)

当 NVDIMM 设备命名空间设为 devdax 模式时，Anaconda 安装会失败。

在 GUI 安装前，Anaconda 安装在 NVDIMM 设备命名空间设为 devdax 模式引导后会失败，并带有 trackback 信息。

要临时解决这个问题，请在安装开始前重新配置 NVDIMM 设备，将命名空间设置为与 devdax 模式不同的模式。因此，您可以继续安装。

(BZ#1891827)

当使用使用第三方工具创建的 USB 引导安装时，不会检测 本地介质 安装源

当从使用第三方工具创建的 USB 引导 RHEL 安装时，安装程序无法检测 本地介质 安装源（只检测 '红帽 CDN'）。

造成此问题的原因是默认引导选项 int.stage2= 尝试搜索 iso9660 镜像格式。但是，第三方工具可能会创建具有不同格式的 ISO 镜像。

作为临时解决方案，请使用以下解决方案之一：

当引导安装时，点击 Tab 键来编辑内核命令行，并将引导选项 inst.stage2= 改为 inst.repo=。
要在 Windows 中创建可引导 USB 设备，使用 Fedora Media Writer。
使用 Rufus 等第三方工具创建可引导 USB 设备时，首先在 Linux 系统上重新生成 RHEL ISO 镜像，然后使用第三方工具创建可引导 USB 设备。

有关执行任何指定临时解决方案的步骤的更多信息，请参阅安装 RHEL 8.3 过程中不会自动探测到安装介质

(BZ#1877697)

Anaconda 现在在文本模式中显示 ldl 或未格式化的 DASD 磁盘对话框

在以前的版本中，在文本模式的安装过程中，Anaconda 无法显示 Linux 磁盘布局(ldl)或未格式化的直接访问存储设备(DASD)磁盘的对话框。因此，用户无法将这些磁盘用于安装。

有了这个更新，在文本模式中，Anaconda 会识别 ldl 和未格式化的 DASD 磁盘，并显示一个对话框，其中用户可以正确格式化它们以备将来安装使用。

(BZ#1874394)

使用图形安装程序时，Red Hat Insights 客户端无法注册操作系统

目前，安装会失败，并显示结尾时指向 Insights 客户端的错误。

要临时解决这个问题，在安装程序注册系统前，在 连接到 Red Hat 这一步骤取消选择 Connect to Red Hat Insights 选项。

因此，您可以使用以下命令完成安装并在以后注册到 Insights：

# insights-client --register

（BZ#1931069）

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)

5.7.3. 基础架构服务

运行 dnf update 时会删除 libmaxminddb-devel-debuginfo.rpm

当执行 dnf update 命令时，二进制 mmdblookup 工具会从 libmaxminddb-devel 子软件包移到主 libmaxmindb 软件包中。因此，libmaxminddb-devel-debuginfo.rpm 被删除，这可能会为这个软件包创建错误的更新路径。要临时解决这个问题，请在执行 dnf update 命令前删除 libmaxminddb-devel-debuginfo。

注意： libmaxminddb-debuginfo 是新的 debuginfo 软件包。

(BZ#1642001)

5.7.4. 安全性

锁定的用户可以运行 sudo

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

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

(BZ#1786990)

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

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

(BZ#1677754)

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)

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

默认日志环境设置可能会消耗 4 GB 内存甚至更多，当 systemd-journald 使用 rsyslog 运行时，速率限制值的调整会很复杂。

如需更多信息，请参阅 RHEL 默认日志设置对性能的负面影响及环境方案。

（JIRA:RHELPLAN-10431）

/etc/passwd- 的文件权限与 CIS RHEL 8 基准 1.0.0 不一致

由于 CIS Benchmark 存在问题，修正 SCAP 规则可以确保 /etc/passwd- backup 文件中的权限被配置为 0644。但是 CIS Red Hat Enterprise Linux 8 Benchmark 1.0.0 需要该文件的文件权限 0600。因此，在修复后, /etc/passwd- 的文件权限与基准数据不一致。

(BZ#1858866)

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

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

要临时解决这个问题，请在内核命令行中添加 selinux=0 参数来禁用 SELinux，如使用 SELinux 中的在引导时更改 SELinux 模式部分所述。

（JIRA:RHELPLAN-34199）

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

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

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

(BZ#1744108)

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)

FIPS 模式中的 openssl 只接受特定的 D-H 参数

在 FIPS 模式中，使用 OpenSSL 的传输安全性层(TLS)客户端返回一个 bad dh value 错误，并在使用手动生成的参数的服务器中保存 TLS 连接。这是因为 OpenSSL 当配置为符合 FIPS 140-2 时，只可用于符合 NIST SP 800-56A rev3 附件 D（RFC 3526 中定义的组 14、15、16、17 和 18,以及 RFC 7919）中定义的组。另，,使用 OpenSSL 的服务器会忽略所有其他参数，并选择类似大小的已知参数。要临时解决这个问题，请只使用兼容的组。

(BZ#1810911)

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

systemd 服务无法从任意路径执行命令

systemd 服务无法从 /home/user/bin 任意路径执行命令，因为 SELinux 策略软件包不包括任何这样的规则。因此，在非系统路径中执行的自定义服务会失败，并最终会在 SELinux 拒绝访问时记录 Access Vector Cache(AVC)拒绝审核信息。要临时解决这个问题，请执行以下操作之一：

使用带有 -c 选项的 shell 脚本执行该命令。例如：
```
bash -c command
```
从常用的命令路径 /bin、/sbin、/usr/sbin、/usr/local/bin 和 /usr/local/sbin 中执行命令。

(BZ#1860443)

rpm_verify_permissions 在 CIS 配置集中失败

rpm_verify_permissions 规则将文件权限与软件包默认权限进行比较。但是，由 scap-security-guide 软件包提供的互联网安全中心(CIS)配置将某些文件权限更改为比默认权限更严格。因此，使用 rpm_verify_permissions 验证某些文件会失败。

要临时解决这个问题，请手动验证这些文件是否具有以下权限：

/etc/cron.d (0700)
/etc/cron.hourly (0700)
/etc/cron.monthly (0700)
/etc/crontab (0600)
/etc/cron.weekly (0700)
/etc/cron.daily (0700)

(BZ#1843913)

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

Kickstart 引用开放安全内容自动化协议(OSCAP)Anaconda 附加组件作为 org_fedora_oscap ，而不是 com_redhat_oscap ，这可能会导致混淆。这样做可以保持与 Red Hat Enterprise Linux 7 的向后兼容性。

(BZ#1665082)

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

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

(BZ#1750755)

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)

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

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

(BZ#1787156)

无法使用 Server with GUI 或 Workstation 软件选择和 CIS 安全配置集进行安装

CIS 安全配置集与 Server with GUI 和 Workstation 不兼容。因此，无法使用 Server with GUI 软件选择和 CIS 配置集进行 RHEL 8 安装。使用 CIS 配置集进行尝试安装，且这两种软件选择之一都会生成出错信息：

package xorg-x11-server-common has been added to the list of excluded packages, but it can't be removed from the current software selection without breaking the installation.

要临时解决这个问题，请不要在 Server with GUI 或 Workstation 软件选择中使用 CIS 安全配置集。

(BZ#1843932)

在 kickstart 安装过程中修复与服务相关的规则可能会失败

在 kickstart 安装过程中，OpenSCAP 工具有时会错误地显示服务的 启用 或 禁用 状态修正不需要。因此，OpenSCAP 可能会将安装的系统上的服务设置为不合规的状态。作为临时解决方案，您可以在 kickstart 安装后扫描并修复该系统。这可以解决与服务相关的问题。

(BZ#1834716)

某些 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)

crypto-policies 错误地允许 Camellia 密码

RHEL 8 系统范围的加密策略应该在所有策略级别禁用 Camellia 密码，如产品文档中所述。但是 Kerberos 协议默认启用密码。

要临时解决这个问题，请应用 NO-CAMELLIA 子策略：

# update-crypto-policies --set DEFAULT:NO-CAMELLIA

在上个命令中，如果您之前已从 DEFAULT 进行了切换，请将 DEFAULT 替换为加密级别名称。

因此，只有在您通过临时解决方案禁用系统范围的加密策略的所有应用程序中，Camellia 密码才会被正确禁止。（BZ#1919155）

5.7.5. 网络

iptables 程序现在为更新链的命令要求载入模块，而不会考虑 NLM_F_CREATE 标签

在以前的版本中，当设定链策略时，iptables-nft 程序会生成 NEWCHAIN 信息，但没有设置 NLM_F_CREATE 标志。因此,如果内核模块没有被手动加载,RHEL 8 内核不会加载任何模块,所得到的 update chain 命令会失败。有了这个更新，iptables-nft 工具现在为所有更新链的命令请求模块加载，用户可以使用 iptables-nft 工具设置链策略，而无需手动加载相关的模块。

(BZ#1812666)

对更新内核中的 数据包/字节 计数器的支持，在 RHEL 7 和 RHEL 8 之间被错误地更改了

当使用启用了 iptables 规则的计数器（即指定匹配 ipset 条目的额外约束）的 ipset 命令时，只有在所有附加约束匹配时才更新 ipset 计数器。在 --packets-gt 或 --bytes-gt 约束中存在问题。

因此，当将 iptables 规则集从 RHEL 7 迁移到 RHEL 8 时，涉及 ipset 查找的规则可能会停止工作，需要调整。要临时解决这个问题，请避免使用 --packets-gt 或 --bytes-gt 选项，并使用 --packets-lt 或者 --bytes-lt 选项替换它们。

(BZ#1806882)

在使用 nfp 驱动程序的 Netronome 网卡中卸载 XDP 程序失败

Netronome 网卡的 nfp 驱动程序存在 bug。因此，如果您使用这些卡，并使用带有 XDP_FLAGS_REPLACE 标志的 IFLA_XDP_EXPECTED_FD 特性加载 XDP 程序时，卸载 eXpress Data Path(XDP)程序会失败。例如，这个程序错误会影响使用 libxdp 库载入的 XDP 程序。目前，这个问题还没有可用的临时解决方案。

(BZ#1880268)

在 ip 引导选项中使用 DHCP 时，Anaconda 没有网络访问权限

初始 RAM 磁盘(initrd)使用 NetworkManager 来管理网络。RHEL 8.3 ISO 文件提供的 dracut NetworkManager 模块错误地假设始终设置了 Anaconda 引导选项中 ip 选项的第一个字段。因此，如果您使用 DHCP 并设置 ip=::::<host_name>::dhcp，NetworkManager 将不会检索 IP 地址，并且网络在 Anaconda 中不可用。

您可以使用以下方法临时解决这个问题：

将 ip 选项中的第一个字段设为‘. ‘：
```
ip=.::::<host_name>::dhcp
```
请注意，当这个问题在以后的 RHEL 版本中被解决后，这个临时解决方案将不会起作用。
使用包含错误修复的 BaseOS 存储库中的最新软件包重新创建 boot.iso 文件：

# lorax '--product=Red Hat Enterprise Linux' --version=8.3 --release=8.3 \
    --source=<URL_to_BaseOS_repository> \
    --source=<URL_to_AppStream_repository> \
    --nomacboot --buildarch=x86_64 '--volid=RHEL 8.3' <output_directory>

.请注意，红帽不支持自创建的 ISO 文件。

因此，RHEL 可以从 DHCP 服务器获得 IP 地址，在 Anaconda 中可以访问网络。

(BZ#1902791)

5.7.6. 内核

tboot-1.9.12-2 工具在 RHEL 8 中会导致引导失败

版本 1.9.12-2 的 tboot 工具会导致某些带有受信任的平台模块(TPM)2.0 的系统无法在旧模式下引导。因此，当系统尝试从 tboot Grand Unified Bootloader(GRUB)条目引导后会停止。要临时解决这个问题，请降级到 1.9.10 版本的 tboot。

(BZ#1947839)

内核在 IBM Z 系统中返回假的警告

在 RHEL 8 中，IBM Z 系统缺少 ZONE_DMA 内存区的白名单条目来允许用户访问。因此，内核会返回假的警告，例如：

...
Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dma-kmalloc-192' (offset 0, size 144)!
WARNING: CPU: 0 PID: 8519 at mm/usercopy.c:83 usercopy_warn+0xac/0xd8
...

当通过 sysfs 接口访问某些系统信息时会出现警告信息。例如，运行 debuginfo.sh 脚本。

要临时解决这个问题，在内核命令行中添加 hardened_usercopy=off 参数。

因此，在以上场景中不会显示任何警告信息。

(BZ#1660290)

rngd 服务忙等待会导致在 FIPS 模式下消耗掉所有 CPU

从版本 4.18.0-193.10 开始，内核添加了 FIPS 模式的新内核熵源。因此，当使用 FIPS 模式时，rngd 服务忙等待会等待对 /dev/random 设备的 poll() 系统调用，从而导致消耗掉 100% 的 CPU 时间。要临时解决这个问题，运行以下命令停止和禁用 rngd：

# systemctl stop rngd
# systemctl disable rngd

因此，在上述场景中，rngd 不再对 poll() 进行忙等待。

(BZ#1884857)

softirq 更改会导致 localhost 接口在负载过重时丢弃 UDP 数据包

完成了对 Linux 内核的软件中断(softirq) 处理的更改，以减少拒绝服务(DOS)的影响。因此，这导致了这样的情况，即 localhost 接口在负载过重时丢弃用户数据报协议(UDP)数据包。

要临时解决这个问题，将网络设备积压缓冲的大小增加到值 6000：

echo 6000 > /proc/sys/net/core/netdev_max_backlog

在红帽进行的测试中，这个值足以防止数据包丢失。负载较大的系统可能需要更大的积压值。增加的积压会导致潜在的延迟在 localhost 接口上增加。

结果是增加缓冲区并允许更多数据包等待处理，这降低了丢弃 localhost 数据包的几率。

(BZ#1779337)

在内存热插拔或拔出操作后，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)

使用 irqpoll 会导致 vmcore 生成失败

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

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

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

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

(BZ#1654962)

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)

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

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

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

Integrated Lights-Out (iLO) 服务器管理软件中的 Generate NMI 按钮。这个按钮由用户触发。
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 profile powersave 命令会导致具有旧的 Thunderx(CN88x)处理器的 Penguin Valkyrie 2000 2-socket 系统的无响应状态。因此，需要重启系统以便恢复工作。要临时解决这个问题，如果您的系统符合上述说明，请避免使用 powersave 配置集。

(BZ#1609288)

默认的 7 4 1 7 printk 值有时会导致临时系统无响应

默认的 7 4 1 7 printk 值可以更好地调试内核的活动。但是，当与串口控制台搭配使用时，这个 printk 设置可能会导致大量 I/O，从而导致 RHEL 系统暂时变得不响应。为了解决这个问题，添加了一个新的 optimize-serial-console TuneD 配置集，它把默认的 printk 值减为 4 4 1 7。用户可以按照以下方法追踪其系统：

# tuned-adm profile throughput-performance optimize-serial-console

重启后会保留一个较低的 printk 值，这可以降低系统挂起的可能性。

请注意，这个设置更改的代价是丢失额外的调试信息。

有关新添加的特性的更多信息，请参阅增加了一个新的 optimize-serial-console TuneD 配置集，通过降低 printk 值来减小到串口控制台的 I/O。

（JIRA:RHELPLAN-28940）

内核 ACPI 驱动程序报告无法访问 PCIe ECAM 内存区域

固件提供的高级配置和电源接口（ACPI）表没有在 PCI 总线设备中定义内存区域。因此，在系统引导时会出现以下警告信息：

[    2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace
[    2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]

但是，内核仍然可以访问 0x30000000-0x31ffff 内存区域，并可以正确地将该内存区域分配给 PCI 增强配置访问机制(ECAM)。您可以通过以下输出通过 256 字节偏移访问 PCIe 配置空间来验证 PCI 是正常工作的：

03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
 ...
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=0us LTR1.2_Threshold=0ns
                L1SubCtl2: T_PwrOn=10us

因此，您可以忽略警告信息。

有关此问题的详情，请参阅 "Firmware Bug: ECAM area mem 0x30000000-0x31ffffff not reserved in ACPI namespace" appears during system boot。

(BZ#1868526)

OPEN MPI 库可能会使用默认 PML 的触发程序运行时失败

在 OPEN 消息密码界面（OPEN MPI）实现 4.0.x 系列中，Unified communicating X（UCX）是默认的点到点通信器（PML）。OPEN MPI 4.0.x 系列之后的版本弃用了 openib Byte Transfer Layer(BTL)。

但是，当 OPEN MPI 在同构集群（相同的硬件和软件配置）上运行时，UCX 仍会为 MPI 单边操作使用 openib BTL。因此，这可能会导致触发器执行错误。要临时解决这个问题：

使用以下参数运行 mpirun 命令：

-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0

其中,

-mca btl openib 参数禁用 openib BTL
-mca pml ucx 参数将 OPEN MPI 配置为使用 ucx PML。
x UCX_NET_DEVICES= 参数限制 UCX 使用指定的设备

OPEN MPI 在使用异构集群（不同硬件和软件配置）中运行时，使用 UCX 作为默认的 PML。因此，这可能会导致 OPEN MPI 任务在运行时出现错误的性能、不响应性行为或崩溃问题。要临时解决这个问题，将 UCX 优先级设置为：

使用以下参数运行 mpirun 命令：

-mca pml_ucx_priority 5

因此，OPEN MPI 库可以选择使用 UCX 的可替代传输层。

(BZ#1866402)

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)

LVM writecache 的限制

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

使用 pvmove 命令时您无法命名 writecache 逻辑卷。
您不能将带有 writecache 的逻辑卷与精简池或 VDO 结合使用。

以下限制也适用于 cache 方法：

您不能在将 cache 或 writecache 附加到逻辑卷时重新定义大小。

（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 设备转换为 raid1，请参阅将镜像 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)

OpenLDAP 库之间的符号冲突可能会导致 httpd 中的崩溃

当 OpenLDAP 提供的 libldap 和 libldap_r 库被加载，并在单个进程中使用时，这些库之间可能会出现符号冲突。因此，如果 mod_security 或mod_auth_openidc 模块也是由 httpd 配置加载的，则使用 PHP ldap 扩展的 Apache httpd 子进程可能会意外终止。

有了这个对 Apache Portable Runtime(APR)库的更新，您可以通过设置 APR_DEEPBIND 环境变量来临时解决这个问题，该变量使在加载 httpd 模块时可以使用 RTLD_DEEPBIND 动态链接器选项。当 APR_DEEPBIND 环境变量启用时，崩溃不会在加载冲突库的 httpd 配置中发生。

(BZ#1819607)

PAM 插件无法在 MariaDB中工作

MariaDB 10.3 提供了可插拔验证模块(PAM)插件版本 1.0。MariaDB PAM 插件版本 1.0 不能在 RHEL 8 中工作。要临时解决这个问题，请使用 mariadb:10.5 模块流提供的 PAM 插件版本 2.0，该模块流由 RHEL 8.4 提供。

（BZ#1942330）

5.7.9. 身份管理

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

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

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

(BZ#1816784)

将 cert-fix 程序与 --agent-uid pkidbuser 选项一同使用会破坏证书系统

使用带有 --agent-uid pkidbuser 选项的 cert-fix 工具可破坏证书系统的 LDAP 配置。因此,，证系统可能会变得不稳定，需要手动步骤才能恢复该系统。

(BZ#1729215)

由连接到 PKI CA 的 PKI ACME Responder 发布的证书可能无法通过 OCSP 验证

PKI CA 提供的默认 ACME 证书配置文件包含一个示例 OCSP URL，其不指向实际的 OCSP 服务。因此，如果将 PKI ACME Responder 配置为使用 PKI CA 签发者，则响应者发布的证书可能会失败 OCSP 验证。

要临时解决这个问题，您需要在 /usr/share/pki/ca/profiles/ca/acmeServerCert.cfg 配置文件中将 policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0 属性设置为空白值：

在 ACME Responder 配置文件中，将行 .serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ocsp.example.com 改为 policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=。
重启服务并重新生成证书。

因此，PKI CA 将使用自动生成的 OCSP URL 生成 ACME 证书，指向实际 OCSP 服务。

(BZ#1868233)

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

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

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

(BZ#1723362)

IdM 主机上的 /var/log/lastlog 稀疏文件可能会导致性能问题

在 IdM 安装过程中，从总计 10,000 个可能范围内会随机选择并分配一个 200,000 UID 范围。当您决定以后合并两个独立的 IdM 域时，以这种方法选择一个随机范围可显著降低冲突 ID 的可能性。

但是，高 UID 可能会导致 /var/log/lastlog 文件出现问题。例如，如果 UID 为 1280000008 的用户登录到 IdM 客户端，则本地 /var/log/lastlog 文件的大小会增加到近 400 GB。虽然实际文件是稀疏的，且没有使用所有空间，但某些应用程序默认不是为识别稀疏文件而设计的，且可能需要一个特定的选项来处理这些文件。例如，如果设置比较复杂，备份和复制应用程序无法正确处理稀疏文件，则该文件会像大小为 400 GB 一样被复制。这个行为可能会导致性能问题。

要临时解决这个问题：

如果是标准软件包，请参考其文档来识别处理稀疏文件的选项。
如果是自定义应用程序，请确保它能够正确管理稀疏文件，如 /var/log/lastlog。

（JIRA:RHELPLAN-59111）

对 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.10. Desktop

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

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

(BZ#1668760)

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

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

(BZ#1717947)

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

5.7.11. 图形基础结构

radeon 无法正确重置硬件

radeon 内核驱动程序目前没有在 kexec 上下文中正确重置硬件。相反，radeon 无法工作，从而导致剩余的 kdump 服务失败。

要临时解决这个问题，在 kdump 中禁用 radeon，方法是在 /etc/kdump.conf 文件中添加以下行：

dracut_args --omit-drivers "radeon"
force_rebuild 1

重启机器和 kdump。启动 kdump 后，force_rebuild 1 行可能会从配置文件中删除。

请注意，在这种情况下，kdump 不会提供图形，但 kdump 可成功运行。

(BZ#1694705)

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

在使用带有 nouveau 驱动程序的 NVIDIA 图灵 GPU 的系统上，使用一个有支持 HDR 的多个显示器插入其中的 DisplayPort 集线器（如笔记本电脑底座），可能会导致打开失败。这是因为系统错误地认为 hub 中没有足够的带宽来支持所有显示器。

(BZ#1812577)

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

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

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

(BZ#1673073)

VNC Viewer 显示在 IBM Z 中带有 16 位颜色深度的错误颜色

当您连接到带有 16 位色彩深度的 IBM Z 服务器上的 VNC 会话时，VNC Viewer 应用程序会显示错误的颜色。

要临时解决这个问题，请在 VNC 服务器中设置 24 位颜色深度。使用 Xvnc 服务器将 -depth 16 选项替换为 -depth 24 （在 Xvnc 配置中）。

因此，VNC 客户端会显示正确的颜色，但在服务器中使用更多的网络带宽。

(BZ#1886147)

ARM 不支持硬件加速

内置图形驱动程序不支持 64 位 ARM 架构中的硬件加速或 Vulkan API。

要启用硬件加速或者 ARM 上的 Vulkan，安装专有 Nvidia 驱动程序。

（JIRA:RHELPLAN-57914）

RHEL 安装程序对 NVIDIA Ampere 没有响应

RHEL 8.3.0 不支持 NVIDIA Ampere GPU。如果您在具有 NVIDIA Ampere GPU 的系统上启动 RHEL 安装，则安装程序将没有响应。因此，安装无法成功完成。

NVIDIA Ampere 系列包括以下 GPU 型号：

GeForce RTX 3060 Ti
GeForce RTX 3070
GeForce RTX 3080
GeForce RTX 3090
RTX A6000
NVIDIA A40
NVIDIA A100
NVIDIA A100 80GB

要临时解决这个问题，请禁用 nouveau 图形 驱动程序，并在文本模式下安装 RHEL:

引导进入安装程序的引导菜单。
在内核命令行上添加 nouveau.modeset=0 选项。
详情请参阅编辑引导选项。
在系统上安装 RHEL。
引导进入新安装的 RHEL。在引导菜单中，在内核命令行上添加 nouveau.modeset=0 选项。

永久禁用 nouveau 驱动程序：

# echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist.conf

作为结果，安装会成功完成，RHEL 现在以文本模式运行。

另外，您可以安装专有 NVIDIA GPU 驱动程序以启用图形。具体步骤请参阅如何在 RHEL 8 中安装 NVIDIA 专有驱动程序。

(BZ#1903890)

5.7.12. Web 控制台

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

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

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

(BZ#1674337)

5.7.13. Red Hat Enterprise Linux 系统角色

系统角色日志记录不支持 ovirt 输入和 elasticsearch 输出功能

系统角色日志中不支持 oVirt 输入和 elasticsearch 输出，虽然 README 文件中已提到它们。目前还没有可用的临时解决方案。

(BZ#1889468)

5.7.14. 虚拟化

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

当使用很多 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)

当主机上禁用 TSX 时，使用 Cooperlake 的虚拟机无法引导

使用 Cooperlake CPU 模型的虚拟机（VM）目前在主机上禁用 TSX CPU 标签时无法引导。相反，主机会显示以下出错信息：

the CPU is incompatible with host CPU: Host CPU does not provide required features: hle, rtm

要在此类主机上使用 Cooperlake 生成虚拟机，请在虚拟机 XML 配置中禁用 VM 配置中的 HLE、RTM 和 TAA_NO 标志：

<feature policy='disable' name='hle'/>
<feature policy='disable' name='rtm'/>
<feature policy='disable' name='taa-no'/>

(BZ#1860743)

虚拟机有时无法在 Witherspoon 主机上引导

在某些情况下，使用 pseries-rhel7.6.0-sxxm 机器类型的虚拟机(VM)不能在使用 DD2.2 或 DD2.3 CPU 的 Power9 S922LC for HPC 主机上启动。

尝试引导这样的虚拟机会生成以下出错信息：

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)

5.7.15. 云环境中的 RHEL

Azure NV6 实例上的 GPU 问题

当在 Microsoft Azure NV6 实例上运行 RHEL 8 作为客户机操作系统时，从休眠状态恢复虚拟机（VM）有时会导致虚拟机的 GPU 工作不正确。当发生这种情况时，内核会记录以下信息：

hv_irq_unmask() failed: 0x5

(BZ#1846838)

kdump 有时不会在 Azure 和 Hyper-V 上启动

在托管在 Microsoft Azure 或 Hyper-V hypervisor 上的 RHEL 8 客户机操作系统中，启动 kdump 内核在某些情况下会在启用执行后通知程序时失败。

要临时解决这个问题，请禁用 crash kexec post notifiers：

# echo N > /sys/module/kernel/parameters/crash_kexec_post_notifiers

(BZ#1865745)

在 VMWare 主机的 RHEL 8 虚拟机中设置静态 IP 无法正常工作

目前，当在 VMWare 主机中使用 RHEL 8 作为虚拟机（VM）的客户机操作系统时，DatasourceOVF 功能无法正常工作。因此，如果您使用 cloud-init 程序将虚拟机的网络设置为静态 IP，然后重启虚拟机，则虚拟机的网络将变为 DHCP。

(BZ#1750862)

内核转储带有特定 NIC 的 RHEL 8 虚拟机到 Azure 的远程机器所需的时间比预期的时间要长

目前，虚拟机使用启用了加速网络的 NIC 时，用 kdump 实用程序将 RHEL 8 虚拟机(VM)的内核转储保存到远程机器上无法正常工作。因此，转储文件会在大约 200 秒后保存，而不是立即保存。另外，在保存转储文件前会在控制台中记录以下出错信息。

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

(BZ#1854037)

在虚拟机从休眠中恢复后，TX/RX 数据包计数器不会增加

在 Microsoft Azure 上恢复休眠时，当 RHEL 8 虚拟机(VM)使用 CX4 VF NIC 时, TX/RX 数据包计数器会停止增长,。要让计数器保持工作正常，重启虚拟机。请注意，这样做会重置计数器。

（BZ#1876527）

RHEL 8 虚拟机无法从 Azure 的休眠状态恢复

当启用 SR-IOV 的 RHEL 8 虚拟机(VM)已休眠并在 Microsoft Azure 上被取消分配，则虚拟功能(VF)（vmbus 设备）的 GUID 会改变。因此，当虚拟机被重启时，它无法恢复并崩溃。作为临时解决方案，使用 Azure 串口控制台硬重置虚拟机。

(BZ#1876519)

将 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.16. 支持性

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

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

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

(BZ#1802026)

5.7.17. 容器

UDICA 无法与 1.0 稳定流工作

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

(JIRA:RHELPLAN-25571)

podman system connection add 不会自动设置默认连接

podman system connection add 命令不会自动将第一个连接设置为默认连接。要设置默认连接，您必须手动运行命令 podman system connection default <connection_name>。

(BZ#1881894)