开机之后没看到熟悉的桌面或者登录界面屏幕上顶着一行grub或者grub rescue下面还跟着一句minimal bash-like line editing is supported。第一次遇到的人十有八九会慌以为系统挂了其实大部分情况下数据都还在只是引导这块断了线。这篇文章就是专门聊这个问题的从命令行手动引导到修复再到怎么防止下次再犯一步一步讲清楚。我会把我在实际环境里排查过的案例、踩过的坑、用过的土办法都放进来。不管你是 Ubuntu、Debian、Arch 还是 CentOS 系的发行版核心思路都是通用的差别只在个别命令和配置文件路径上。1. 先搞清楚问题本质grub 命令行是怎么出现的1.1 你遇见的到底是哪种界面很多人把grub和grub rescue混为一谈但这两者的问题阶段完全不同处理方式也不一样。grub rescue是 GRUB 的救援模式。GRUB 自己在启动的时候连核心模块比如 normal.mod都没找到或者加载失败就退到了这个最简环境。这个模式下能用的命令非常少基本只有ls、set、unset、insmod这几个。想要脱离它操作起来会比较繁琐一般得先手动找到分区再一步步insmod加载模块最后normal进入完整命令行。grub是 GRUB 正常模块加载之后、但找不到或者无法读取 grub.cfg 时的状态。屏幕上方会有个大标题 GNU GRUB version 2.xx底部提示minimal bash-like line editing is supported。在这个界面你能用的命令全多了TAB 键能自动补全也可以直接配置 root、加载内核、启动系统。对比起来grub的修复成本其实比grub rescue低很多。判断一下你眼前是哪个提示符后面要做的操作完全不一样。这一步没辨清楚很容易在错误的路径上白折腾。1.2 最常见的几个诱因从真实故障案例来看grub 走到命令行模式基本逃不开下面几类原因。第一类是 grub.cfg 文件丢失、损坏或者被移动。这个文件通常位于/boot/grub/grub.cfg它是整个引导菜单的配置文件。系统升级时中途断电、磁盘空间写满、误操作删除都可能让它坏掉。第二类是分区表或者分区 UUID 变化了。GRUB 在配置文件里大量使用 UUID 来定位分区比如search --no-floppy --fs-uuid --setroot xxxxxxxx。如果你用 GParted 改过分区、格式化过某个分区、克隆过磁盘UUID 就变了GRUB 按旧 ID 找不到对应分区自然就启动不了。第三类是 Windows 更新把引导给覆盖了。双系统用户特别容易碰这个情况。Windows 在更新或者修复引导的过程中会重新写入自己的 EFI 启动项把 GRUB 从启动序列里挤出去或者直接覆盖掉 EFI 分区里的引导文件。黑屏后你甚至可能直接进到 Windows 的恢复界面而不是 grub 命令行但两者本质都是引导冲突。第四类是装了新内核之后initramfs 或者 vmlinuz 文件缺失。比如/boot分区空间不够内核升级时没写全GRUB 能读取配置但配置里指向的内核文件不存在也会打进命令行或直接报error: file not found。第五类是 BIOS 引导模式切换导致的。原来用传统 BIOS 模式装的系统在 BIOS 里改成了 UEFI 模式或者反过来。GRUB 安装位置彻底变了MBR 里的引导代码和 EFI 分区里的引导文件完全不匹配机器当然找不到正常引导项。1.3 为什么 BIOS 和 UEFI 环境下的表现不一样这俩环境底下GRUB 的工作原理差得很远理解这点才能知道该怎么修。传统 BIOS 模式机器一开机CPU 会跳到一个固定地址BIOS 去读启动盘的第一个扇区MBRMBR 里的 GRUB 引导代码接着去加载 core.img然后按配置一步步把 Linux 内核拉起来。也就是说引导代码是直接写在硬盘的开头位置的。UEFI 模式下主板会读取 EFI 系统分区ESP一般是 FAT32 格式里的.efi文件。GRUB 的启动文件是EFI/grub/grubx64.efiNVRAM 里记录着要加载哪个 .efi 文件。你可以理解成 UEFI 是一个小操作系统它把启动项列表存进自己的配置区里然后按顺序加载。这也就是为什么 UEFI 环境出问题往往要去检查efibootmgr里的启动项顺序而不只是重写 MBR。我见过不少人在 UEFI 机器上用grub-install /dev/sda这种方式来修引导结果重启还是进不了系统。原因很简单UEFI 模式下要指定--targetx86_64-efi --efi-directory...不写的话命令默认按 BIOS 方式安装方向就错了。2. 现场急救grub 命令行下手动引导系统启动2.1 先看清当前处境ls 和 set既然已经停在 grub 命令行与其干瞪眼不如先手动把系统拉起来。这套操作我做过无数次思路非常简单确认分区、指定 root、加载内核、启动。进入 grub 命令行第一步就是ls。这个命令会列出当前 GRUB 能看到的所有磁盘和分区输出大致长这样(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)(hd0)是第一块物理硬盘(hd0,gpt1)表示硬盘上的第一个 GPT 分区。传统 MBR 分区表标识通常是(hd0,msdos1)这种写法。通过分区编号和文件系统内容我们能判断出哪个分区是 EFI 分区、哪个是根分区、哪个是 /boot。接着用set看一下当前的 GRUB 变量grub set cmdpath(hd0,gpt1)/EFI/grub prefix(hd0,gpt1)/grub roothd0,gpt1这里prefix告诉你去哪儿找 GRUB 的模块和配置文件root是当前 GRUB 认为的根分区。如果这个 root 指向不对后面加载东西都会报错。这时候要做的就是找到真正的 Linux 根分区。可以用ls (hd0,gpt2)/一类的命令去翻每个分区的内容。看到etc/、usr/、var/这些目录说明这就是根分区看到vmlinuz-*、initrd.img-*、grub/这些说明是 /boot可能独立也可能就在根分区里。2.2 手动引导 Linux 内核启动的完整步骤找到根分区之后手动引导的过程就很机械了。假设系统根分区是(hd0,gpt3)/boot 没有单独分区全部在根分区里一套标准命令如下grub set root(hd0,gpt3) grub linux /boot/vmlinuz-5.15.0-91-generic root/dev/sda3 grub initrd /boot/initrd.img-5.15.0-91-generic grub boot第一行告诉 GRUB 根分区在哪第二行指定要启动的内核文件同时通过root/dev/sda3告诉 Linux 内核系统真正的根文件系统是哪个设备。第三行加载 initramfs这个文件包含驱动的初始环境和根文件系统挂载工具没有它内核没法挂载真正的 root。最后boot启动。如果 /boot 是独立分区命令会变成这样grub set root(hd0,gpt2) grub linux /vmlinuz-5.15.0-91-generic root/dev/sda3 grub initrd /initrd.img-5.15.0-91-generic grub boot差别就是内核和 initrd 的路径前面不用加/boot因为整个分区挂载点就是 /boot。实际操作时TAB 键补全非常关键。忘掉了确切的内核版本号也没关系输入linux /boot/vmlinuz-之后按 TABGRUB 会自动把存在的内核文件名补全出来。同理root后也可以多试试拿不准根分区设备号时可以直接写rootUUIDxxxx这个 UUID 可以通过ls -l /dev/disk/by-uuid/或者blkid查到比设备名更保险。2.3 特殊文件系统LVM、btrfs、加密分区如果根分区用了 LVM、btrfs 子卷或者 LUKS 加密手动引导时就得先加载对应模块否则 GRUB 认不出这些文件系统。遇到 LVM 逻辑卷先执行grub insmod lvm grub ls (lvm/ubuntu-vg-root)/这里(lvm/ubuntu-vg-root)的 pq 是「卷组名/逻辑卷名」。找对了之后设置 root 并加载内核grub set root(lvm/ubuntu-vg-root) grub linux /boot/vmlinuz-... root/dev/mapper/ubuntu-vg-root grub initrd /boot/initrd.img-... grub bootbtrfs 子卷的情况稍微麻烦点。如果根文件系统是 btrfs并且 root 子卷设置得很特殊手动加载内核时老提示找不到文件其实不是文件不存在而是路径没进去子卷。可以试试grub insmod btrfs grub set root(hd0,gpt3) grub linux //boot/vmlinuz-... root/dev/sda3 rootflagssubvol grub initrd //boot/initrd.img-... grub boot/前缀是 btrfs 默认子卷的路径写法rootflagssubvol是告诉内核以「」作为 root 子卷来挂载。这个和不同发行版的默认布局强相关建议先查好自己的子卷结构再动手。加密分区更复杂一般需要先从其他介质进救援系统解锁并挂载后进入 chroot 修复。靠 grub 命令行手动引导加密根系统操作链太长不建议现场硬刚直接走 Live USB 方案反而更快。2.4 现场急救的几个经验技巧第一点进了 grub 命令行不要急着反复重启。每一次重启你都要重新经历一遍引导失败的过程而且有些临时状态可能还会被重置。在命令行里慢慢排查反而最容易解决问题。第二点尽量用 UUID 而不是/dev/sdX设备名。设备名在 BIOS 环境、UEFI 环境、不同启动介质下顺序可能完全不同。同一块 U 盘在某些机器上是sda换个插口就成sdb了。UUID 是磁盘分区的唯一身份标识Linux 内核和 GRUB 都认它。第三点确认内核版本时要小心。使用旧的 vmlinuz 和新的 initrd 混搭或者反过来有概率启动到一半崩掉。尽量选当前系统里最新、最完整的一组文件。判断是否完整可以先分别按 TAB 看补全结果内核文件名和 initrd 文件名版本号应该一一对应。第四点手动引导成功进入系统之后别急着关机。第一件事就是执行引导修复命令让 GRUB 配置重新生成。不然你不会想再来一遍的。3. 修复方案让引导恢复正常3.1 在 grub 命令行进去系统后的一步操作假设你已经通过手动引导进入了系统这时候能直接在宿主机里修引导省去很多麻烦。不同发行版生成的命令不太一样但本质上都是同一件事重新生成 grub.cfg。Ubuntu 和 Debian 系sudo update-grubFedora 和 CentOS/RHEL 系sudo grub2-mkconfig -o /boot/grub2/grub.cfgArch Linux 系sudo grub-mkconfig -o /boot/grub/grub.cfg跑完之后查看/boot/grub/grub.cfg或者/boot/grub2/grub.cfg是否重新生成了。如果里面能看到 Linux 内核的 menuentry 段落说明配置已经恢复。但这里有个隐藏坑如果系统里没有安装正确的grub-pc或者grub-efi包重新生成配置可能失败或者生成不完整。需要先确认自己的 GRUB 版本和模式grub-install --version efibootmgr -v # UEFI 环境看启动项要是update-grub执行中报错顺手查一下/boot磁盘空间是不是满了。我遇到过一台机器boot 分区 256MB 被旧内核塞满grub.cfg 根本写不进去df -h一看直接 100%。清掉旧内核再更新问题就没了。3.2 使用 Live USB 修复的正确姿势如果系统已经完全进不去手动引导也失败了那就得上 Live USB。这个方法适合任何发行版狗屁前提条件也少只要有一台能正常开机的电脑做一个启动 U 盘就能修。Live 系统启动后先挂载硬盘根分区sudo mount /dev/sda3 /mnt如果有独立 /boot 分区继续sudo mount /dev/sda2 /mnt/boot如果是 UEFI 环境必须要把 EFI 分区挂载到对应位置sudo mount /dev/sda1 /mnt/boot/efi挂载顺序有讲究。 /boot 和 /boot/efi 要挂在 /mnt 下面而不是直接挂到 /mnt/boot 就完了层级不能乱。挂载完之后把必要的虚拟文件系统 bind 过去这是 chroot 环境能正常工作的前提sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run然后进入目标系统sudo chroot /mnt进入 chroot 之后你就是在用目标系统的工具链了。接下来可以执行更新配置、重装引导等操作。全流程做完退出exit sudo umount -R /mnt sudo reboot这里有三个高频失误要特别记住。第一忘记挂载 EFI 分区就一直折腾grub-install 一直报错其实是--efi-directory指向的目录是空的。第二没有 bind 挂载/proc、/sys等虚拟文件系统chroot 里执行硬件相关命令直接卡死或者报诡异错误。第三修复完直接强制重启没正常 umount导致文件系统写缓存丢失白修一场。3.3 重装 GRUB 的完整差异点BIOS 和 UEFI在 chroot 环境下重装 GRUB 需要根据引导模式做区分这步绝对不能搞错。传统 BIOS 模式执行grub-install /dev/sda update-grub这里的/dev/sda是整个磁盘设备不是某个分区。因为 GRUB 引导代码要写入 MBR而 MBR 位于磁盘最开头不是分区内部。UEFI 模式要这样grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idGRUB update-grub--efi-directory指定 EFI 系统分区的挂载点--bootloader-id是自己起的引导项名称一般叫 GRUB 或者 Ubuntu。执行成功后EFI 分区里会生成EFI/GRUB/grubx64.efi之类的文件。UEFI 还有个很有用的检查命令。退出 chroot 之后执行efibootmgr -v输出里会列出当前机器的所有启动项。确认存在类似Boot0001* GRUB ...这样的条目并且顺序在 Windows Boot Manager 之前才能保证下次开机先进 GRUB。如果启动项顺序不对可以用efibootmgr -o 0001,0000把 GRUB 项的编号调整到第一位。3.4 不重装也能救手动生成最小 grub.cfg有一种场景是 GRUB 本身安装完好模块齐全只是 grub.cfg 损坏或缺失。重装 GRUB 显然能解决但如果你着急也可以手动写一个 mini 版的 grub.cfg把系统先拉起来再说。手工写一个最简 grub.cfg 的模板大概长这样set default0 set timeout5 menuentry My Linux { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --setroot 3d4a7c6e-xxxx-xxxx-xxxx-xxxxxxxxxxxx linux /vmlinuz-6.1.0-arch1-1 rootUUID3d4a7c6e-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw initrd /initramfs-6.1.0-arch1-1.img }把 UUID 换成自己根分区的真实 UUID内核文件名也按/boot里的实际文件修改。存到/boot/grub/grub.cfg后重启GRUB 就能显示这个精简的启动菜单。但需要强调这个手写配置不具备生成系统里其他启动项的扩展能力双系统、内核升级之后的自动更新都不会自动应用。所以这个方案主要适合「临时把系统弄起来、备份数据、安排正式修复」的阶段正规修复还是建议走一次update-grub或者重装。4. 那些年踩过的坑常见误判与排查实录4.1 是不是数据丢了其实是引导丢了遇到 grub 命令行大部分用户的第一个想法然后告诉自己可能得重装系统。我处理过的案子里面至少八成都是纯引导问题盘里数据完好无损。之前有个朋友的服务器开机进 grub rescue操作半天没进展催我帮忙。我问他最近动过什么他说插了一块新硬盘进去然后 BIOS 把新硬盘设置成了第一启动顺序。老系统盘虽然没问题但 MBR 引导代码指向的配置和分区 UUID 全部变了路径。解决方案非常简单BIOS 启动顺序调整回去一行都不改直接开始引导。这类属于磁盘顺序变化导致的假故障没有这个经验很难快速定位。4.2 Windows 更新把 GRUB 顶掉了双系统环境Windows 更新后开机直接进 Windows或者卡在奇怪的引导界面是日常。原因前面提到Windows 在更新或者修复时会重写 EFI 启动项把 GRUB 项排在后面甚至将原来的启动项删掉。处理方式两种。Linux 侧从 Linux Live USB 启动进入 chroot 后重装 GRUB 并更新启动项顺序。也可以不进系统直接用efibootmgr操作。比如查到了 GRUB 的项是Boot0003执行efibootmgr -o 0003,0000设置第一启动项重启就能看见 GRUB 菜单。Windows 侧也可以在 Windows 命令提示符管理员里执行bcdedit /set {bootmgr} path \EFI\GRUB\grubx64.efi把引导直接指向 GRUB 文件。4.3 克隆磁盘后的引导迷局用 dd、Clonezilla 或者一些分区克隆工具迁移系统盘是投诉的另一个重灾区。磁盘克隆完了盘号变了分区比原来大了或者小了UUID 虽然复制过来了但 EFI 分区里的引导文件可能没被正确带到新盘上或者 BIOS 启动顺序没有指向新盘。有个次踩完的路径是把旧盘的系统克隆到新 SSD然后拔掉旧盘开机报 grub 错误。用 Live USB 进去看发现 EFI 分区根本没克隆到新盘上因为克隆的时候只克隆了根分区和 boot 分区忘了 EFI 分区ESP。这种只能手动把 EFI 分区复制过去再引导修复。所以做磁盘克隆时ESP 分区一定要包含在克隆范围里否则事后补账很麻烦。4.4 内核升级后 initramfs 缺失还有一种情况是正常关机隔天开机就直接 grub 命令行。进去一看grub.cfg 还在里面的 menuentry 也在但启动时报file not found。用 ls 检查 /boot发现 vmlinuz 引用的版本号和实际文件对不上。这类问题大多出在「内核升级中断」。比如升级过程中空间满了或者新内核下载一半或者升级工具生成 grub.cfg 之后又清理了旧内核。解决方案是在 grub 命令行手动引导一个存在的内核版本或者直接用 Live USB chroot 后重新update-grub让它重新生成对应现有文件的配置。4.5 grub 命令行问题快速排查表现象常见原因快速判断方法grub rescue 模式GRUB 模块未加载ls看分区列表找 /bootgrub 模式grub.cfg 缺失或损坏ls (hd0,gptX)/boot/grub/看文件启动时报file not found内核/initrd 版本不匹配对比 vmlinuz 和 initrd 文件名Windows 更新后直接进 Windows启动项顺序被覆盖efibootmgr -v查看顺序克隆盘后无法引导ESP 分区未完整克隆或 UUID 改变Live 检查 ESP 内容和分区 UUID开机黑屏只有光标引导代码损坏或模式切换用 Live USB 检查 MBR/EFI 状态根分区是 lvm 无法启动缺少 lvm 模块grub 里insmod lvm4.6 grub minimal bash 这句话到底在说什么屏幕上的这句minimal bash-like line editing is supported本质上是 GRUB 在提示你我现在处于一个简化的命令行环境只用基本行的编辑能力不能提供完整菜单。它不是系统崩溃不是硬盘坏了也不是数据清空它只是在告诉你GRUB 没找到配置文件只能让你用命令行手动救。我见过一些教程把这句话翻译成「最小 bash 式命令行编辑已可用」单看字面没问题但对普通用户来说毫无帮助。更准确、更有用的理解其实是「GRUB 加载成功了但找不到菜单配置文件现在需要你在命令行里手动告诉它从哪启动」。说人话就是——引导程序活着但它的菜单丢了得你来指定启动参数。5. 预防与应对避免再次出现5.1 给 GRUB 上一份保险引导修复的功夫再熟练也不如从源头避免问题。办法不复杂但要坚持执行。最简单的一层保险是定期备份 grub.cfg。别小看这个文本文件cp /boot/grub/grub.cfg /boot/grub/grub.cfg.bak每次系统完成内核升级、大版本更新之后都重新备份一次。出问题时可以直接把备份恢复过去至少能先启动起来。再加一层保险是记录关键分区 UUIDblkid | grep -E (/dev/sd|/dev/nvme)把根分区、/boot 分区、EFI 分区的 UUID 记录到个人笔记里。grub 命令行里需要手填 UUID 的时候翻笔记比自己猜要稳妥得多。如果你用的是虚拟化环境比如 VMware、VirtualBox快照是成本最低的保险。做任何可能影响引导的操作之前拍一张快照出了问题往回一拉几秒钟就恢复原状。物理机没有快照那就准备一个系统救援 U 盘。我长期挂着一个 Ventoy 启动盘里面同时塞了 SystemRescue 和 Ubuntu Live出问题随时插上。5.2 内核升级的正确习惯内核升级是引导损坏的高频触发点尤其是 Ubuntu 这种自动升级内核的发行版。推荐养成三个习惯。第一系统升级前先确认 /boot 分区空间充足执行df -h /boot留出至少两三倍的旧内核空间余量。第二升级完成后重启前先跑一次update-grub确认配置正确生成再重启不迟。第三定期清理无用的旧内核用发行版自带工具或apt autoremove --purge处理。如果你开启了自动安全更新记得看看它是否包含内核更新。无脑全自动更新加自动重启出问题你的感知窗口会非常短可能更糟糕的是半夜里就启动不了了。5.3 双系统用户要建立的防线双系统用户要明确一个原则Windows 的引导修复功能是「我很强势」的存在只要它在磁盘上发现 Windows 分区它就可能把引导覆盖到自己这边。为了防止 Windows 更新把 GRUB 顶掉可以采取两个措施。第一在 Windows 的「禁用自动更新」策略上设置延期至少给 Linux 侧一个缓冲时间。第二提前学会使用efibootmgr调整启动顺序出问题不用再折腾 Live USB直接在 Windows 下重启到 UEFI 设置手动选择 GRUB 启动项一般也能进系统。当然如果你的 Windows 经常需要打更新我建议把 GRUB 菜单默认超时时间调长一点比如设置成 10 秒这样重启的时候还有机会手动选引导项。改超时的方法sudo sed -i s/GRUB_TIMEOUT5/GRUB_TIMEOUT10/ /etc/default/grub sudo update-grub5.4 给新手的一份实用建议如果你刚刚接触 Linux碰到 grub 命令行确实容易手足无措。给自己定几条底线能减少很多损失。第一不在不熟悉命令的情况下直接执行rm -rf或者dd尤其涉及全盘操作的时候。第二不随意动分区表。看到某个分区的 UUID 变化很正常但自己去fdisk改类型、删分区极可能引发引导崩溃。第三每次做可能有风险的操作前想想数据备份问题哪怕只是把 /etc、/boot 目录复制出来也比没有强。我最开始修引导的时候也干过在 grub rescue 下误删分区的蠢事。现在修引导养成了固定习惯先ls把所有分区列出来再set看当前上下文最后才动手设置参数。这个习惯帮我避开了很多不必要的坑。根据我个人经验grub 命令行问题百分之九十都不是灾难而是「配置丢失」加上「专业知识不够」造成的心理恐慌。只要你理解了 GRUB 查找配置文件的路径逻辑知道了手动引导内核这五个步骤大部分情况都能当场解决。剩下那百分之十交给 Live USB 和 grub-install 收尾也足够了。最后分享一个小技巧。grub 命令行下TAB键真的很好用你不需要记住完整的内核版本号输入前缀后按 TAB所有候选文件都会列出来。手动引导时我就是靠这个少走了很多弯路。下次再遇到minimal bash-like line editing is supported先深吸一口气然后按这个思路一步步来。
开机之后没看到熟悉的桌面或者登录界面屏幕上顶着一行grub或者grub rescue下面还跟着一句minimal bash-like line editing is supported。第一次遇到的人十有八九会慌以为系统挂了其实大部分情况下数据都还在只是引导这块断了线。这篇文章就是专门聊这个问题的从命令行手动引导到修复再到怎么防止下次再犯一步一步讲清楚。我会把我在实际环境里排查过的案例、踩过的坑、用过的土办法都放进来。不管你是 Ubuntu、Debian、Arch 还是 CentOS 系的发行版核心思路都是通用的差别只在个别命令和配置文件路径上。1. 先搞清楚问题本质grub 命令行是怎么出现的1.1 你遇见的到底是哪种界面很多人把grub和grub rescue混为一谈但这两者的问题阶段完全不同处理方式也不一样。grub rescue是 GRUB 的救援模式。GRUB 自己在启动的时候连核心模块比如 normal.mod都没找到或者加载失败就退到了这个最简环境。这个模式下能用的命令非常少基本只有ls、set、unset、insmod这几个。想要脱离它操作起来会比较繁琐一般得先手动找到分区再一步步insmod加载模块最后normal进入完整命令行。grub是 GRUB 正常模块加载之后、但找不到或者无法读取 grub.cfg 时的状态。屏幕上方会有个大标题 GNU GRUB version 2.xx底部提示minimal bash-like line editing is supported。在这个界面你能用的命令全多了TAB 键能自动补全也可以直接配置 root、加载内核、启动系统。对比起来grub的修复成本其实比grub rescue低很多。判断一下你眼前是哪个提示符后面要做的操作完全不一样。这一步没辨清楚很容易在错误的路径上白折腾。1.2 最常见的几个诱因从真实故障案例来看grub 走到命令行模式基本逃不开下面几类原因。第一类是 grub.cfg 文件丢失、损坏或者被移动。这个文件通常位于/boot/grub/grub.cfg它是整个引导菜单的配置文件。系统升级时中途断电、磁盘空间写满、误操作删除都可能让它坏掉。第二类是分区表或者分区 UUID 变化了。GRUB 在配置文件里大量使用 UUID 来定位分区比如search --no-floppy --fs-uuid --setroot xxxxxxxx。如果你用 GParted 改过分区、格式化过某个分区、克隆过磁盘UUID 就变了GRUB 按旧 ID 找不到对应分区自然就启动不了。第三类是 Windows 更新把引导给覆盖了。双系统用户特别容易碰这个情况。Windows 在更新或者修复引导的过程中会重新写入自己的 EFI 启动项把 GRUB 从启动序列里挤出去或者直接覆盖掉 EFI 分区里的引导文件。黑屏后你甚至可能直接进到 Windows 的恢复界面而不是 grub 命令行但两者本质都是引导冲突。第四类是装了新内核之后initramfs 或者 vmlinuz 文件缺失。比如/boot分区空间不够内核升级时没写全GRUB 能读取配置但配置里指向的内核文件不存在也会打进命令行或直接报error: file not found。第五类是 BIOS 引导模式切换导致的。原来用传统 BIOS 模式装的系统在 BIOS 里改成了 UEFI 模式或者反过来。GRUB 安装位置彻底变了MBR 里的引导代码和 EFI 分区里的引导文件完全不匹配机器当然找不到正常引导项。1.3 为什么 BIOS 和 UEFI 环境下的表现不一样这俩环境底下GRUB 的工作原理差得很远理解这点才能知道该怎么修。传统 BIOS 模式机器一开机CPU 会跳到一个固定地址BIOS 去读启动盘的第一个扇区MBRMBR 里的 GRUB 引导代码接着去加载 core.img然后按配置一步步把 Linux 内核拉起来。也就是说引导代码是直接写在硬盘的开头位置的。UEFI 模式下主板会读取 EFI 系统分区ESP一般是 FAT32 格式里的.efi文件。GRUB 的启动文件是EFI/grub/grubx64.efiNVRAM 里记录着要加载哪个 .efi 文件。你可以理解成 UEFI 是一个小操作系统它把启动项列表存进自己的配置区里然后按顺序加载。这也就是为什么 UEFI 环境出问题往往要去检查efibootmgr里的启动项顺序而不只是重写 MBR。我见过不少人在 UEFI 机器上用grub-install /dev/sda这种方式来修引导结果重启还是进不了系统。原因很简单UEFI 模式下要指定--targetx86_64-efi --efi-directory...不写的话命令默认按 BIOS 方式安装方向就错了。2. 现场急救grub 命令行下手动引导系统启动2.1 先看清当前处境ls 和 set既然已经停在 grub 命令行与其干瞪眼不如先手动把系统拉起来。这套操作我做过无数次思路非常简单确认分区、指定 root、加载内核、启动。进入 grub 命令行第一步就是ls。这个命令会列出当前 GRUB 能看到的所有磁盘和分区输出大致长这样(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)(hd0)是第一块物理硬盘(hd0,gpt1)表示硬盘上的第一个 GPT 分区。传统 MBR 分区表标识通常是(hd0,msdos1)这种写法。通过分区编号和文件系统内容我们能判断出哪个分区是 EFI 分区、哪个是根分区、哪个是 /boot。接着用set看一下当前的 GRUB 变量grub set cmdpath(hd0,gpt1)/EFI/grub prefix(hd0,gpt1)/grub roothd0,gpt1这里prefix告诉你去哪儿找 GRUB 的模块和配置文件root是当前 GRUB 认为的根分区。如果这个 root 指向不对后面加载东西都会报错。这时候要做的就是找到真正的 Linux 根分区。可以用ls (hd0,gpt2)/一类的命令去翻每个分区的内容。看到etc/、usr/、var/这些目录说明这就是根分区看到vmlinuz-*、initrd.img-*、grub/这些说明是 /boot可能独立也可能就在根分区里。2.2 手动引导 Linux 内核启动的完整步骤找到根分区之后手动引导的过程就很机械了。假设系统根分区是(hd0,gpt3)/boot 没有单独分区全部在根分区里一套标准命令如下grub set root(hd0,gpt3) grub linux /boot/vmlinuz-5.15.0-91-generic root/dev/sda3 grub initrd /boot/initrd.img-5.15.0-91-generic grub boot第一行告诉 GRUB 根分区在哪第二行指定要启动的内核文件同时通过root/dev/sda3告诉 Linux 内核系统真正的根文件系统是哪个设备。第三行加载 initramfs这个文件包含驱动的初始环境和根文件系统挂载工具没有它内核没法挂载真正的 root。最后boot启动。如果 /boot 是独立分区命令会变成这样grub set root(hd0,gpt2) grub linux /vmlinuz-5.15.0-91-generic root/dev/sda3 grub initrd /initrd.img-5.15.0-91-generic grub boot差别就是内核和 initrd 的路径前面不用加/boot因为整个分区挂载点就是 /boot。实际操作时TAB 键补全非常关键。忘掉了确切的内核版本号也没关系输入linux /boot/vmlinuz-之后按 TABGRUB 会自动把存在的内核文件名补全出来。同理root后也可以多试试拿不准根分区设备号时可以直接写rootUUIDxxxx这个 UUID 可以通过ls -l /dev/disk/by-uuid/或者blkid查到比设备名更保险。2.3 特殊文件系统LVM、btrfs、加密分区如果根分区用了 LVM、btrfs 子卷或者 LUKS 加密手动引导时就得先加载对应模块否则 GRUB 认不出这些文件系统。遇到 LVM 逻辑卷先执行grub insmod lvm grub ls (lvm/ubuntu-vg-root)/这里(lvm/ubuntu-vg-root)的 pq 是「卷组名/逻辑卷名」。找对了之后设置 root 并加载内核grub set root(lvm/ubuntu-vg-root) grub linux /boot/vmlinuz-... root/dev/mapper/ubuntu-vg-root grub initrd /boot/initrd.img-... grub bootbtrfs 子卷的情况稍微麻烦点。如果根文件系统是 btrfs并且 root 子卷设置得很特殊手动加载内核时老提示找不到文件其实不是文件不存在而是路径没进去子卷。可以试试grub insmod btrfs grub set root(hd0,gpt3) grub linux //boot/vmlinuz-... root/dev/sda3 rootflagssubvol grub initrd //boot/initrd.img-... grub boot/前缀是 btrfs 默认子卷的路径写法rootflagssubvol是告诉内核以「」作为 root 子卷来挂载。这个和不同发行版的默认布局强相关建议先查好自己的子卷结构再动手。加密分区更复杂一般需要先从其他介质进救援系统解锁并挂载后进入 chroot 修复。靠 grub 命令行手动引导加密根系统操作链太长不建议现场硬刚直接走 Live USB 方案反而更快。2.4 现场急救的几个经验技巧第一点进了 grub 命令行不要急着反复重启。每一次重启你都要重新经历一遍引导失败的过程而且有些临时状态可能还会被重置。在命令行里慢慢排查反而最容易解决问题。第二点尽量用 UUID 而不是/dev/sdX设备名。设备名在 BIOS 环境、UEFI 环境、不同启动介质下顺序可能完全不同。同一块 U 盘在某些机器上是sda换个插口就成sdb了。UUID 是磁盘分区的唯一身份标识Linux 内核和 GRUB 都认它。第三点确认内核版本时要小心。使用旧的 vmlinuz 和新的 initrd 混搭或者反过来有概率启动到一半崩掉。尽量选当前系统里最新、最完整的一组文件。判断是否完整可以先分别按 TAB 看补全结果内核文件名和 initrd 文件名版本号应该一一对应。第四点手动引导成功进入系统之后别急着关机。第一件事就是执行引导修复命令让 GRUB 配置重新生成。不然你不会想再来一遍的。3. 修复方案让引导恢复正常3.1 在 grub 命令行进去系统后的一步操作假设你已经通过手动引导进入了系统这时候能直接在宿主机里修引导省去很多麻烦。不同发行版生成的命令不太一样但本质上都是同一件事重新生成 grub.cfg。Ubuntu 和 Debian 系sudo update-grubFedora 和 CentOS/RHEL 系sudo grub2-mkconfig -o /boot/grub2/grub.cfgArch Linux 系sudo grub-mkconfig -o /boot/grub/grub.cfg跑完之后查看/boot/grub/grub.cfg或者/boot/grub2/grub.cfg是否重新生成了。如果里面能看到 Linux 内核的 menuentry 段落说明配置已经恢复。但这里有个隐藏坑如果系统里没有安装正确的grub-pc或者grub-efi包重新生成配置可能失败或者生成不完整。需要先确认自己的 GRUB 版本和模式grub-install --version efibootmgr -v # UEFI 环境看启动项要是update-grub执行中报错顺手查一下/boot磁盘空间是不是满了。我遇到过一台机器boot 分区 256MB 被旧内核塞满grub.cfg 根本写不进去df -h一看直接 100%。清掉旧内核再更新问题就没了。3.2 使用 Live USB 修复的正确姿势如果系统已经完全进不去手动引导也失败了那就得上 Live USB。这个方法适合任何发行版狗屁前提条件也少只要有一台能正常开机的电脑做一个启动 U 盘就能修。Live 系统启动后先挂载硬盘根分区sudo mount /dev/sda3 /mnt如果有独立 /boot 分区继续sudo mount /dev/sda2 /mnt/boot如果是 UEFI 环境必须要把 EFI 分区挂载到对应位置sudo mount /dev/sda1 /mnt/boot/efi挂载顺序有讲究。 /boot 和 /boot/efi 要挂在 /mnt 下面而不是直接挂到 /mnt/boot 就完了层级不能乱。挂载完之后把必要的虚拟文件系统 bind 过去这是 chroot 环境能正常工作的前提sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /run /mnt/run然后进入目标系统sudo chroot /mnt进入 chroot 之后你就是在用目标系统的工具链了。接下来可以执行更新配置、重装引导等操作。全流程做完退出exit sudo umount -R /mnt sudo reboot这里有三个高频失误要特别记住。第一忘记挂载 EFI 分区就一直折腾grub-install 一直报错其实是--efi-directory指向的目录是空的。第二没有 bind 挂载/proc、/sys等虚拟文件系统chroot 里执行硬件相关命令直接卡死或者报诡异错误。第三修复完直接强制重启没正常 umount导致文件系统写缓存丢失白修一场。3.3 重装 GRUB 的完整差异点BIOS 和 UEFI在 chroot 环境下重装 GRUB 需要根据引导模式做区分这步绝对不能搞错。传统 BIOS 模式执行grub-install /dev/sda update-grub这里的/dev/sda是整个磁盘设备不是某个分区。因为 GRUB 引导代码要写入 MBR而 MBR 位于磁盘最开头不是分区内部。UEFI 模式要这样grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idGRUB update-grub--efi-directory指定 EFI 系统分区的挂载点--bootloader-id是自己起的引导项名称一般叫 GRUB 或者 Ubuntu。执行成功后EFI 分区里会生成EFI/GRUB/grubx64.efi之类的文件。UEFI 还有个很有用的检查命令。退出 chroot 之后执行efibootmgr -v输出里会列出当前机器的所有启动项。确认存在类似Boot0001* GRUB ...这样的条目并且顺序在 Windows Boot Manager 之前才能保证下次开机先进 GRUB。如果启动项顺序不对可以用efibootmgr -o 0001,0000把 GRUB 项的编号调整到第一位。3.4 不重装也能救手动生成最小 grub.cfg有一种场景是 GRUB 本身安装完好模块齐全只是 grub.cfg 损坏或缺失。重装 GRUB 显然能解决但如果你着急也可以手动写一个 mini 版的 grub.cfg把系统先拉起来再说。手工写一个最简 grub.cfg 的模板大概长这样set default0 set timeout5 menuentry My Linux { insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --setroot 3d4a7c6e-xxxx-xxxx-xxxx-xxxxxxxxxxxx linux /vmlinuz-6.1.0-arch1-1 rootUUID3d4a7c6e-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw initrd /initramfs-6.1.0-arch1-1.img }把 UUID 换成自己根分区的真实 UUID内核文件名也按/boot里的实际文件修改。存到/boot/grub/grub.cfg后重启GRUB 就能显示这个精简的启动菜单。但需要强调这个手写配置不具备生成系统里其他启动项的扩展能力双系统、内核升级之后的自动更新都不会自动应用。所以这个方案主要适合「临时把系统弄起来、备份数据、安排正式修复」的阶段正规修复还是建议走一次update-grub或者重装。4. 那些年踩过的坑常见误判与排查实录4.1 是不是数据丢了其实是引导丢了遇到 grub 命令行大部分用户的第一个想法然后告诉自己可能得重装系统。我处理过的案子里面至少八成都是纯引导问题盘里数据完好无损。之前有个朋友的服务器开机进 grub rescue操作半天没进展催我帮忙。我问他最近动过什么他说插了一块新硬盘进去然后 BIOS 把新硬盘设置成了第一启动顺序。老系统盘虽然没问题但 MBR 引导代码指向的配置和分区 UUID 全部变了路径。解决方案非常简单BIOS 启动顺序调整回去一行都不改直接开始引导。这类属于磁盘顺序变化导致的假故障没有这个经验很难快速定位。4.2 Windows 更新把 GRUB 顶掉了双系统环境Windows 更新后开机直接进 Windows或者卡在奇怪的引导界面是日常。原因前面提到Windows 在更新或者修复时会重写 EFI 启动项把 GRUB 项排在后面甚至将原来的启动项删掉。处理方式两种。Linux 侧从 Linux Live USB 启动进入 chroot 后重装 GRUB 并更新启动项顺序。也可以不进系统直接用efibootmgr操作。比如查到了 GRUB 的项是Boot0003执行efibootmgr -o 0003,0000设置第一启动项重启就能看见 GRUB 菜单。Windows 侧也可以在 Windows 命令提示符管理员里执行bcdedit /set {bootmgr} path \EFI\GRUB\grubx64.efi把引导直接指向 GRUB 文件。4.3 克隆磁盘后的引导迷局用 dd、Clonezilla 或者一些分区克隆工具迁移系统盘是投诉的另一个重灾区。磁盘克隆完了盘号变了分区比原来大了或者小了UUID 虽然复制过来了但 EFI 分区里的引导文件可能没被正确带到新盘上或者 BIOS 启动顺序没有指向新盘。有个次踩完的路径是把旧盘的系统克隆到新 SSD然后拔掉旧盘开机报 grub 错误。用 Live USB 进去看发现 EFI 分区根本没克隆到新盘上因为克隆的时候只克隆了根分区和 boot 分区忘了 EFI 分区ESP。这种只能手动把 EFI 分区复制过去再引导修复。所以做磁盘克隆时ESP 分区一定要包含在克隆范围里否则事后补账很麻烦。4.4 内核升级后 initramfs 缺失还有一种情况是正常关机隔天开机就直接 grub 命令行。进去一看grub.cfg 还在里面的 menuentry 也在但启动时报file not found。用 ls 检查 /boot发现 vmlinuz 引用的版本号和实际文件对不上。这类问题大多出在「内核升级中断」。比如升级过程中空间满了或者新内核下载一半或者升级工具生成 grub.cfg 之后又清理了旧内核。解决方案是在 grub 命令行手动引导一个存在的内核版本或者直接用 Live USB chroot 后重新update-grub让它重新生成对应现有文件的配置。4.5 grub 命令行问题快速排查表现象常见原因快速判断方法grub rescue 模式GRUB 模块未加载ls看分区列表找 /bootgrub 模式grub.cfg 缺失或损坏ls (hd0,gptX)/boot/grub/看文件启动时报file not found内核/initrd 版本不匹配对比 vmlinuz 和 initrd 文件名Windows 更新后直接进 Windows启动项顺序被覆盖efibootmgr -v查看顺序克隆盘后无法引导ESP 分区未完整克隆或 UUID 改变Live 检查 ESP 内容和分区 UUID开机黑屏只有光标引导代码损坏或模式切换用 Live USB 检查 MBR/EFI 状态根分区是 lvm 无法启动缺少 lvm 模块grub 里insmod lvm4.6 grub minimal bash 这句话到底在说什么屏幕上的这句minimal bash-like line editing is supported本质上是 GRUB 在提示你我现在处于一个简化的命令行环境只用基本行的编辑能力不能提供完整菜单。它不是系统崩溃不是硬盘坏了也不是数据清空它只是在告诉你GRUB 没找到配置文件只能让你用命令行手动救。我见过一些教程把这句话翻译成「最小 bash 式命令行编辑已可用」单看字面没问题但对普通用户来说毫无帮助。更准确、更有用的理解其实是「GRUB 加载成功了但找不到菜单配置文件现在需要你在命令行里手动告诉它从哪启动」。说人话就是——引导程序活着但它的菜单丢了得你来指定启动参数。5. 预防与应对避免再次出现5.1 给 GRUB 上一份保险引导修复的功夫再熟练也不如从源头避免问题。办法不复杂但要坚持执行。最简单的一层保险是定期备份 grub.cfg。别小看这个文本文件cp /boot/grub/grub.cfg /boot/grub/grub.cfg.bak每次系统完成内核升级、大版本更新之后都重新备份一次。出问题时可以直接把备份恢复过去至少能先启动起来。再加一层保险是记录关键分区 UUIDblkid | grep -E (/dev/sd|/dev/nvme)把根分区、/boot 分区、EFI 分区的 UUID 记录到个人笔记里。grub 命令行里需要手填 UUID 的时候翻笔记比自己猜要稳妥得多。如果你用的是虚拟化环境比如 VMware、VirtualBox快照是成本最低的保险。做任何可能影响引导的操作之前拍一张快照出了问题往回一拉几秒钟就恢复原状。物理机没有快照那就准备一个系统救援 U 盘。我长期挂着一个 Ventoy 启动盘里面同时塞了 SystemRescue 和 Ubuntu Live出问题随时插上。5.2 内核升级的正确习惯内核升级是引导损坏的高频触发点尤其是 Ubuntu 这种自动升级内核的发行版。推荐养成三个习惯。第一系统升级前先确认 /boot 分区空间充足执行df -h /boot留出至少两三倍的旧内核空间余量。第二升级完成后重启前先跑一次update-grub确认配置正确生成再重启不迟。第三定期清理无用的旧内核用发行版自带工具或apt autoremove --purge处理。如果你开启了自动安全更新记得看看它是否包含内核更新。无脑全自动更新加自动重启出问题你的感知窗口会非常短可能更糟糕的是半夜里就启动不了了。5.3 双系统用户要建立的防线双系统用户要明确一个原则Windows 的引导修复功能是「我很强势」的存在只要它在磁盘上发现 Windows 分区它就可能把引导覆盖到自己这边。为了防止 Windows 更新把 GRUB 顶掉可以采取两个措施。第一在 Windows 的「禁用自动更新」策略上设置延期至少给 Linux 侧一个缓冲时间。第二提前学会使用efibootmgr调整启动顺序出问题不用再折腾 Live USB直接在 Windows 下重启到 UEFI 设置手动选择 GRUB 启动项一般也能进系统。当然如果你的 Windows 经常需要打更新我建议把 GRUB 菜单默认超时时间调长一点比如设置成 10 秒这样重启的时候还有机会手动选引导项。改超时的方法sudo sed -i s/GRUB_TIMEOUT5/GRUB_TIMEOUT10/ /etc/default/grub sudo update-grub5.4 给新手的一份实用建议如果你刚刚接触 Linux碰到 grub 命令行确实容易手足无措。给自己定几条底线能减少很多损失。第一不在不熟悉命令的情况下直接执行rm -rf或者dd尤其涉及全盘操作的时候。第二不随意动分区表。看到某个分区的 UUID 变化很正常但自己去fdisk改类型、删分区极可能引发引导崩溃。第三每次做可能有风险的操作前想想数据备份问题哪怕只是把 /etc、/boot 目录复制出来也比没有强。我最开始修引导的时候也干过在 grub rescue 下误删分区的蠢事。现在修引导养成了固定习惯先ls把所有分区列出来再set看当前上下文最后才动手设置参数。这个习惯帮我避开了很多不必要的坑。根据我个人经验grub 命令行问题百分之九十都不是灾难而是「配置丢失」加上「专业知识不够」造成的心理恐慌。只要你理解了 GRUB 查找配置文件的路径逻辑知道了手动引导内核这五个步骤大部分情况都能当场解决。剩下那百分之十交给 Live USB 和 grub-install 收尾也足够了。最后分享一个小技巧。grub 命令行下TAB键真的很好用你不需要记住完整的内核版本号输入前缀后按 TAB所有候选文件都会列出来。手动引导时我就是靠这个少走了很多弯路。下次再遇到minimal bash-like line editing is supported先深吸一口气然后按这个思路一步步来。
