GRUB rescue 引导故障排查与 Linux 引导重建指南

1. 卡在 grub rescue> 到底意味着什么

grub rescue>是 GRUB 2 在自身运行环境被破坏后,退无可退的一个极简 shell,它没有任何菜单、没有主题、没有tab补全的舒适体验,只有一小撮内置命令。很多人第一次看到error: unknown filesystem紧跟着Entering rescue mode...和grub rescue>这几行白字黑底,第一反应是系统盘废了、数据没了、得重装。实际我在处理这类问题的经验里,九成以上都只是引导阶段某个环节读错了位置,系统文件、/etc、家目录一个字节都没动过。换句话说,这是“门锁坏了”而不是“房子塌了”。

这篇内容我打算讲清楚三件事:GRUB 从固件手里接过控制权之后到底按什么顺序找东西、在rescue>提示符下怎么用几条命令把它救回来、以及从 Live 环境进去之后怎么把引导彻底重建到不会再犯。适合刚装完双系统就撞上黑屏的初学者,也适合要维护一屋子机器、迟早会被叫去救火的运维。命令以通用写法给出,不同发行版家族的差异我会单独标出来,你照着抄基本不会错。

1.1 从按下电源键到出现登录框,中间这几百毫秒发生了什么

想修好一个东西,得先知道它的工作顺序。GRUB 2 的启动被切成好几段,每一段都是一段几十 KB 的机器码,它们像接力赛一样把控制权往下传,任何一棒掉链子,都会直接落到 rescue。

第一棒是固件。传统 BIOS 模式下去读磁盘最前面 512 字节的主引导记录,也就是 MBR,里面前 446 字节是boot.img。UEFI 模式不玩这一套,它去读 EFI 系统分区里那个.efi文件,通常是grubx64.efi,或者走shimx64.efi的中转。所以第一个关键区别:Legacy 依赖磁盘最开头的扇区,UEFI 依赖一个 FAT 分区里的文件。这决定了后面两种模式的修复命令完全不一样。

第二棒是core.img。Legacy 下它被塞在 MBR 之后的空隙扇区里(通常是第 1 到第 31 扇区),UEFI 下它是嵌在.efi文件内部的一个模块。core.img里最要命的是两样东西:能识别文件系统的最小驱动,以及一个硬编码的prefix变量。这个prefix长得像(hd0,gpt2)/boot/grub,它告诉 GRUB“去这块盘的第二个分区、路径/boot/grub下面找我的主程序”。注意,这里是硬盘序号加分区号,不是 UUID。

第三棒是normal.mod。GRUB 拿着prefix去对应分区里找normal.mod,加载成功后进入 normal 模式,才会去读grub.cfg、渲染菜单。所有“能不能救”的分水岭就在这一棒:找到了,你看到蓝色菜单;找不到,你就看到rescue>。

第四棒才是内核。GRUB 从grub.cfg里拿到linux和initrd两行,把vmlinuz和initrd.img(RHEL 系叫initramfs-*.img)加载进内存,跳到内核入口。到这一步之后,磁盘挂载、systemd启动、登录界面,全都是操作系统自己的事了,GRUB 已经退场。

所以grub rescue>出现的位置非常明确:它一定发生在第三棒之前。你的内核没坏,根文件系统没坏,坏的只是“GRUB 找不到自己的家”这件事。

1.2 为什么它不给你一个完整 shell,而是卡在 rescue>

原因很朴素:rescue模式下能用的模块极其有限。normal.mod没加载,意味着读取配置文件、解析菜单、支持所有文件系统驱动的能力都不在。剩下来的命令大概只有set、unset、ls、lsmod、insmod、source这几类,加上一点点echo。没有cd,没有cat,没有mount。很多人下意识敲ls /boot,结果报错,就是因为ls在这里的语法是ls (hd0,gpt2)/boot,括号里的设备标识不能省。

