如何解决RHEL系统启动时GRUB故障？

Question

问题：RHEL系统启动时出现“error: no such partition”或直接进入grub>命令行提示符，无法正常加载操作系统。该问题通常由GRUB配置文件损坏、磁盘分区表变更或/boot/grub2/grub.cfg丢失导致。如何在无图形界面的情况下，通过救援模式重建GRUB2引导配置并修复启动？需涉及使用chroot环境、重新安装grub2及生成配置文件等关键步骤。

Answer 1

一、问题背景与现象分析

RHEL（Red Hat Enterprise Linux）系统在启动过程中若出现 error: no such partition 或直接进入 grub> 命令行提示符，通常意味着引导加载程序 GRUB2 无法定位到正确的分区或配置文件。这种故障常见于以下场景：

• 磁盘重新分区或调整了分区表（如使用 fdisk/gdisk 修改）
• /boot/grub2/grub.cfg 文件丢失或损坏
• 操作系统更新中断导致 GRUB 配置未正确生成
• 物理磁盘更换或虚拟机磁盘迁移后设备映射变化
• 误删除或覆盖了 MBR/GPT 引导扇区

该问题直接影响系统的可启动性，尤其在生产环境中可能导致服务长时间中断。

二、修复思路与技术路径

为恢复系统正常启动，需通过救援模式挂载原系统根目录，并在 chroot 环境中重建 GRUB2 引导配置。整个过程涉及以下几个关键阶段：

1. 使用 RHEL 安装介质进入救援模式
2. 识别并挂载原有根文件系统及 /boot 分区
3. 建立 chroot 环境以访问原系统上下文
4. 重新安装 GRUB2 到目标磁盘的引导扇区
5. 生成新的 grub.cfg 配置文件
6. 验证修复结果并重启测试

三、详细操作步骤

1. 启动至救援模式

插入 RHEL 安装光盘或 ISO 镜像，从 BIOS/UEFI 中选择该介质启动，进入如下菜单时选择 “Troubleshooting” → “Rescue a Red Hat system”。

2. 挂载原系统文件系统

系统会自动尝试查找可用的 Linux 安装。选择 “Continue” 将原系统的根分区挂载至 /mnt/sysimage。若自动挂载失败，则手动执行：

# 查看磁盘分区情况
fdisk -l

# 假设根分区为 /dev/sda2，/boot 为 /dev/sda1
mount /dev/sda2 /mnt/sysimage
mount /dev/sda1 /mnt/sysimage/boot

# 若使用 LVM
vgchange -ay
mount /dev/mapper/vg_root-lv_root /mnt/sysimage
mount /dev/mapper/vg_root-lv_boot /mnt/sysimage/boot

    

3. 进入 chroot 环境

为了使后续命令作用于原系统而非救援环境，必须切换根目录：

chroot /mnt/sysimage
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev

    

4. 重新安装 GRUB2

根据系统架构（BIOS 或 UEFI），执行不同的 GRUB 安装命令：

启动方式	命令
BIOS（传统MBR）	grub2-install /dev/sda
UEFI	grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=redhat

5. 生成新的 grub.cfg

运行以下命令重建引导配置文件：

grub2-mkconfig -o /boot/grub2/grub.cfg

    

该命令将扫描所有内核镜像并生成标准的多入口菜单。

四、诊断与验证流程图

graph TD
            A[系统启动报错: no such partition] --> B{是否能进入救援模式?}
            B -->|是| C[挂载根与/boot分区]
            B -->|否| D[检查介质完整性]
            C --> E[chroot进入原系统]
            E --> F[执行grub2-install]
            F --> G[运行grub2-mkconfig]
            G --> H[退出chroot并重启]
            H --> I[验证能否正常启动]
            I -->|成功| J[修复完成]
            I -->|失败| K[检查设备UUID或fstab]

五、高级排查建议

在复杂环境中，还需考虑以下因素：

• UUID 不匹配： 使用 blkid 检查实际分区 UUID 是否与 /etc/fstab 和 /boot/grub2/grub.cfg 中一致
• EFI 系统分区缺失： UEFI 模式下需确保存在 FAT32 格式的 ESP 分区（通常为 /boot/efi）
• LVM/RAID 支持： 救援环境需激活逻辑卷组和阵列设备
• Secure Boot 影响： 某些环境下需禁用或签名自定义模块
• 双系统干扰： 其他操作系统的引导器可能覆盖 MBR

可通过以下命令辅助诊断：

# 查看当前设备UUID
blkid

# 检查grub环境变量
grub2-editenv list

# 验证内核是否存在
ls /boot/vmlinuz-*