GRUB引导故障排查与修复实战：从grub＞到正常启动

开机，屏幕停在grub>提示符上，或者更惨一点，只剩一个飞快跳动的光标。折腾过 Debian 的人十有八九都经历过这种时刻，尤其是那些装了双系统、或者手滑动过分区的用户。GRUB 引导故障听起来很可怕，但绝大多数情况下它并不是硬件损坏，也不是系统文件彻底完蛋，只是“引导链路的某个环节断了”，大概率可以在 30 分钟内修好。

这篇文章不谈空泛的理论，我按自己实际修过的一堆案例来写。先帮你根据屏幕症状判断故障发生在哪一环，再讲 Live 环境下的 chroot 修复主流程，以及不插 U 盘时的 GRUB 命令行手工引导方法，最后附上速查表和日常预防经验。适合所有 Debian 系用户阅读，不管你是第一次遇到grub>还是已经修过几次，都能在里面找到能直接用上的命令和避坑点。

1. 先分清“坏在哪”：GRUB 故障的几种典型症状与成因

1.1 三种屏幕状态分别代表什么

同样是引导失败，屏幕给的信息完全不一样，对应的问题环节也是天差地别。

第一种是直接进入grub>命令行。GRUB 已经加载起来了，但它找不到或者读不了/boot/grub/grub.cfg这个配置文件。这种情况常见于手改 grub.cfg 改坏了、grub.cfg 文件损坏、或者/boot分区被意外格式化。好消息是基础引导程序还活着，手工敲命令就能救。

第二种是进入grub rescue>救援模式。这个更麻烦，说明 GRUB 连自己的核心模块和正常模式都加载不了。常见原因是分区表发生变化，比如删过分区、重装过 Windows、用分区工具调整过分区大小，导致 GRUB 记录的“下一阶段模块所在位置”找不到内容。rescue>模式下支持的命令非常少，传统 remedy 是插入 Live USB 进系统重新安装 GRUB。

第三种是开机后直接黑屏、或者卡在主板 Logo 后没有任何反应。这种其实不一定全是 GRUB 的问题，还可能是 Secure Boot 设置、UEFI 引导项丢失或者 GRUB 二进制文件损坏。需要进固件设置界面，或者在 Live 环境里检查 EFI 启动项。

还有一种常见情况是在内核加载到一半后进入一个 BusyBox 命令行，屏幕提示(initramfs)。别慌，这其实已经过了 GRUB 阶段，问题出在内核或者 initramfs 无法挂载根文件系统。

1.2 用“最近做了什么”快速缩小范围

修 GRUB 有个特别好用的逻辑：回忆最近一次开机前你做了什么。别小看这一步，它能把排查范围缩小到一个很小的区域。

• 如果昨天刚安装完 Windows，今天 Debian 不见了，那几乎可以确定是 Windows 安装程序重写了 MBR 或者 UEFI 引导项。
• 如果刚才在 GParted 里调整过分区大小，那 GRUB 大概率去找原来的分区起始位置找不到了。
• 如果之前手动编辑过/etc/fstab改过 UUID，那可能根分区挂载失败，只是表现比较像 GRUB 问题。
• 如果升级内核到一半断电了，grub.cfg 可能还引用着不存在的新内核文件。
• 如果什么都没做，前一晚还在正常关机，第二天就进不去了，那先怀疑磁盘是否有坏道，再看 GRUB 文件是否损坏。

我见过不少人在不知道原因的情况下重复跑 grub-install，结果当然没用。先想清楚“接下来要干的事”是什么，再决定用什么修复手段，比盲目敲命令重要得多。

1.3 确认引导模式：BIOS 还是 UEFI

这是修复命令选择的分水岭，搞错了一步就会白折腾。在 Live 环境里打开终端，执行：

ls /sys/firmware/efi

如果目录存在且有内容，说明系统是以 UEFI 模式启动的；如果提示 No such file or directory，那就是传统 BIOS 模式。

BIOS 模式的 GRUB 安装在整块磁盘的 MBR 区域和第一个分区前的空隙里，修复命令是grub-install /dev/sda。UEFI 模式的 GRUB 则是以.efi文件的形式放在 EFI 系统分区里，修复命令完全不同，还需要指定 EFI 目录参数。这两条命令绝不能混用。

