9.6. Shell 和命令行工具
ipmitool 与某些服务器平台不兼容
ipmitool 工具为监控、配置和管理支持智能平台管理接口(IPMI)的设备提供服务。ipmitool 的当前版本默认使用 Cipher Suite 17,而不是之前的 Cipher Suite 3。因此,ipmitool 无法与在协商过程中与声称支持 Cipher Suite 17 的某些裸机节点通信,但实际上不支持这个加密套件。因此,ipmitool 会停止,并显示 no matching cipher suite 错误消息。
如需了解更多详细信息,请参阅相关的 知识库文章。
要解决这个问题,请更新您的基板管理控制器(BMC)固件以使用 Cipher Suite 17。
另外,如果 BMC 固件更新不可用,您可以通过强制 ipmitool 使用特定加密套件来临时解决这个问题。当使用 ipmitool 调用管理任务时,向 ipmitool 命令添加 -C 选项,以及您要使用的加密套件的 编号。请参见以下示例:
ipmitool -I lanplus -H myserver.example.com -P mypass -C 3 chassis power status
# ipmitool -I lanplus -H myserver.example.com -P mypass -C 3 chassis power status
当您不使用清理磁盘进行恢复时,ReaR 无法重新创建卷组
当您要恢复到包含现有数据的磁盘时,ReaR 无法执行恢复。
要临时解决这个问题,如果磁盘之前使用过,请在恢复之前手动擦除磁盘。要在救援环境中擦除磁盘,请在运行 rear recover 命令前使用以下命令之一:
-
使用
dd命令覆盖磁盘。 -
使用带有
-a标志的wipefs命令来清除所有可用的元数据。
请参见以下擦除 /dev/sda 磁盘的元数据的示例:
wipefs -a /dev/sda[1-9] /dev/sda
# wipefs -a /dev/sda[1-9] /dev/sda
此命令首先从 /dev/sda 上的分区擦除元数据,然后是分区表本身。
启用了安全引导机制的 UEFI 系统上的 ReaR 救援镜像无法使用默认设置引导
使用 rear mkrescue 或 rear mkbackup 命令创建 ReaR 镜像失败,并显示以下信息:
grub2-mkstandalone might fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/x86_64-efi/moddep.lst file) (...) grub2-mkstandalone: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
grub2-mkstandalone might fail to make a bootable EFI image of GRUB2 (no /usr/*/grub*/x86_64-efi/moddep.lst file)
(...)
grub2-mkstandalone: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
缺少的文件是 grub2-efi-x64-modules 软件包的一部分。如果您安装此软件包,则会成功创建救援镜像,且没有任何错误。当启用了 UEFI 安全引导时,救援镜像无法引导,因为它使用未签名的引导装载程序。
要临时解决这个问题,请在 /etc/rear/local.conf 或 /etc/rear/site.conf (ReaR 配置文件)中添加以下变量:
UEFI_BOOTLOADER=/boot/efi/EFI/redhat/grubx64.efi SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi
UEFI_BOOTLOADER=/boot/efi/EFI/redhat/grubx64.efi
SECURE_BOOT_BOOTLOADER=/boot/efi/EFI/redhat/shimx64.efi
使用推荐的临时解决方案,即使在没有 grub2-efi-x64-modules 软件包的系统上也可以成功生成镜像,它可在启用了安全引导的系统上启动。另外,在系统恢复过程中,恢复的系统的引导加载程序被设置为 EFI shim 引导装载程序。
有关 UEFI、安全引导 和 shim 引导装载程序 的更多信息,请参阅 UEFI:引导系统时会发生什么 知识库文章。
Jira:RHELDOCS-18064[1]
coreutils 可能会报告误导性的 EPERM 错误代码
GNU Core 工具(coreutils)使用 statx() 系统调用启动了。如果 seccomp 过滤器为未知系统调用返回 EPERM 错误代码,则 coreutils 可能会报告误导 EPERM 错误代码,因为 EPERM 无法与正常工作的 statx () syscall 返回的实际 Operation not permitted 错误区分开。
要临时解决这个问题,请更新 seccomp 过滤器,使其要么允许 statx() 系统调用,要么对其它不知道的系统调用返回 ENOSYS 错误代码。
sysstat 软件包中的 %vmeff 指标显示不正确的值
sysstat 软件包提供 %vmeff 指标来测量页面回收效率。sar -B 命令返回的 %vmeff 列的值不正确,因为 sysstat 不会解析后续内核版本提供的所有相关的 /proc/vmstat 值。要临时解决这个问题,您可以从 /proc/vmstat 文件中手动计算 %vmeff 值。详情请查看 为什么在 RHEL 8 和 RHEL 9 中 sar (1) 工具报告 %vmeff 值超过 100 % ?
sar 和 iostat 工具生成的 %util 和 svctm 列无效
当您在内核版本 4.18.0-55.el8 或更高版本的系统上使用 sar 或 iostat 工具收集系统使用情况统计数据时,sar 或 iostat 生成的 %util 和 svctm 列可能包含无效的数据。
Jira:RHEL-23074[1]