这种“残疾”状态其实是设计上的保守。GRUB 不敢在这种时候自动乱猜分区,因为猜错的代价是把引导写到别的盘上去,可能顺带毁掉另一个系统的启动项。它选择停下来,把决策权交给人。你要做的,就是替它把这几个变量补对。

2. 动手之前先把现场摸清楚

我最怕看到的一种操作是:一看到rescue>就开始凭记忆敲set root=(hd0,1)然后insmod normal。如果这台机器上挂了两块盘、/boot又是独立分区,这么敲十有八九是白忙一场,甚至会把变量改得更乱。花两分钟先把磁盘拓扑看清楚,后面的每一步都能省一半力气。

2.1 用 ls 遍历硬盘与分区

在rescue>后面直接敲一个不带参数的ls,它会列出所有被识别到的设备:

grub rescue> ls (hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,msdos1)

读法是这样的:hd0是第一块硬盘,hd1是第二块。硬盘编号从 0 开始,这一点和 Linux 里的/dev/sda从 a 开始对应得上,但不保证顺序一致——固件报告的枚举顺序,和内核探测出来的顺序,偶尔会不一样,这正是很多人“明明盘没问题却引导失败”的根源之一。

分区命名有两种:gpt1、gpt2表示这块盘是 GPT 分区表,编号从 1 开始;msdos1到msdos4是 MBR 的主分区,msdos5往上才是逻辑分区。如果你看到(hd0,msdos5),心里要有数:这是扩展分区里切出来的逻辑分区,/boot落在逻辑分区上、随后被某些工具搞乱,是历史上非常经典的一个坑。

接着逐个探测。对每个候选分区敲ls (hd0,gpt2),它会回一行信息:

grub rescue> ls (hd0,gpt2) (hd0,gpt2): Filesystem type ext*, UUID 3f2a...

这一行信息量极大。Filesystem type告诉你 GRUB 认不认这个文件系统,如果是unknown filesystem,说明要么这个分区压根没格式化,要么文件系统 GRUB 的内置驱动不支持(比如某些很新的特性、或者用了btrfs的某些子卷布局)。UUID则是你后面核对/etc/fstab的钥匙,先抄下来。

判断哪个是根分区,有个很土但很好用的办法:在分区路径后面加/etc,能列出来东西的那个,基本就是根。同理ls (hd0,gpt1)/grub能列出来的,那就是/boot所在的分区——注意如果/boot是独立分区,grub目录在它的一级目录下;如果不是独立分区,grub目录在根分区的/boot/grub。

2.2 分清 /boot 是否独立,这一步决定了 prefix 怎么填

这是最容易搞混的一点,我把两种情况的取值列清楚:

判断方法很简单:ls (hd0,gpt1)/如果直接看到vmlinuz-xxx、initrd.img-xxx、grub这几样并排出现,那这个分区就是独立的/boot。如果看到的是bin、etc、home、usr这种,那它是根分区,grub目录还得再往/boot下面找。

注意:很多“按教程敲了没反应”的情况,就是把独立/boot的机器按非独立写法填了 prefix,GRUB 跑去/boot/grub/grub找,当然找不到。

2.3 三类典型报错的含义对照

rescue>上面前一行通常会有一句具体的错误,别忽略它,它是唯一的诊断线索。

i386-pc和x86_64-efi这两个目录名,就是 GRUB 记录自己“是用哪种模式装的”的印记。看到i386-pc说明当初装的是 Legacy,看到x86_64-efi说明是 UEFI。这个细节在最后重建引导时非常关键,搞反了会导致“修完了还是进不去”。

3. 先救活:rescue 提示符下的手工引导

现场摸清楚之后,先别急着找 U 盘做个 Live 环境。如果只是prefix指错了,在rescue>里敲五六行就能把系统拉起来,进系统之后再从容地做永久修复。这条路我走过很多次,快的时候三分钟搞定。

3.1 set root 与 set prefix 的正确取值逻辑

顺序不能反。先把root设成包含grub目录的那个分区,再把prefix设成从该分区根开始的完整路径:

