9.3. RHEL 8.10 到 RHEL 9.4 和 9.5 升级的已知问题
以下是您升级时可能遇到的已知问题。
- 在进行原位升级时，如果 Network Manager 被禁用或没有安装，则 network teaming 功能无法正常工作。
-
如果您的 RHEL 8 系统使用由红帽提供但在 RHEL 9 中不可用的设备驱动程序，
Leapp将会限制升级。但是，如果 RHEL 8 系统使用Leapp在/etc/leapp/files/device_driver_deprecation_data.json文件中没有数据的第三方设备驱动程序，Leapp不会检测这样的驱动程序并进行升级。然后，该系统可能会在升级后无法引导。 如果系统上安装的第三方软件包（不是红帽签名的）的名称与红帽提供的软件包名称相同，则原位升级会失败。要临时解决这个问题，请在升级前选择以下选项之一：
- 删除第三方软件包
- 使用红帽提供的软件包替换第三方软件包
- 在 RHEL 8 中，您可以使用 VDO 管理器或逻辑卷管理器(LVM)管理 Virtual Data Optimizer (VDO)卷。在 RHEL 9 中，只能使用 LVM 管理 VDO 卷。要在 RHEL 9 上继续使用 VDO 管理的卷，请在升级前将这些卷导入到 LVM 管理的 VDO 卷。如需更多信息，请参阅 将现有 VDO 卷导入到 LVM。
- 在带有独立磁盘的软件冗余阵列(RAID)的系统上，原位升级可能会失败。(BZ#1957192)
在原位升级过程中，
Leapp通常会在 RHEL 8 和 RHEL 9 之间保留网络接口控制器(NIC)。但是，在一些系统上，比如带有网络绑定的系统，可能需要在 RHEL 8 和 RHEL 9 之间更新 NIC 名称。在这些系统上执行以下步骤：-
设置
LEAPP_NO_NETWORK_RENAMING=1环境变量，以防止 Leapp 工具错误地保留原始 RHEL 8 NIC 名称。 - 执行原位升级。
验证您的网络是否正常工作。如果需要，请手动更新网络配置。
(BZ#1919382)
-
设置
如果您的系统使用 BIOS 引导，如果引导磁盘嵌入区域没有包含足够空间用于核心镜像安装，在升级 GRUB 引导装载程序时，原位升级会失败。这会导致系统损坏，在磁盘被手动分区时可能会发生，例如使用 RHEL 6
fdisk工具。要验证这个问题是否会影响您，请执行以下步骤：确定哪个扇区使用安装的引导装载程序在磁盘中启动第一个分区：
# fdisk -l标准分区，其确保为核心镜像保留足够的空间，从扇区 2048 开始。
确定起始扇区是否提供足够的空间。RHEL 9.0 内核镜像需要至少 36 KiB。例如，如果扇区大小为标准的 512 字节，则从扇区 73 或以下开始将无法提供足够的空间。
注意RHEL 9 内核镜像可能大于 36 KiB，需要更高的起始扇区。始终验证当前 RHEL 9 内核需要多少空间。
如果嵌入区域不包含足够的存储空间，请执行全新的 RHEL 9 系统安装，而不是执行原位升级。
(BZ#2181380)
原位升级后，如果系统满足以下条件，SSH 密钥将不再自动生成：
- 系统在云上。
- cloud-init 软件包已安装。
ssh_genkeytypes 配置在 /etc/cloud/cloud.cfg 文件中被设置为 ~，这是默认设置。
如果删除了原始密钥，则此问题会阻止系统使用 SSH 连接。要防止这个问题，请参阅 将模板升级到 RHEL 8.7 或 9 后，无法 SSH 到新虚拟机 知识库解决方案。(BZ#2210012)
- 在硬件级别 13 上创建的，并使用 UEFI 引导的 VMware 虚拟机可能会在升级过程中遇到问题，因为 NVRAM 文件太小了。有关此问题以及如何解决它的更多信息，请参阅 VMWare: 当执行 efibootmgr 或 mokutil 命令添加条目时，得到 "No space left on device"。(RHEL-3362)
-
如果您使用带有 ISO 镜像的 RHUI 进行升级，则升级可能会失败。您可以通过在升级时不使用
--iso选项，或者按照 使用 ISO 进行离线 Leapp 升级失败，并带有 "Failed to synchronize cache for repo 'rhul-microsoft-azure-rhel8', ignoring this repo" 中的说明进行操作，来临时解决这个问题。(RHEL-3296) 如果挂载了太多文件系统，则预升级过程可能会失败，并显示以下错误消息：
OperationalError: unable to open database file
如果出现这个问题，请完成以下步骤：
- 卸载与系统分区无关且在升级过程中不需要的文件系统。
-
注释掉
/etc/fstab文件中卸载的文件系统的条目，以防止它们在升级过程中被挂载。 升级后恢复原始文件系统配置。
如果
/etc/fstab文件中定义的任何挂载的文件系统没有设置shared传播标志，则升级可能失败。要防止这个问题，请重新挂载这些文件系统，以将其设置为 shared ：# mount -o remount --make-shared <mountpoint>使用每个文件系统的挂载点替换 mountpoint。
如需更多信息，请参阅 在 DNF 事务检查过程中 Leapp "不能加载的 RPM 文件"。(RHEL-23449)
-
如果为升级过程设置了有限的资源，则升级可能会失败。例如，如果设置了，升级进程可能达到
最大打开文件描述符数和进程及其子进程可写的最大文件大小。要防止这些问题，请在升级前增加或减少这些限制。如需更多信息，请参阅 为什么 leapp 预升级失败，并显示 sqlite3.OperationalError: unable to open database file traceback error? 和 Ensure that there is enough diskspace in /var/lib/leapp/scratch/diskimages/root_boot at least XXX mib are needed。(RHEL-16881, RHEL-26459) - 目前在 ARM 架构的 Amazon Web Services (AWS)上使用 Red Hat Update Infrastructure (RHUI)进行原位升级时遇到问题。改为使用 Red Hat Subscription Management (RHSM)。(RHEL-38909)
-
如果您使用 RHUI 进行升级，则
/usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/目录中的文件在预升级报告中被错误地报告为自定义文件。除非手动修改这些文件，否则您可以忽略报告中有关这些文件的警告，原位升级将不会受到影响。(RHEL-40115) 默认情况下，在升级后
logrotate不会激活。logrotate以前在 RHEL 8 及更早版本中由cron管理。在 RHEL 9 中，它由systemd管理。要永久激活logrotate，请在升级后运行以下命令：# systemctl enable --now logrotate.timer-
如果您使用 HTTP 代理，则必须将 Red Hat Subscription Manager 配置为使用代理服务器，或在执行
subscription-manager命令时使用--proxy <hostname>选项 。否则，subscription-manager命令的执行会失败。如果您使用--proxy选项而不是配置更改，升级过程会失败，因为Leapp无法检测到代理。要防止这个问题发生，请手动编辑rhsm.conf文件，如 How to configure HTTP Proxy for Red Hat Subscription Management 所述。(BZ#1689294) -
对于需要代理访问 RHEL 9 内容的系统，您通常需要在
/etc/dnf/dnf.conf配置文件中配置 DNF 使用代理。如果当前的 DNF 配置与目标系统上的 DNF 版本不兼容，请在/etc/leapp/files/dnf.conf配置文件中指定有效的目标配置。如需更多信息，请参阅 Leapp 如何使用代理？