另外一个容易踩的坑是：Live USB 本身的启动模式会影响你看到的整机引导模式。如果你拿一个以 BIOS 方式启动的 Live USB，去修一个 UEFI 方式安装的系统，就算命令敲对也可能出现偏差。我在实际操作中会确保 Live 环境的引导模式和原系统一致，再开始操作。

2. 修之前先准备：Live 介质、认盘与风险兜底

2.1 准备一只 Live USB：工具选择与制作要点

手边必须有至少一个可以启动的 Linux Live 环境。Debian 官方 ISO、桌面版的普通安装镜像都能当 Live 环境用，或者用 SystemRescue、GParted Live 这类专用救援镜像。从服务器上拔下一块空闲 U 盘，用写盘工具把 ISO 写入 U 盘。

写盘时注意一个细节：写入目标要选 U 盘设备本身，而不是 U 盘里的分区。比如在 Linux 下用：

sudo dd if=debian-live.iso of=/dev/sdb bs=4M status=progress

这里的/dev/sdb是整个 U 盘，不是/dev/sdb1。Windows 下用写盘工具时也会遇到类似选择，选错了轻则写入失败，重则把移动硬盘数据清了。

我习惯做两只不同发行版的 Live U 盘，比如一个 Debian live、一个 Ubuntu live，交叉使用。因为不同发行版自带的工具版本和内核模块有差异，有时候 A 盘识别不了磁盘阵列，B 盘却能正常挂载。这不是玄学，是内核模块覆盖面的问题。

2.2 进入 Live 后的第一件事：识别磁盘和分区

启动到 Live 桌面后，先别急着挂载，第一步一定是看清楚磁盘结构。我一般连续执行两条命令：

lsblk -f blkid

lsblk -f能以树状结构显示磁盘、分区、文件系统类型和 UUID，blkid则能更精确地显示每个分区的属性。对于一块安装了 Debian 的硬盘，你通常能看到一个根分区（ext4 或 btrfs）、一个 EFI 系统分区（vfat），可能还有一个独立/boot分区。如果系统用 LVM 或 LUKS 加密，lsblk 还会列出卷组和加密设备。

如果你发现根分区明明存在，但在/dev/sd*下看不到，那可能是用了 LVM 或者较新的 NVMe 磁盘，先用lsblk找找有没有vg_开头的卷组。如果系统加密了，还需要先解密才能挂载。

2.3 动手前的备份优先级

进入 chroot 修复之前，先花两分钟把关键文件备份出去。这一步不是浪费时间，而是给自己留一条后路。因为后面执行的update-grub会用扫描结果重新生成grub.cfg，你之前辛苦手写进去的自定义启动项会被直接覆盖。

需要备份的文件至少包括：

• /boot/grub/grub.cfg（当前能用的引导配置）
• /etc/fstab（挂载配置）
• /etc/default/grub（GRUB 默认参数）
• /etc/grub.d/目录里的自定义脚本

最简单的方式是在 Live 环境挂载根分区后，把文件复制到 U 盘的其他位置。比如：

sudo mount /dev/sda2 /mnt sudo cp /mnt/boot/grub/grub.cfg /media/user/USB/grub.cfg.bak sudo cp /mnt/etc/fstab /media/user/USB/fstab.bak

如果你不确定某个文件是否需要备份，那就备份。多备份一个文件不会占用多少空间，但少备份一个可能让你后悔很久。

3. 标准修复主流程：Live 环境下的 chroot 重建 GRUB

3.1 挂载分区和非根目录：一步都不能少

现在真正进入修复。这一步的原理是：Live 环境本身是一个完整系统，我们通过 chroot 把当前终端的根目录切换到原 Debian 系统的根分区，然后在“原系统的视角”下执行 GRUB 修复命令。这样 grub-install 才能把引导写进正确的磁盘位置。

先把根分区挂载到/mnt：

sudo mount /dev/sda2 /mnt

如果你的/boot是独立分区，还要挂载：

sudo mount /dev/sda1 /mnt/boot

如果是 UEFI 引导模式，还需要挂载 EFI 系统分区：

sudo mount /dev/sda1 /mnt/boot/efi

注意上面的分区路径只是举例，必须根据实际情况调整。这里特别强调一个我踩过很多次的坑：很多新手只挂载了根分区就急着 chroot，结果 grub-install 时根本看不到 EFI 系统分区，报错信息让人一头雾水。