grub rescue> set root=(hd0,gpt2) grub rescue> set prefix=(hd0,gpt2)/boot/grub grub rescue> ls $prefix

最后那行ls $prefix是个自检动作,能列出normal.mod、grub.cfg、i386-pc(或x86_64-efi)这些东西,说明路径对了。如果报unknown filesystem,说明root指错了;如果报not found,说明prefix后面的路径写错了,常见的是多写或少写一层boot。

有个细节值得说:这里的分区号是当前固件枚举出来的顺序,它可能和你印象里的/dev/sda不一致。如果你插了一个 U 盘又没拔,或者主板上有 NVMe 加 SATA 混插,hd0很可能已经不是系统盘了。这种情况下,靠ls一个个试是最稳的,别看编号猜。

3.2 insmod normal 与绕道直接加载内核

路径对了之后,加载主模块:

grub rescue> insmod normal grub rescue> normal

第一条把normal.mod拉进内存,第二条切进正常模式。顺利的话屏幕上会刷出菜单,你选默认项回车,系统就起来了。这两条命令的意义在于:它们只是临时把 GRUB 拉起来,硬盘上的core.img一个字节都没变。所以下次重启,大概率还是rescue>。这就是为什么救活之后必须做第 4 节的永久修复。

如果insmod normal报错,比如normal.mod文件本身丢了或者损坏了,还有一条更硬核的路:跳过 normal,直接手工加载内核。这需要先加载linux模块:

grub rescue> insmod (hd0,gpt2)/boot/grub/linux.mod grub rescue> set root=(hd0,gpt2) grub rescue> linux /boot/vmlinuz-6.8.0-xx-generic root=/dev/sda2 grub rescue> initrd /boot/initrd.img-6.8.0-xx-generic grub rescue> boot

这里有两个坑。第一,vmlinuz后面的版本号必须和磁盘上真实存在的文件名一字不差,rescue模式下没有补全,只能靠ls (hd0,gpt2)/boot把文件名抄下来。第二,root=/dev/sda2这个设备名是给内核用的,它由内核自己解析,和 GRUB 的(hd0,gpt2)是两套编号体系,别混着写。RHEL 系的话文件名是vmlinuz-<版本>.x86_64和initramfs-<版本>.x86_64.img。

3.3 临时方案的天花板,以及什么时候别硬撑

手工set这套办法只解决“pointer 指错”这一类问题。如果根因是normal.mod真的丢了、文件系统有坏块、分区表本身错乱,你在rescue>里折腾一晚上也回不去。判断标准很直接:ls $prefix里明明能看到normal.mod,insmod却报错,那就别再试了,直接进 Live 环境。

还有一种情况要特别提醒:如果是/boot所在分区被整体格式化或者误删,insmod normal会失败,你可能想用linux直接引导,但只要内核文件也跟着没了,这条路同样堵死。这时候唯一的选择是从备份恢复/boot,或者重装内核包。所以我在任何机器上做完分区之后,第一件事就是把/boot整个目录打包丢到别的地方存一份,几十兆的事,救命的时候很值。

4. 根治:从 Live 环境重建引导记录

临时救活只是让你能进去把数据捞出来,真正的修复必须重写core.img里的prefix、重新生成grub.cfg,让下一次冷启动不依赖任何手工干预。这套流程我建议你至少完整走一遍,哪怕现在没坏——真出事的时候手是抖的。

4.1 挂载顺序与伪文件系统的坑

先做一个同版本的 Live 启动盘,从它启动,打开终端。第一步永远是认盘,不要凭/dev/sda的直觉:

lsblk -f

它会列出每个分区的文件系统类型、UUID、挂载点、以及 LVM 结构。对照你记下来的 UUID,确认哪个是根、哪个是/boot、哪个是 EFI 分区。如果这台机器有 LVM,还得先vgchange -ay把卷组激活,否则/dev/mapper/下面看不到逻辑卷。

