CentOS系统启动时卡在grub rescue界面，通常意味着GRUB第二阶段引导程序无法找到配置文件或所需模块。这个提示符虽然看起来吓人，但只要磁盘数据还在，多数情况下都能通过几条命令恢复。下面先给出一个典型的错误场景：开机后屏幕显示error: unknown filesystem.和grub rescue>，这说明GRUB找不到包含/boot/grub2目录的分区，可能是分区表损坏、UUID变更，或者安装新系统时覆盖了引导记录。
第一步：定位grub目录所在分区
进入grub rescue模式后，系统只加载了极小的命令行环境，很多命令都用不了。先执行ls命令查看当前能识别的磁盘和分区。直接输入ls回车，会列出类似(hd0) (hd0,msdos1) (hd0,msdos2)这样的设备名。如果你的磁盘是GPT分区表，会看到(hd0,gpt1)这样的标识。需要逐个分区尝试，找到包含/boot/grub2目录的那个分区。
可以使用ls (hd0,msdos1)/这样的命令查看分区根目录内容，如果出现boot、etc、usr等目录，说明这是根分区。如果只找到grub目录，可能分出了独立的/boot分区。定位到正确分区后，假设它是(hd0,msdos1)，执行以下命令设置前缀：
set root=(hd0,msdos1) set prefix=(hd0,msdos1)/boot/grub2 insmod normal normal
如果prefix路径设置正确，执行normal后就会进入正常的GRUB菜单，可以正常启动系统。但很多时候我们不知道具体分区，需要挨个测试。比如输入ls (hd0,msdos1)/boot/grub2，如果显示很多.mod文件和grub.cfg，就说明找到了。如果没有/boot独立分区，路径就是/boot/grub2；如果有独立/boot分区，则前缀直接是/grub2。务必确认清楚，否则insmod normal会报错。
第二步：手动引导内核进入系统
如果normal命令执行失败，或者虽然进入菜单但选择内核后仍然报错，可以手动指定内核和initrd文件来启动。首先用ls命令找到vmlinuz和initramfs文件的确切路径。在grub rescue下，输入ls (hd0,msdos1)/boot/，查看输出的文件名。通常CentOS 7的内核文件叫vmlinuz-3.10.0-1160.el7.x86_64，initrd叫initramfs-3.10.0-1160.el7.x86_64.img。记下完整文件名。
执行以下命令手动引导（注意版本号换成你自己看到的）：
set root=(hd0,msdos1) linux (hd0,msdos1)/boot/vmlinuz-3.10.0-1160.el7.x86_64 ro root=/dev/sda1 initrd (hd0,msdos1)/boot/initramfs-3.10.0-1160.el7.x86_64.img boot
这里root=/dev/sda1需要根据实际根分区设备名填写，可以用blkid或从之前的分区信息推断。如果/boot是独立分区，linux行和initrd行的路径要去掉/boot，比如linux (hd0,msdos1)/vmlinuz-xxx。启动成功后进入系统，需要立刻修复GRUB，否则下次重启还会卡住。
进入系统后打开终端，先挂载必要的文件系统，然后重新安装GRUB到主引导记录。对于BIOS+MBR方式：
grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg
对于UEFI+GPT方式，需要重新生成EFI引导项：
dnf reinstall grub2-efi shim grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
第三步：常见原因与预防措施
很多人进入grub rescue是因为/boot分区被误删除或格式化，比如在清理旧内核时不小心删除了整个/boot目录。另一种常见情况是磁盘顺序发生变化，比如在BIOS中调整了硬盘启动顺序，或者拔插了SATA线，导致GRUB记录的磁盘编号和实际不一致。还有安装双系统时，Windows的引导程序覆盖了MBR，使GRUB无法加载。
要减少这类问题，首先不要在系统运行中直接修改/boot分区的内容，删除旧内核使用yum remove或dnf remove，而不是手动rm。如果服务器有RAID卡或NVMe硬盘，确保GRUB配置中的设备名使用UUID而非/dev/sdX，因为设备名可能随加载顺序改变。可以通过修改/etc/default/grub中的GRUB_DISABLE_LINUX_UUID=false来强制使用UUID，然后重新生成配置。
另外建议备份主引导记录，对于MBR磁盘可以执行dd if=/dev/sda of=/root/mbr.bak bs=512 count=1，一旦MBR损坏，可以用LiveCD启动后恢复。对于UEFI系统，保证/boot/efi分区挂载正常，并且有备用启动项。如果条件允许，在服务器上配置带外管理（IPMI/iLO），这样即使系统无法启动，也能远程挂载ISO进行修复。
总结：从救援模式到彻底修复
grub rescue模式并不可怕，它只是GRUB在早期阶段找不到必要文件时的保护机制。通过ls命令耐心定位分区，配合set prefix和insmod normal，大多数情况下能直接恢复菜单。如果菜单无法使用，手动指定内核路径也能临时进入系统。进入系统后必须执行grub2-install和grub2-mkconfig，否则等于没修。整个修复过程的关键是准确识别分区和内核版本，不同CentOS发行版、不同磁盘布局的命令参数略有差异，但思路完全一致。
建议把本文的修复步骤记录下来，打印贴在机房或保存到运维知识库。当生产服务器出现类似问题时，先不要慌张，严格按照顺序操作，尤其注意不要随意执行grub2-install到错误的磁盘上，以免覆盖其他系统的引导记录。如果确实无法确定分区，可以用CentOS安装光盘进入救援模式，挂载根分区后使用chroot方式修复，那样会更加稳妥。
CentOSGRUB rescue引导修复修改时间：2026-10-04 07:22:38