挂载完分区后，还需要绑定注入几个虚拟文件系统，否则 chroot 环境里看不到系统设备节点、进程信息等运行环境组件。命令如下：

sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run

/run这个目录经常被人忽略，但不绑定它，GNOME 桌面下某些grub-probe操作可能会报诡异的错误。绑定完成后再进入 chroot：

sudo chroot /mnt /bin/bash

进入之后，终端的提示符会变化，当前根目录已经切换为原系统的根。先执行mount -a看看 fstab 里有没有挂载报错。如果一切正常，就可以继续了。

3.2 解决 chroot 环境里的网络问题

如果你在 chroot 里需要安装或更新软件包，会发现网络可能不通。原因很简单：chroot 里没有/etc/resolv.conf或者它的内容不对，DNS 解析失败。从 Live 环境复制过去即可：

cp /etc/resolv.conf /mnt/etc/resolv.conf

这个操作在退出 chroot 后可以再恢复原样。不过对纯 GRUB 修复来说，一般不需要联网，除非你打算重装 grub 包或者内核包。

3.3 重新安装 GRUB：MBR 与 UEFI 的两套命令

这是核心中的核心。打开属于你的那套命令。

BIOS 引导模式下，指定目标磁盘整块安装：

grub-install /dev/sda

这里目标是/dev/sda，是磁盘本身，绝不能写/dev/sda1或/dev/sda2。GRUB 在 BIOS 模式下需要同时写 MBR 和嵌入区域，而这两个位置都属于“整块磁盘”的范畴。写错了会直接报错。

UEFI 引导模式下，需要指定 target 和 EFI 目录：

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian

--efi-directory必须指向 EFI 系统分区的挂载点（也就是包含EFI目录的那个位置），--bootloader-id是安装在 EFI 启动菜单里显示的名称，一般保持发行版名称即可。执行过程中如果报错EFI partition is not mounted，那就说明之前 EFI 分区没挂对。

UEFI 环境还有一个容易忽视的点：Secure Boot。如果主板开启 Secure Boot，而 grub 二进制没有经过签名，固件会拒绝启动。Debian 官方源的 grub-efi-amd64-signed 自带签名，可以应对这一场景。如果修复后仍然无法启动，进 BIOS 暂时关闭 Secure Boot 验证一下，能排除一大类问题。

3.4 生成引导配置：update-grub 与 grub-mkconfig

GRUB 程序安装完成后，还需要重新生成配置文件。否则安装程序写的空配置会让开机直接进入grub>命令行。Debian 系的习惯命令是：

update-grub

这个命令本质上是在执行grub-mkconfig -o /boot/grub/grub.cfg，它会扫描当前系统里的所有可引导内核，并把它们的启动菜单项写进去。遇到双系统还会尝试通过 os-prober 检测 Windows。

输出信息里有一行Found linux image: /boot/vmlinuz-xxx说明内核被正常识别。如果你之前是双系统环境，却发现输出里没有 Found Windows，很可能时新版 GRUB 默认禁用了 os-prober。修改/etc/default/grub：

GRUB_DISABLE_OS_PROBER=false

然后再次执行update-grub，就能在菜单里看到 Windows 启动项。这一步只影响菜单生成过程，不会改动 Windows 自己的引导文件。

3.5 收尾与重启：卸载顺序有讲究

所有修复命令执行完毕，先退出 chroot：

exit

然后按逆序卸载所有挂载点。先卸载 chroot 里的虚拟文件系统，再卸载分区，避免写入缓存丢失或设备占用报错。直接一条命令可以搞定：

sudo umount -R /mnt

如果提示target is busy，说明某个终端进程还停留在 chroot 页面里，关掉它再卸载。然后移除 Live USB，重启机器。如果一切顺利，应该能看到熟悉的 GRUB 菜单。

4. 没有 Live 介质时的最后一根稻草：GRUB 命令行手工引导

4.1 先搞懂 GRUB 的磁盘命名

手边没有 U 盘，或者不想大动干戈的时候，GRUB 自己提供的命令行可能就是唯一的希望。很多人看到grub>就慌了，其实它并不是无路可走，前提是你得懂它的设备命名规则。