然后是挂载,顺序有讲究:先挂根,再挂/boot,最后挂 EFI 分区。之所以这个顺序,是因为后挂的会覆盖前一个挂载点下的同名目录,如果先挂了 EFI 分区再挂根,EFI 里的内容会被根分区里的空目录盖住,后面grub-install就找不到它。

mount /dev/sda2 /mnt mount /dev/sda1 /mnt/boot # 若 /boot 独立 mount /dev/sda1 /mnt/boot/efi # UEFI 机器

接着把几个伪文件系统绑进去,这一步不做,chroot之后很多命令会报奇怪的错:

for d in /dev /dev/pts /proc /sys /run; do mount --bind $d /mnt$d done

/dev尤其重要,grub-install要往磁盘写引导扇区,没有/dev它连盘都看不见。/proc和/sys缺了会导致grub-mkconfig探测不到已安装的内核。我见过有人漏了/dev/pts,结果chroot进去之后终端没反应,以为系统死了,其实是伪终端没挂上。

4.2 chroot 里的两条修复路线

chroot /mnt /bin/bash

进去之后,先确认自己真的在目标系统里:cat /etc/os-release和uname -r对不上是正常的(内核还是 Live 的),但/etc下的发行版标识必须是你那台机器的。这一步确认完,再动手。

Legacy BIOS 路线:

grub-install /dev/sda grub-mkconfig -o /boot/grub/grub.cfg

RHEL 系对应的是grub2-install /dev/sda和grub2-mkconfig -o /boot/grub2/grub.cfg。Debian 系还有个update-grub的封装,本质就是调grub-mkconfig,输出路径它自己算,图省事可以用它。

UEFI 路线:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB grub-mkconfig -o /boot/grub/grub.cfg

--bootloader-id会影响 EFI 分区里目录名和固件启动项的名字,起个自己认得出的就行。如果这台机器开了 Secure Boot,还得加--uefi-secure-boot,否则签名的shim那套会缺文件,开机直接被固件拒绝。

两条路线最本质的区别在于:grub-install /dev/sda写的是磁盘的 MBR 和紧随其后的空隙扇区,而 UEFI 那条只往 FAT 分区里丢文件、顺带用efibootmgr注册一个启动项,完全不碰 MBR。反过来搞错,轻则无效,重则把好好的 MBR 覆盖成一堆垃圾。

4.3 修完之后必须做的三项验证

很多人grub-install一跑完就重启,结果还是rescue>,回来问我为什么。原因是grub-install只重写了引导代码和模块,grub.cfg还是旧的;或者反过来,grub-mkconfig生成了新配置,core.img里的prefix还是错的。两者必须都做,而且要验证。

第一项,看grub.cfg里的search --fs-uuid那几行,确认 UUID 和blkid输出对得上。第二项,ls /boot/grub/i386-pc/normal.mod(或x86_64-efi目录),确认模块文件在位。第三项,UEFI 机器跑一次efibootmgr -v,确认启动项顺序里你的系统排在第一位,而且指向的路径真实存在。

提示:如果是 UEFI 机器,修完之后一定要在固件设置里确认启动顺序。有过不止一次,引导修好了,但固件把某个已经拔掉的 U 盘排在第一位,开机照样黑屏,白折腾半小时。

4.4 参数与挂载点核对清单

重建引导之前,把这张表对一遍,能省掉绝大部分返工。

5. 那些年踩过的坑:五类高频翻车场景

同样的grub rescue>,背后的成因可以完全不同。按我处理过的频次排个序,下面这几类占了绝大多数。

5.1 双系统里另一个系统更新后引导被顶掉

装了两个系统的机器,某次其中一个系统打了大版本更新,重启直接进rescue>。原因通常是更新过程重写了 MBR 或 EFI 分区的默认引导文件,把 GRUB 的入口覆盖掉了,或者把core.img所在的空隙扇区当成空闲空间给占了。

