RHEL 9.4 启动死锁故障排查：误导入低版本 GLIBC 核心库导致系统瘫痪的抢救实录

前言

在企业级 Linux 服务器运维中，由于强行安装不兼容的第三方软件或误用低版本配置源，偶尔会导致系统核心动态链接库（GLIBC）受损。由于几乎所有系统命令（如 bash, systemd, ls 等）都极度依赖 GLIBC，一旦其损坏，系统将在启动切换根目录（Switch Root）时瞬间死锁。

本文记录了一次在 HPE ProLiant Gen10 服务器上，成功抢救因误导入 RHEL 7 的 glibc-2.17 导致 RHEL 9.4 瘫痪的完整排查与修复过程。

一、故障现象

在一台 HPE 服务器上，Red Hat Enterprise Linux 9.4 卡死，重启时发生死锁：

图形界面：重启卡在 HPE 厂商 Logo 及下方转圈界面，随后转圈停止，完全死锁。
文本跑码：在 GRUB 阶段去掉 rhgb quiet 参数后，系统打印底层日志。

开机看到 RHEL 的内核选择菜单时，赶快按上下键停住。
选中第一行内核，按 e 进入编辑。
找到以 linux 或 linuxefi 开头的那一行，把末尾的 rhgb 和 quiet 彻底删掉。
在这一行的末尾加上：pci=nomsi 或者 nomodeset（防止显卡驱动死锁）。
按 Ctrl + x 启动。

目的：此时系统不会再显示 HPE Logo，而是直接显示黑底白字的跑码。看它最后停在哪个驱动（比如 mpt3sas、smartpqi、lpfc 或 megaraid），那它就是罪魁祸首。

在显示 Reached target Switch Root. 并准备交接系统控制权的一瞬间，抛出如下致命报错后彻底卡死：

[    8.753971] systemd-journald[388]: Received SIGTERM from PID 1 (systemd).
/bin/bash: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /bin/bash)

二、问题分析与定性

报错信息清晰地指出了病因：

核心矛盾：/bin/bash 在启动时去加载系统的 C 语言标准库（GLIBC）libc.so.6，但发现库内缺少它所必需的 GLIBC_2.25 符号分支。
版本冲突：RHEL 9.4 原生自带的 GLIBC 版本为 2.34，而报错提示找不到 2.25。通过救援模式底层查看，发现系统的 libc.so.6 竟然被降级指向了 libc-2.17.so（这是 RHEL 7 的标准库）。
根因推断：前期的某次大批量 RPM 包安装或环境迁移过程中，由于依赖项冲突或脚本误操作，误将老旧系统的 lib64 核心库覆盖到了这台 RHEL 9.4 主机上，导致系统在新旧版本严重串线后彻底丧失启动自理能力。

三、核心抢救步骤（实战复盘）

由于原系统内的 bash 已经瘫痪，任何常规的单用户模式均无法进入。必须使用 RHEL 9.4 官方原厂 ISO 镜像 进入救援模式，并在光盘提供的健康 Shell 环境下向原系统“强行输血”。

步骤 1：引导进入 Rescue 救援模式

通过 HPE iLO 的 Virtual Media（虚拟介质） 挂载 RHEL 9.4 ISO 镜像。
开机按 F11 进入 Boot Menu，选择从虚拟光驱引导。
依次选择 Troubleshooting -> Rescue a Red Hat Enterprise Linux system。
在弹出的挂载提示中选择 1) Continue。此时原系统会被安全地挂载到 /mnt/sysroot 目录下。

⚠️ 注意：此时千万不能执行 chroot /mnt/sysroot，因为原系统的 bash 是碎的，一旦 chroot 会立刻报错退出。必须保持在光盘自带的 bash-5.1# 极简环境下操作。

步骤 2：强行向原系统灌入 RHEL 9.4 官方 GLIBC 库

在光盘环境下寻找原厂 RPM 包，利用 --root 参数将干净的核心库强行覆写回原系统，绕过原系统受损的依赖链。

# 1. 寻找光盘内的 glibc 2.34 软件包路径（通常在 BaseOS 目录下）
find / -name "glibc-2.34*.rpm"

# 2. 强行灌入原系统（假设路径如下，务必加上 --force 和 --nodeps）
rpm -ivh --root=/mnt/sysroot /run/install/repo/BaseOS/Packages/glibc-2.34-100.el9.x86_64.rpm --force --nodeps

提示：安装进度走到 100% 后，说明原系统的核心动态链接库已重置回 2.34 版本。

步骤 3：验证并切入环境（Chroot）

当核心库文件补齐后，尝试切入原系统环境。如果无报错成功进入，说明修复已见曙光：

chroot /mnt/sysroot

进入成功后，系统提示符会改变。此时可以使用 yum history 调取历史记录，即可坐实前几天导致 1400 多个包异常变动的“内鬼”操作。

步骤 4：清理残留与固化动态链接（至关重要）

为了防止重启后由于新旧库残留导致动态链接器（Program Loader）混乱，必须在 chroot 环境内完成最后的清理：

核对动态链接器状态：
执行 ls -l /lib64/ld-*，确认 RHEL 9.4 的原厂动态链接器实体文件 ld-linux-x86-64.so.2（约 850KB）完好无损，且没有错误地指向 2.17。

扬弃带毒的旧库残留：

rm -f /lib64/libc-2.17.so
rm -f /lib64/ld-2.17.so

强制刷新全局动态链接缓存：
```
ldconfig
```

步骤 5：正常断开引导并重启

完成上述收尾后，安全退出并重启硬件：

exit   # 退出 chroot
reboot # 重启服务器

在 HPE iLO 中卸载（Unmount）ISO 镜像。服务器重新引导本地硬盘，RHEL 9.4 顺利亮起登录界面，死锁解除。

四、运维经验总结与防范

慎用强制覆盖参数：在生产环境中执行 rpm 安装时，除非明确知晓后果，否则严禁随意组合使用 --force --nodeps，这极易撕裂系统底层级联依赖。
多版本共存陷阱：在编译老旧软件或迁移旧业务时，切勿图省事直接将高版本系统的 /lib64/libc.so.6 软链接强行改向低版本实体文件。系统全局对 GLIBC 具有向后兼容性，但绝对无法向前兼容。
善用厂商管理工具：依托 HPE iLO 的 IML 日志可以第一时间排除是否由阵列卡崩盘或多路径（Multipath）超时引起的物理死锁，从而把排查精力精准聚焦在系统软件层。

分类：Linux 运维 / 故障排查 / HPE服务器 _标签：RHEL9, GLIBC, 救援模式, 阵列卡, 运维实战_

前言

一、 故障现象

二、 问题分析与定性

三、 核心抢救步骤（实战复盘）