Linux 系统里我们叫/dev/sda1、/dev/sdb2，GRUB 里则是(hd0,msdos1)、(hd1,gpt2)这种格式。hd0代表第一块磁盘，msdos1表示第一块 MSDOS 分区表下的第一个分区，gpt1表示 GPT 分区表下的第一个分区。和 Linux 设备名的对应关系基本是：hd0 对应 sda，hd1 对应 sdb，分区的数字则一一对应。

不要靠猜，直接用 GRUB 自带的ls命令确认即可。

4.2 用 ls 逐渐锁定根分区

在grub>提示符下输入：

grub> ls

GRUB 会列出它当前能识别到的所有磁盘和分区，例如(hd0) (hd0,msdos1) (hd0,msdos2)。接着逐一查看每个分区的内容：

grub> ls (hd0,msdos1)/

看到boot/、etc/、home/、usr/这些目录，就是 Debian 的根分区。看到vmlinuz-xxx和initrd.img-xxx的目录是/boot，如果它是独立分区则需要额外注意路径前缀。

4.3 手工敲入内核与 initrd

确定根分区后，设置 GRUB 的 root 变量：

grub> set root=(hd0,msdos2)

然后指定内核和 initrd。这里的路径取决于/boot是独立分区还是根分区下的目录。如果/boot是根分区的一部分：

grub> linux /boot/vmlinuz-6.1.0-10-amd64 root=/dev/sda2 ro quiet grub> initrd /boot/initrd.img-6.1.0-10-amd64

如果/boot是独立分区，则省略/boot前缀：

grub> linux /vmlinuz-6.1.0-10-amd64 root=/dev/sda2 ro quiet grub> initrd /initrd.img-6.1.0-10-amd64

root=参数指定真实根文件系统所在设备。建议用 UUID 替代设备名，因为/dev/sda2这种设备节点在启动早期不一定稳定。先查看grub.cfg里的写法，或者直接根据ls输出推断。

一切就绪后执行：

grub> boot

内核就会开始加载。如果这一步成功了，系统会继续执行正常的启动流程。

4.4 成功进入系统后怎么彻底修复

手工引导只是临时措施，是为了让你能进入系统。进去之后第一件事就是把 GRUB 安装配置重新做完整，不然下次开机还会停在grub>。

在系统终端里依次执行：

sudo update-grub sudo grub-install /dev/sda

UEFI 环境用对应的grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian。执行完后再重启，就能恢复正常的自动引导。

4.5 initramfs 阶段的救援提示

还有一部分人遇到的是 BusyBox(initramfs)提示符。这个过程已经越过 GRUB，是内核加载完但无法挂载根文件系统。屏幕通常会提示ALERT! UUID=xxxx does not exist。去检查/etc/fstab里面的 UUID 和实际情况是否一致。在 Live 环境下挂载分区后改正 fstab：

sudo mount /dev/sda2 /mnt sudo nano /mnt/etc/fstab

也可以用blkid查询正确 UUID 后替换错误值。如果 UUID 正确但文件系统模块缺失，则需要在 chroot 里重建 initramfs：

sudo update-initramfs -u

重建 initramfs 时会把你当前内核需要的磁盘驱动模块打包进去，能解决不少由于 initramfs 损坏导致的挂载失败。

5. 实战问题速查：症状 -> 原因 -> 解法

5.1 高频故障对照表

这在里我额外提一个结论：GRUB 修复的大多数失败，不是命令难，而是“没有按正确顺序执行”。比如没挂载 EFI 分区就运行 grub-install，或者没绑定虚拟文件系统就 chroot，这些低级错误远比命令行本身的难度更费时间。

5.2 双系统用户特别提醒

Windows 和 Linux 双系统环境下，GRUB 故障的诱因往往来自 Windows 一侧。Windows 重装、Windows 更新、甚至磁盘管理工具里的“修改分区”操作，都可能重写引导记录，让 Debian 从启动菜单里消失。

这种场景下，chroot 里执行grub-install和update-grub依然是最稳的方案，但有两个细节要额外注意。

第一个是 os-prober 问题。Debian 出于安全考虑，在某些版本里默认禁用了 os-prober 执行。如果你在 update-grub 的输出里看不到 Windows 相关条目，就去/etc/default/grub里设置GRUB_DISABLE_OS_PROBER=false，然后再次生成配置。