处理办法就是走第 4 节的流程,从 Live 进去重装 GRUB。但有一个额外动作:重建完之后grub-mkconfig会重新扫描磁盘,把另一个系统的启动项也加回来。如果扫不到,说明os-prober被禁用了,Debian 系在/etc/default/grub里加一行GRUB_DISABLE_OS_PROBER=false再生成一次。UEFI 机器还要注意:两个系统各自的.efi文件都在同一个 FAT 分区里,重装 GRUB 时不要格式化EFI 分区,只覆盖文件就行。

5.2 磁盘克隆/换盘之后的 UUID 撞车

用工具把整块盘克隆到新盘,或者把系统迁到 SSD 上,开机进rescue>,报unknown filesystem或者干脆找不到分区。这类问题的本质是两块盘上出现了完全相同的 UUID,GRUB 的search --fs-uuid找到了“第一个”匹配的,可能偏偏是那块还没拔掉的旧盘。

在 Live 环境里用blkid扫一遍,如果看到两个分区 UUID 一模一样,就给新盘重新生成:

tune2fs -U random /dev/sdb2 # ext 系 xfs_admin -U generate /dev/sdb2 # xfs

改完之后,/etc/fstab、/etc/default/grub里的GRUB_CMDLINE_LINUX,以及/boot/grub/grub.cfg里的search行,全都要跟着改。只改 fstab 不改 GRUB,结果是内核启动参数找不到根,进了initramfs的(initramfs)提示符,那是另一个坑。最省事的做法是改完 UUID 之后立刻grub-mkconfig重生成配置,让它自己把新 UUID 写进去。

另外提醒一句:克隆迁移强烈建议只克隆分区,不要克隆整盘,或者在克隆完成后立刻把旧盘物理断开。我见过不止一次,两块盘同时挂在机器上,UUID 一样、分区表一样,GRUB 每次开机随机挑一块,时好时坏,排查了两天才发现是这个原因。

5.3 LVM、加密卷与软 RAID 的特殊处理

这几种布局下,rescue>提示符能看到的东西比普通分区少得多,因为读取它们需要额外的模块。

LVM 场景,先进 rescue 手动加载:

grub rescue> insmod lvm grub rescue> ls (lvm/vg0-root) (lvm/vg0-swap) ...

然后set root=(lvm/vg0-root),set prefix=(lvm/vg0-root)/boot/grub。要注意的是,如果/boot也在 LVM 里,那core.img每次启动都得先把 LVM 拉起来才能找到normal.mod,这要求安装 GRUB 时确实把lvm.mod打进了core.img。做法是grub-install之前确认/etc/default/grub里的GRUB_PRELOAD_MODULES包含 lvm,或者干脆把/boot单独划出来。从可靠性角度,我倾向于后者:独立/boot分区,200MB 到 1GB,省掉一大堆麻烦。

加密卷的情况更严格:GRUB 读不了 LUKS 加密的分区,除非专门开启GRUB_ENABLE_CRYPTODISK=y让它支持 cryptodisk。即便如此,开机要输两次密码(一次给 GRUB,一次给内核),体验很差。所以主流做法是/boot独立、不加密,只加密根分区。如果你接手一台/boot被加密的机器,又看到rescue>,基本可以判定这就是原因,只能靠 Live 进去解锁、挂载、修grub.cfg里的cryptodisk配置。

软 RAID 类似,core.img里需要mdraid09或mdraid1x模块,否则 GRUB 认不出/dev/md0。修复时先mdadm --assemble --scan把阵列组装起来,再走标准流程。

5.4 分区表从 MBR 换成 GPT 之后编号全乱

这是一个隐藏很深的坑。有人用工具把 MBR 转成了 GPT(通常是为了支持大于 2TB 的盘),分区数据没丢,但 GRUB 里的硬编码prefix还写着(hd0,msdos1),而实际设备已经变成了(hd0,gpt1)。这种情况下rescue>报的是no such partition,因为msdos1这个设备名在新分区表下不存在了。

