1. 写在前面什么情况下你会用到这篇教程先聊点实际的。作为一个用了好几年 Debian 的普通用户我最怕的事情之一就是某天早上按下电源键屏幕亮了结果蹦出来一行GRUB rescue或者直接黑屏只留一个光标在那闪。那种感觉就是你明明没做错什么系统就是不给你进。说白了GRUB 就是 Linux 系统开机时的“领路人”。BIOS/UEFI 启动电脑后GRUB 负责找到内核、加载内核再把控制权交出去。如果 GRUB 出现问题就像你请了个向导结果向导自己先迷路了后面的行程自然全乱了。这篇教程能帮你解决的问题包括但不限于开机直接进入GRUB rescue提示符不知道输什么。开机卡在GRUB loading界面不动了。重装 Windows 之后 Ubuntu/Debian 的引导没了这是最常见的场景。修改 GRUB 配置后重启直接翻车连菜单都出不来了。分区调整、硬盘更换之后GRUB 找不到原来的启动文件。我写这篇东西的时候默认你的 Debian 系统本身还是完好的只是引导层出了问题——比如/boot/grub下的文件损坏了、MBR/EFI 引导记录被覆盖了、grub.cfg 配置错了。如果你的根文件系统本身也挂了那要先用 Live CD 把数据备份出来再回来看这篇文章。另外说明一下这篇教程主要针对 Debian包括树莓派上跑 Debian 的情况其实也有点类似不过引导方式略不同。Ubuntu、Linux Mint 这类基于 Debian 的发行版操作基本是通用的我习惯用一份方法通吃几个系统。文章里的命令我会说清楚哪条在什么环境下执行哪些改动是临时生效、哪些需要持久化。你要是遇到的具体情况跟我的不完全一样也别慌里面的核心思路都是相通的让 GRUB 能找到你的内核能读取根分区能正常加载配置。2. 故障初判先弄清楚 GRUB 到底坏在哪2.1 三种最常见的故障表现GRUB 出问题就像感冒分风寒风热一样症状不同病因和药方也不同。我按我实际遇到的情况帮你归个类方便你自己对号入座。第一种开机直接进GRUB rescue提示符这算是比较著名的一种。屏幕上会出现GRUB rescue这个状态说明 GRUB 代码本身还活着它被写在磁盘开头或者 EFI 分区里但它找不到/boot/grub这个目录更别说读取里面的配置和模块了。通常是你删了/boot分区、移动了分区、改了分区表或者用别的工具把磁盘重新分区了。也有可能是grub-install装刷了位置。在rescue模式下GRUB 只加载了最基本的模块很多命令不可用比如ls能用但insmod、normal这些都得看模块有没有被加载。这个状态不算最糟糕还有救。第二种开机卡在GRUB loading或者黑屏这种情况下你看到的是GRUB loading.然后光标一直闪烁或者直接黑屏没反应。这多半是 GRUB 的配置文件grub.cfg引用了不存在的路径、分区 UUID 对不上或者在加载某个模块时卡住了。还有一个常见诱因是你改了/etc/default/grub里的参数然后跑了update-grub结果生成了错误的配置——比如分辨率设得过高导致显示异常看着就像死机了。第三种直接跳进另一个系统通常是 Windows或者显示 “No bootable device”这个场景很多人应该在装双系统的时候经历过——Windows 更新之后把 GRUB 的引导记录给覆盖了开机直接进 Windows你的 Debian 仿佛人间蒸发。严重一点的开机直接提示No bootable device found这是引导器彻底丢了。之前那个“重装 Windows 把 Linux 引导搞没了”的经典故事说的就是这种情况。2.2 先摸摸底再动手别瞎敲命令无论是哪种故障第一件事不是着急敲命令而是确认你的系统里有哪些分区、它们分别是什么格式、原来的 Debian 装在哪儿。你总不能连自己系统装在哪都不知道就开始修复吧。我推荐的做法是拿一个 Debian/Ubuntu 的 Live USB 启动电脑进入体验环境然后打开终端执行lsblk这个命令列出所有块设备你会看到类似这样的输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 238.5G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 119.2G 0 part └─sda3 8:3 0 118.8G 0 part看到这个输出了你至少需要搞清楚三件事根分区是哪个一般是最大的那个 ext4 分区EFI 系统分区是哪个如果是 UEFI 引导模式一般是那个几百 MB 的 FAT32 小分区/boot是不是单独分区有的话一般是个 1GB 左右的分区如果你分不清哪个是根分区用blkid看文件系统类型和 UUID或者用lsblk -f直接看有没有标签。比如df -h mount | grep / 如果系统不能正常启动那就用 Live 环境挂载之后再看。我再强调一遍修复 GRUB 不是一个固定命令走天下的操作你得根据“引导模式”legacy BIOS 还是 UEFI、“是否有独立 /boot 分区”、“是否有独立 EFI 分区”这几个变量来选方案。下面我每个场景都会单独说你先确认自己是哪一类再把对应的方法抄走。3. 准备工作Live 环境与 chroot 的正确姿势3.1 UEFI 还是 Legacy这决定了一半修法动手修复之前你得先搞清楚自己机器的引导模式。2015 年之后再买的电脑绝大多数出厂默认 UEFI 引导但很多人装系统的时候会手工改成 Legacy也叫 CSM模式。引导模式不同GRUB 的安装位置和修复方式完全不同。怎么判断两个方法你选一个。方法一查看/sys/firmware/efi这个目录是否存在。在 Live 环境里打开终端执行ls /sys/firmware/efi如果存在这个目录里面不是空的说明你的机器处于 UEFI 模式。如果提示 No such file or directory那就是 Legacy BIOS 模式。方法二在已经装好的系统里跑efibootmgr能出结果就是 UEFI。我用这个判断标准的经验是UEFI 模式下GRUB 的修复方向是“找到 ESPEFI System Partition分区把 grubx64.efi 文件刷进去并且确保 NVRAM 启动项正确指向它”。Legacy 模式下GRUB 是针对整个磁盘来安装引导代码会被写到 MBR 区域。两种模式的命令是有差异的后面我会分开给。另外注意Live 系统本身的启动模式最好跟目标系统一致——如果你是 UEFI 机器那就确保 U盘 以 UEFI 方式启动否则可能出现你明明修好了重启还是进不去的情况那个坑很隐蔽。3.2 全程最好用的外壳chroot在 Live 环境里你的终端看到的是 Live 系统的文件系统要修复的目标系统文件没法直接用。这时候最可靠的方法就是 chroot把当前终端的根目录切换到目标系统的根目录上。一句话理解chroot 之后你在终端里的操作就好像直接站在了目标系统里能直接运行它原有的update-grub等工具也能正常访问原来的/boot目录。我用的是 Debian Live USB系统起来之后先按身份证信息挂载分区sudo mount /dev/sda2 /mnt假设/dev/sda2是你的根分区。接下来挂载boot如果/boot是单独的那就要sudo mount /dev/sdaX /mnt/boot如果/boot就在根分区里多数人是这种那这一步可以跳过。但如果你的根分区是在 LVM 卷组上那前头要多几步先激活卷组再找到逻辑卷路径再挂载。Debian 默认安装时给整块盘做 LVM 也很常见后面我专门说一下。挂载虚拟文件系统这一步别人可能不强调但我强烈建议你养成习惯否则某些操作会报奇怪的错误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如果是 UEFI 模式还需要挂载 EFI 分区如果没有独立 /boot 分区的话sudo mount /dev/sda1 /mnt/boot/efi挂完之后进入目标系统sudo chroot /mnt /bin/bash到这步你就进入了目标系统的终端。可以用df -h /确认一下当前根分区是不是目标分区。看到你原来的系统路径后面修复起来才安心。3.3 网络和 DNS 的问题顺手解决在 chroot 环境里系统默认 DNS 配置和网络状态可能跟 Live 环境不一致。如果你后面需要安装或重装grub-pc/grub-efi包那网络得通。chroot 进去后我习惯先测试一下ping -c 3 deb.debian.org如果 ping 不通域名但能 ping 通 IP那就是 DNS 没配好。写一个临时 resolv.conf 就行echo nameserver 1.1.1.1 /etc/resolv.conf提示别在这里纠结 DNS 服务器选哪个1.1.1.1 或者 2.2.2.2 这种公共解析服务都行重点是能解析域名就行。这个操作不会影响你修复后的系统因为修完后 Live 环境里的这个临时文件不参与目标系统的启动。4. 常规修复从 chroot 内重装 GRUB4.1 Legacy BIOS 模式下的重装方法进了 chroot 之后Legacy 模式修复其实就是一个核心动作——重新把 GRUB 引导代码写回磁盘的 MBR。我实际操作中这个步骤最后会执行grub-install /dev/sda注意这里是/dev/sda不是/dev/sda2这种分区路径。GRUB 在 Legacy 模式下要写在整块磁盘的主引导记录里写在分区上是不行的除非特殊场景。执行之前用lsblk确认你的磁盘路径如果在虚拟机里可能是/dev/vda或/dev/nvme0n1一个都不能错。如果你忘了 grub-install 需要对应主板固件类型的版本比如在 UEFI 机器上用了 BIOS 模式安装 Debian这种组合其实能开机但性质特殊一般不在讨论范围内。绝大多数情况下通过 Live 环境 chroot 后直接执行 grub-install 就行。执行完再更新 GRUB 配置update-grubupdate-grub 这条命令实际跑的是grub-mkconfig -o /boot/grub/grub.cfg它会扫描/etc/default/grub和/etc/grub.d/下的脚本生成新的grub.cfg。输出了类似于Found linux image: /boot/vmlinuz-6.1.0-... Found initrd image: /boot/initrd.img-6.1.0-...看到这行说明内核被正确发现了。如果没有这句输出说明/boot里根本没内核文件或者挂载有问题查一下再继续。最后退出 chroot卸载所有挂载点重启。稳妥起见我通常会这样卸载exit sudo umount /mnt/run sudo umount /mnt/sys sudo umount /mnt/proc sudo umount /mnt/dev sudo umount /mnt/boot/efi sudo umount /mnt如果umount提示 busy别慌大多数情况是你当前终端的工作目录还在 /mnt 下先cd /再卸载。这种小坑我踩过一次后来学乖了卸载前先确保不在挂载点目录里。4.2 UEFI 模式下的修复EFI 分区和启动项一个都不能少UEFI 模式修起来会多一步除了把 GRUB 文件安装到 EFI 分区里还得确保固件启动项指向正确的 EFI 文件。有时候你会发现 GRUB 文件都在但 NVRAM 里的启动项丢了导致主板不知道去哪找引导器。chroot 之后执行grub-installUEFI 模式下不带设备路径参数或少带设备路径参数也行它会自动检测 EFI 分区。如果系统里有多个磁盘为了保险你也可以指定磁盘grub-install /dev/sda然后照例update-grub注意观察输出中有没有类似这样的内容Installing for x86_64-efi platform.说明它安装的是 EFI 版本的 GRUB。之后检查一下 UEFI 启动项efibootmgr -v如果列表里没有 Debian 相关的启动项就手动创建efibootmgr --create --disk /dev/sda --part 1 --label Debian --loader \EFI\debian\grubx64.efi这里--part 1是指 EFI 分区在第一分区路径里的反斜杠是 UEFI 固件里的习惯写法跟 Linux 的正斜杠不一样注意别抄错。如果你之前见过\EFI\debian\shimx64.efi这个文件那建议 logo 指向它——如果你的主板开了 Secure Bootshim 是负责验签的引导器用它能少好些麻烦。4.3 如果你的根分区在 LVM 里面Debian 安装器默认就支持 LVM不少人装的时候没管直接默认配置结果根分区就在 LVM 里。这种分区结构本身没问题但在 chroot 前要先把 LVM 卷组激活。Live 环境下执行sudo apt update sudo apt install lvm2然后扫描并激活sudo vgscan sudo vgchange -ay之后lsblk里的设备路径就清晰了可以看到卷组下的逻辑卷比如/dev/vg0/root。挂载时这样挂sudo mount /dev/vg0/root /mnt逻辑卷路径怎么知道执行lvdisplay或者ls /dev/mapper/查看。这个场景我在朋友的一台老服务器上遇到过一次当时不熟悉 LVM 的流程卡了好久后来发现就是没装 lvm2 工具。你 Live 环境是完整版的 Debian 的话一般自带但精简版就可能缺记得自己按需装上。5. 当 GRUB 彻底罢工从 rescue 模式手动引导5.1 先搞懂 rescue 模式里能做什么有一种情况比较尴尬GRUB 的损坏程度已经导致所有自动修复路径都不通用了或者你暂时没有 Live USB只有面前这个GRUB rescue提示符。这种情况下你仍然可以用 GRUB 自己的命令手动引导进入系统后再修复。rescue模式说实话功能比较受限。它没有加载正常的模块所以像是normal、insmod这类命令需要自己找模块路径。你首先要做的是用ls列出所有分区GRUB rescue ls输出可能是(hd0) (hd0,gpt1) (hd0,gpt2) ...这种。接下来你要做的是找到哪一个是根分区、哪一个是 boot 分区。用ls (hd0,gpt2)/看看内容比如GRUB rescue ls (hd0,gpt2)/看到bin/ dev/ etc/ home/这些目录恭喜你这就是根分区。看到grub/ vmlinuz-* initrd.img-*这就是 boot 分区或 /boot 目录所在分区。5.2 手动引导到内核再反手修复找到根分区后比如根分区是(hd0,gpt2)boot 目录在它下面那就可以这样手动引导GRUB rescue set root(hd0,gpt2) GRUB rescue set prefix(hd0,gpt2)/boot/grub GRUB rescue insmod normal GRUB rescue normal如果normal能正常工作GRUB 会重新读取/boot/grub/grub.cfg菜单就出来了。这种方法的关键在于你得知道根分区是哪个还要保证/boot/grub里的模块文件还在。如果insmod normal报错说你没有这个模块那就说明 /boot/grub 里的模块文件已经损坏或缺失这时候只能靠加载 kernel 和 initrd 来引导了。做法如下先设置好根分区和 prefix然后逐条执行GRUB rescue set root(hd0,gpt2) GRUB rescue set prefix(hd0,gpt2)/boot/grub GRUB rescue insmod linux GRUB rescue linux /boot/vmlinuz-6.1.0-... root/dev/sda2 GRUB rescue initrd /boot/initrd.img-6.1.0-... GRUB rescue boot注意这里vmlinuz-6.1.0-...要替换成你实际的版本号root 参数要指定你的根分区设备路径。如果你不知道内核版本可以先ls (hd0,gpt2)/boot/查看。如果根分区的路径都变了、UUID 跟你原来 grub.cfg 里的对不上那手动引导成功后第一件事就是update-grub重新生成配置。5.3 rescue 模式引导成功的后续修复从 rescue 模式手动引导进入系统之后因为当前状态下 /boot 和 / 分区其实已经挂载好了你只需要在系统里重新跑一遍安装步骤sudo grub-install /dev/sda sudo update-grub这里 grub-install 的写法跟前面一样Legacy 选/dev/sdaUEFI 可以直接grub-install。如果你刚才在 rescue 模式里是靠 root/dev/sda2 这种格式手动指定的根分区系统起来后你可以在终端里确认一下自己的分区路径然后再执行上面的命令。提示手动引导只是“急救”不修根因的话下次开机还是会翻车。所以在系统能正常进之后这个修复动作一定要做。5.4 一种罕见的翻车initrd 找不到的情况我遇到过一种情况linux这行加载正常但 initrd 那步死活报错说什么 “file not found”。检查一下文件名发现/boot目录下 initrd 文件名是带版本号的但initrd.img这个软链接不见了。这种情况多半是之前有人清理/boot时把软链接删了或者在急救过程中看了错误的目录。处理办法也简单进入系统后重建软链接sudo ln -s /boot/initrd.img-6.1.0-... /boot/initrd.img sudo update-grub然后重启验证。我顺手提这个点是提醒你救援过程中看清楚文件名和软链接状态很多启动问题其实不是 GRUB 模块坏而是这些最基础的文件指向有问题。6. 双系统场景Windows 抢了引导怎么把 Debian 找回来6.1 为什么 Windows 一重装Debian 就“消失”了这个场景非常多见尤其是一台电脑同时装了 Windows 和 Debian。Windows 重装或大版本更新后它不会“好心”地在引导菜单里加上 Linux而是直接把自己的引导信息写在固件启动项最前面。对于 UEFI 模式Windows 会把 EFI 分区里的Microsoft目录重新弄一遍同时把BootOrder改成 Windows 优先对于 Legacy 模式Windows 更是直接把 MBR 里的引导代码覆盖成自己的。结果就是开机后 Windows 的引导管理器根本没有“其他操作系统”这个选项你的 Debian 还在硬盘里躺着只是没人去启动它。听起来像房子还在但是门的钥匙被换了。6.2 修复方法其实跟第 4 章完全一样不要被“双系统”这个标签吓到修复方法跟单系统 GRUB 损坏本质一致。你只需回到第 4 章做一遍完整的流程让 GRUB 重新接管引导顺序。我实际操作中的完整套路用 Live USB 启动记住以 UEFI 模式进入。挂载 Debian 根分区、EFI 分区chroot。执行grub-install此时它会检测到 Windows 的引导项。执行update-grub在输出里找到 Windows Boot Manager 相关条目。重启进入 GRUB 菜单选 Windows 或 Debian 都没问题。update-grub 能自动探测到 Windows 的 EFI 文件吗能。它通过os-prober工具来探测其他操作系统它在/etc/grub.d/30_os-prober这个脚本里。如果执行完 update-grub 之后没看到 Windows 条目大概率是os-prober没装或者执行权限不对。手动装一个sudo apt install os-prober sudo os-prober sudo update-grub有些新版本 Ubuntu/Debian 默认把 os-prober 功能关闭了需要在/etc/default/grub里加一行GRUB_DISABLE_OS_PROBERfalse改完再 update-grub 一次Windows 条目就出来了。这个坑我是在帮朋友修一台双系统电脑时遇到的新装的 Debian 12 更新完死活不认 Windows后来发现就是 os-prober 默认关闭了。6.3 一个更轻量的选择把 GRUB 放在优盘上有一个思路可能适合你——如果你不想动 Windows 的引导项只希望在需要时才切换到 Debian那可以考虑把 GRUB 装到一个优盘上平时优盘不插就直接进 Windows想要 Debian 时插上优盘从优盘启动。这个操作在 UEFI 模式下倒是挺简单的sudo grub-install --removable /dev/sdX注意/dev/sdX是你优盘的设备路径执行之后优盘上会生成EFI/BOOT/BOOTX64.EFI这种结构的文件主板从优盘启动时就会自动使用这个引导器。--removable选项的意思是让你把 GRUB 装到可移动磁盘上而不做固定磁盘路径的 NVRAM 设置。不过我个人不太推荐这种方式作为日常手段——优盘丢了、坏了或者临时找不着都是麻烦事。我更习惯的还是把 GRUB 全局接管引导顺序让 GRUB 菜单里同时列着 Debian 和 Windows想进哪个选哪个。7. 进阶修复grub.cfg 配置修改与内核参数调整7.1 grub.cfg 到底能不能手改说实话正常安装完的 Debian绝大多数人一辈子都不需要手动编辑/boot/grub/grub.cfg这个文件。因为它是由 update-grub 自动生成的手动改了之后下次一跑 update-grub改动就没了。那什么场景下需要手动改我遇到过两种系统根本启动不了必须从 Live 环境 chroot 进去检查/修改配置。内核参数需要临时/长期添加比如nomodeset绕开显卡驱动问题比如single进入单用户模式改密码都要改 grub.cfg 才能让内核带特定参数开机。如果只是临时加参数你可以在 GRUB 菜单界面按e编辑启动项找到linux那一行在ro quiet后面加上你想要的参数比如linux /vmlinuz-... root/dev/sda2 ro nomodeset然后按CtrlX或 F10 启动。这个修改是临时的重启失效。如果你需要让这个参数永久生效那就要改配置文件。Debian 的正确姿势不是在 grub.cfg 里直接改而是改/etc/default/grub里的GRUB_CMDLINE_LINUX_DEFAULT这一行。比如GRUB_CMDLINE_LINUX_DEFAULTquiet nomodeset改完之后sudo update-grub这样 grub.cfg 就会重新生成并且带上你要的参数。如果你确实需要在 grub.cfg 里做一次性修改比如临时修系统改完好歹记得马上执行 update-grub 回滚否则下次重启可能白改。7.2 一个实例显卡驱动崩溃导致开机黑屏这里我举一个亲身经历过的案例。有台机器装了新内核之后开机过了 GRUB 菜单就黑屏只能盲切到终端模式杀掉 X 服务才能进去。后来在 GRUB 菜单里加nomodeset参数后成功进系统。后来我去/etc/default/grub里把GRUB_CMDLINE_LINUX_DEFAULT那行改成GRUB_CMDLINE_LINUX_DEFAULTquiet splash nomodesetupdate-grub 之后从系统更新到驱动修复全程都没再黑屏。注意这种修改属于“绕过”显卡驱动之前的故障排查常用手段不是长期最优解。显卡驱动问题得找到根源解决——比如驱动版本不对、内核模块冲突——而不是永远靠 nomodeset 续命。7.3 默认等待时间和菜单隐藏问题有人喜欢把 GRUB 菜单的等待时间调成 0让系统直接秒进。但如果你手滑把GRUB_TIMEOUT0写在配置里你会发现开机时根本看不到 GRUB 菜单连按 Shift / Esc 都未必来得及呼出菜单。这时候想临时进别的系统或加参数都变得很难。保留默认的GRUB_TIMEOUT5我觉得是比较稳的如果你想快点调到 2 也行。还有个小技巧即使设置了GRUB_TIMEOUT0也可以在 GRUB 界面按Esc键呼出菜单——不过你只有极短的时间窗口看到 LOGO。为了保险我一般会留个 1~2 秒的缓冲时间别把自己逼得太绝。另外有个隐藏参数GRUB_HIDDEN_TIMEOUT在某些发行版里会出现Debian 默认一般不会设置。如果你从 Ubuntu 转过来注意检查一下这行是不是还在它会把菜单隐藏起来只显示倒计时。7.4 启动参数丢失的奇葩场景有时候你会发现连 grub.cfg 里的启动参数都变了——比如之前加了quiet后来变成quiet splash或者 root 路径从/dev/sda2变成了/dev/mapper/vg-root。这往往不是有人手改了而是内核版本升级后update-grub 重新生成过配置把旧的内核条目清理掉新增了新的内核条目而你之前手动加的参数是在旧的 menuentry 里加的自然就没了。这个教训让我养成了一个习惯所有需要长期生效的内核参数一律写在/etc/default/grub里而不是手动改 grub.cfg。手动改是临时的更新内核后一定被覆盖但/etc/default/grub永远会被 update-grub 重新读取。这一点值得你养成同样的习惯。8. 折腾三天总结出来的避坑清单8.1 挂载顺序错了全盘皆输有些人急着修 GRUB直接mount /dev/sda2 /mnt之后就开始 chroot然后装 grub最后报一堆奇怪错误。你看到错误别急着找驱动、找包先回去检查一遍挂载顺序和挂载完整性。特别是有独立/boot分区的情况你如果忘了挂/mnt/bootchroot 进去后/boot目录其实是空的或者只有根分区里的内容update-grub找不到内核grub-install也会把引导装得驴唇不对马嘴。我写了个自检清单每次修 GRUB 前过一遍[ ] 根分区已经挂载到 /mnt[ ] 如果有独立 /boot确认已经挂到 /mnt/boot[ ] UEFI 模式确认 /mnt/boot/efi 已挂载内容应该包含 EFI 目录结构[ ] /dev, /proc, /sys/run 已经绑定挂载[ ] chroot 前在 /mnt/etc/fstab 里确认过目标系统的分区方案对了fstab 这个文件也值得看一眼。如果里面写的 root 分区 UUID 跟你实际 UUID 对不上就算 GRUB 引导成功内核加载后挂载根文件系统也会失败表现为开机卡在Timed out waiting for device dev-disk-by...或者直接 panic。这种情况一定要用blkid和 fstab 相互核对。8.2 chroot 之后提示 locale 错误或者其他奇怪报错Debian 的 chroot 环境经常提示perl: warning: Setting locale failed. perl: warning: Please check that your locale settings are supported by your installed locales.这种不影响 grub-install 和 update-grub 的正常执行可以暂时不管。如果你看着难受装一下locales包或者先 export 一个环境变量export LC_ALLC还有chroot 里如果提示/dev/null不存在或没有权限可能是/dev没绑定挂载好重新执行一遍sudo mount --bind /dev /mnt/dev这两个小问题每次急救基本都会碰到一两个见多了就不慌了。8.3 使用备份分区表跟分区 UUID 变化这场大戏分区 UUID 在系统启动中扮演的角色很重要。grub-install和update-grub都会把 UUID 写进 grub.cfg一旦你用的备份工具比如某些第三方克隆软件或者磁盘分区工具改变了分区 UUIDGRUB 就会失效。这种情况下的症状非常诡异同样的故障代码ls能看到文件set root也正确但内核就是起不来日志里报的 root device 找不到。我的经验是遇到这种问题不要盯着 GRUB 参数死磕先去查 fstab 和 grub.cfg 里的 UUID 是否和blkid输出一致。不一致就统一更新一遍让它们对齐sudo blkid cat /etc/fstab cat /boot/grub/grub.cfg | grep root三个输出里的 UUID 对得上基本上没问题。对不上改掉重新update-grub。8.4 Secure Boot 导致的“启动项明明在却进不去”UEFI Secure Boot 这个组合在 Debian 上也是越来越常见。如果你efibootmgr看到 Debian 启动项在位但选择它时提示类似 “Security Policy Violation” 或者直接闪回 BIOS 设置那就要考虑 Secure Boot 在拦截。Debian 官方在 12 版本对 Secure Boot 的支持已经比较完善了但如果你想完全避开这个坑也可以在 BIOS 里暂时禁用 Secure Boot进系统后再判断是否需要重新开启。或者确认用的是shimx64.efi而不是grubx64.efi作为启动文件shim 才有签名验证链才能过 Secure Boot 这一关。这个坑我实际碰到过一次当时帮人看一台新笔记本UEFI 引导项完美就是进不去折腾了半天才想到了 Secure Boot。后来装了 shim 文件之后问题就消失了。9. 一些能救命的辅助工具和备份习惯9.1 制作一个靠谱的 Live USB 是自己的本分不管你是 Debian 老用户还是刚入门我真心建议你手头常备一个 Live USB。不需要什么花哨的工具用 Debian 官方镜像加写盘工具就行。常见的方式# 在 Linux 下用 dd 写镜像 sudo dd ifdebian-live-12.iso of/dev/sdX bs4M statusprogress oflagsync在 Windows 下写 U 盘用开源免费的写盘工具就行界面简单选镜像、选 U盘、确认几分钟搞定。写完之后U 盘最好贴个标签放在抽屉里备用。9.2 /boot 分区备份这件事值得养成习惯GRUB 故障最烦的情况不是引导坏了而是引导坏的时候/boot目录里的内核和模块文件也不完整了。所以备份/boot分区是一个低成本高回报的习惯。我常用的办法是sudo tar -czf boot_backup.tar.gz /boot偶尔系统大版本升级前后、调整分区前后打包一下放到另一个磁盘或移动硬盘里。别小看这个操作真出事的时候你只要能从备份里恢复内核文件和 initrd剩下的修复流程就会顺畅非常多。9.3 记录自己系统的分区布局我真的见过不少人在 GRUB 坏了之后连自己系统装在哪块盘、根分区是哪个、有没有独立 /boot 都说不清——要临时现查。每次你新装系统或者调整分区的时候花一分钟把分区方案记下来保存在手机备忘录或者硬盘文档里。比如这样磁盘 /dev/sda 512GB /dev/sda1 512MB EFI (FAT32) /dev/sda2 100GB root (ext4) /dev/sda3 剩余 home (ext4)这样的记录比任何密码管理器都实用。等哪天真需要救援靠这个纸条能少走很多弯路。我自己的经验是这个记录在双系统、LVM、多磁盘场景下尤其值钱。10. 最后的实操经验小结我修过很多次 GRUB但说实话每一次都是在压力下进行的——要么是早上要开会要么是晚上要交作业电脑却不给你进门。这种时刻最能检验你对这套机制的理解到底是不是表面的。主动去了解 GRUB 的原理而不是背命令才是省时间的正路。当你理解了“GRUB 是引导器它需要找到 /boot 里的模块和配置文件再加载内核”下次遇到任何 GRUB 相关报错你都能立刻判断问题出在哪个环节。第一次修 GRUB把自己当成系统管理员修完重启的时候手指还是会微微发抖。但跑通之后那种“原来它是这么个逻辑”的豁然开朗会让你对整个系统启动链路都有更深的体感。我建议你在平时系统正常的时候就找一个空闲的周末打开虚拟机开一台 Debian故意把 grub.cfg 改名、故意把 boot 分区重新分配然后练习整套修复流程。花两三个小时练一练远比真出事了干着急来得划算。说句实在的真到了生产环境值班遇到 GRUB 故障你能稳住别慌、按流程走就已经胜过大半人了。