第二个是 UEFI 引导项问题。Windows 重装有时不会清除其他系统，只是调整了 EFI 启动顺序。在 Live 环境里可以用efibootmgr看看固件启动项：

efibootmgr

输出里会列出所有 UEFI 引导项。如果 Debian 条目还在，只是排序靠后，可用efibootmgr -o调整顺序。如果条目消失，chroot 里的grub-install --bootloader-id=debian会重新创建一个。

5.3 这些低级错误我见得太多了

把grub-install目标写成分区而不是整块磁盘。grub-install /dev/sda1在 BIOS 模式下几乎一定失败，而且失败信息看起来像硬件故障。记住，BIOS 模式的目标永远是整块盘。

挂载完根分区后忘记--bind /dev就 chroot。这会直接导致在 chroot 里执行grub-install时cannot open /dev/sda，明明设备存在却看不到。挂载命令只是多了两行，省不得。

手写修改grub.cfg后没有备份原文件。GRUB 对配置文件语法宽容，但一个括号漏掉或引号写错，就可能把整个菜单破坏，开机直接跳grub>。我一直强调的规矩是：正常情况下不要直接编辑grub.cfg，需要修改参数时编辑/etc/default/grub或/etc/grub.d/里的脚本，然后用update-grub生成。这样生成出来的文件就算出问题，也能随时重新生成，而不是手工改坏后无从下手。

还有一个非常典型的场景是：在 Live 环境里执行修复时，把 U 盘当成了目标磁盘，导致grub-install写到了 U 盘上。命令倒是执行成功了，但你拔掉 U 盘后系统依然无法启动。所以我每次在 Live 环境里都会先用lsblk确认哪个是系统盘哪个是 U 盘，再写命令。

6. 把损失扼杀在摇篮里：日常维护与预防

6.1 给关键文件做“快照式备份”

GRUB 相关文件并不大，但它们是系统启动的生命线。我现在的习惯是每次系统正常工作时，就把这几个文件打包一份存在系统盘之外的地方：

• /etc/fstab
• /etc/default/grub
• /etc/grub.d/
• /boot/grub/grub.cfg

一条命令打包：

sudo tar czf /root/grub-backup-$(date +%F).tar.gz /etc/fstab /etc/default/grub /etc/grub.d /boot/grub/grub.cfg

然后把 tar 包复制到另一块磁盘或网盘。即使某天 grub.cfg 被写坏，也能参考以前的正常配置快速定位改动点。另外建议把blkid的输出也存一份，以后查 UUID 变化时会很方便。

6.2 内核升级后的小心机

内核升级是 GRUB 故障的常见触发点。Debian 升级内核时会自动调用 update-grub，但如果/boot分区空间不足，内核镜像或 initramfs 写入会失败，有时还会留下半截文件，导致 GRUB 找不到完整的启动镜像。

定期清理旧内核是个好习惯，但清理时要留神。先看看当前系统用的哪个内核：

uname -r

然后有选择地删除旧内核包：

sudo apt autoremove --purge

顺便检查/boot分区使用率：

df -h /boot

如果空间紧张，除了删除旧内核，还要看看是否有大量孤立的 initrd.img 文件残留。这些文件一般不会自动清理，需要手动删除。注意只删除已经不被任何内核引用的旧 initrd，别误删最新版的。

6.3 我踩过的坑与个人体会

修 GRUB 这事实在是修得太多了，说几个让我印象深刻的。

有一回是同事的服务器，重启后卡在grub rescue>，系统里跑着数据库。一开始以为是分区表坏了，后来发现是他前一天用分区工具把 boot 分区“优化”了一下，导致 GRUB 找不到 core.img。最后从 Live 环境 chroot 进去重装 GRUB，数据完全没动，半小时解决。还有一次是某用户在家里电脑装了 Debian 和 Windows 双系统，Windows 一次大更新后引导菜单不见了，他差点重装 Debian 保 Windows。实际上只需要把 os-prober 打开重新生成一次配置，菜单就回来了。

我自己最大的体会是：遇到 GRUB 问题，心态比技术重要。不要一上来就想着重装系统，先冷静判断故障出现在哪个阶段。只要分区还在、文件还在，GRUB 就是一层软件，重装引导程序远远比重装系统成本低。备份的习惯越早养成，关键时刻越从容。