临时救法是把set root和set prefix换成gpt写法,进去之后重新grub-install。但要注意,MBR 转 GPT 之后原来的引导扇区位置全变了,grub-install必须重跑一遍,不能只grub-mkconfig。还有一点容易被忽略:GPT 磁盘在末尾有一份分区表备份,某些分区工具操作完之后两份不一致,GRUB 读到的可能是旧的那份,表现为“改完重启又变回去”。这时候用gdisk的修复功能把备份表同步一下。

5.5 插着 U 盘或移动硬盘就进 rescue

这条听起来很傻,但发生率不低。固件枚举磁盘的顺序受外接设备影响,插了个 U 盘,它可能变成hd0,系统盘退到hd1,而core.img里写死的(hd0,gpt2)就指到了 U 盘的一个分区上,自然找不到normal.mod。

临时救法是在rescue>里把编号改成hd1试一遍。永久解法是进系统后重新跑grub-install,但要注意:如果每次插拔设备编号都会变,那grub-install也治不了根,因为你没法保证写入时的编号和下次开机时一致。真正稳的思路是让 GRUB 用 UUID 定位——grub.cfg里的search --fs-uuid本来就是干这个的,问题只出在core.img的硬编码prefix上。所以一个更保险的工程习惯是:开机前别插不相关的移动设备;或者在固件里把系统盘的启动优先级固定下来。

6. 排查速查表与善后工作

修好一次不算本事,让它别再坏、坏了能十分钟定位,才是能拿得出手的东西。这一节把上面零散的经验收成两张表,再讲讲我自己的几个习惯动作。

6.1 现象对照与快速处置表

用这张表的时候有个技巧:先在rescue>里把错误原文完整抄下来。很多人只记得“卡在黑屏”,具体是哪一行报错全忘了,回来描述的时候只能说“就是进不去”,那排查就只能从零开始猜。

6.2 把引导做成可回滚的

我现在接手任何一台要长期跑的机器,做完分区之后会立刻做三件事,加起来不超过五分钟,但能省掉未来几小时的焦虑。

第一件,备份引导扇区。Legacy 机器执行dd if=/dev/sda of=/root/mbr.bak bs=512 count=1,把前 512 字节存下来,出问题时dd回去就能恢复到一个“能进 rescue”的起点。第二件,UEFI 机器直接把整个/boot/efi打包:tar czf /root/efi-backup.tar.gz -C /boot/efi .,几十兆,连启动项文件带目录结构一起留着。第三件,把blkid、lsblk -f、efibootmgr -v三个命令的输出存成一个文本文件,放在/root下面。这个东西的价值在于:出问题时你不用再靠回忆去猜当初的分区布局,照着文件念就行。

还有一条更省事的经验:如果你的发行版支持grub-btrfs之类的快照集成,把根分区做成btrfs加定时快照,grub.cfg里会自动多出“从某个快照启动”的菜单项。哪次升级把引导搞坏了,直接从快照进去回滚,比拿 Live 盘折腾快得多。

6.3 我自己的几条习惯

最后说几条纯经验,文档里一般不会写。

第一条,别在引导出问题时第一时间重装系统。我见过太多人因为rescue>重装了整台机器,数据全丢,而实际上问题只是 prefix 里的一个字符。GRUB 卡在 rescue 恰恰说明它连自己的模块都没加载,它一个字都没往你的磁盘上写。冷静下来先把盘挂载读一遍,数据大概率完好。

第二条,更新内核之后,别只看“命令没报错”就当成功。跑一次ls -l /boot/vmlinuz-*和df -h /boot,确认新内核文件真的落盘了、/boot没满。/boot撑爆导致内核只写了一半,是升级后进 rescue 的另一个常见成因,而且报错信息往往误导人。

第三条,修好之后立刻重启验证一次,别拖。有些修复动作(比如grub-install写 MBR)在chroot里看着成功,实际因为/dev没挂全而静默失败,只有真正冷启动一次才能确认。验证完之后,再把这次的错误原文和处置步骤记一条笔记,下一次遇到同类问题时,这条笔记能帮你省掉一半时间。