今天早上朋友的公司服务器趴窝了开机后黑底白字屏幕上只有一行提示GRUB后面跟着一个闪烁的光标。那是一台 CentOS 7 的 Linux 服务器之前跑着数据库现在连系统都进不去。他第一反应是重装系统我跟他说先别急GRUB这个命令提示符对应的情况大部分是引导配置文件损坏系统本身远没到需要重装的地步。这篇文章就是专门讲这种情况的。开机进不了系统、卡在 GRUB 命令提示符看着吓人其实套路非常固定先手动敲命令把系统带起来再进系统重装引导器最后恢复 GRUB 配置。整个过程 10 分钟就能完成不需要重装系统数据也不会丢。适合所有用 Linux 做服务器、做开发环境或日常主力系统的朋友收藏尤其是那些和我一样曾经被 GRUB 界面吓得半夜爬起来翻文档的人。1. 先搞明白GRUB 提示符到底在“喊什么”1.1 这个现象和“Windows 进不去系统”有什么不同很多人第一次见到GRUB会被吓到因为它既不是 Linux 的登录界面也不是常见的错误弹窗而是一个看起来十分原始的交互环境。光标悬在GRUB后面敲什么命令都没反应让人误以为系统彻底废了。实际上这个界面是 GRUB 2 的“最小命令行模式”。简单说GRUB 相当于 Linux 的引导大厅它的正式工作流程是开机后去读取配置文件/boot/grub2/grub.cfg根据里面的菜单把内核加载进内存然后交棒给 Linux 内核。现在你看到GRUB说明配置文件没读到GRUB 只能退而求其次给你一个手动输入命令的最小环境。这和 Windows 进不去系统有本质区别。Windows 蓝屏或者引导损坏常常意味着系统文件丢失修复手段有限。但 Linux 的 GRUB 只是一个前端引导器它本身只有几百 KB损坏的往往只是配置文件内核文件、系统库、数据库数据都完好无损地躺在硬盘里。你只要在GRUB下用几条命令像开发环境启动时设置参数一样手动把内核拉起来整个系统就能正常进入。这也是 Linux 引导机制最抗造的地方——只要内核还在系统就有救。1.2 为什么会掉到 GRUB搞清楚损坏点在哪个环节GRUB出现的原因五花八门但归结起来无非是下面这几类我整理成一张表方便对照排查故障类型典型场景损坏点配置文件丢失/损坏手动编辑 grub.cfg 时格式错误、断电导致写入不完整/boot/grub2/grub.cfg 缺失或语法错误引导器未安装/被覆盖重装 Windows 后 MBR 被覆盖、克隆硬盘后没有重装 GRUB磁盘主引导记录上的 GRUB 代码丢失分区表变动删除了 Linux 分区、重新分区后分区号改变grub.cfg 中的 root 指向旧分区内核升级失败升级内核过程中断电、yum/apt 信息中断vmlinuz、initramfs 文件名不匹配硬件变更更换硬盘、SSD 接管系统后接口顺序变化设备名比如 /dev/sda 变成了 /dev/nvme0n1这几种情况里配置文件损坏和分区变动占到了九成以上。而且注意一个细节GRUB 菜单本身是“可显示但启动失败”还是“完全进不了 GRUB 菜单”对应的问题层级是不一样的。如果你能看到 GRUB 菜单只是选择内核后启动失败问题多在内核参数或 initramfs如果你开机后直接掉进GRUB那几乎可以断定是 grub.cfg 没被正确读取GRUB 只能启动自己的命令行。理解这一点很关键因为它决定了你的修复思路——先找配置文件再考虑重装引导器。大多数人一上来就 grub-install 重装引导器结果发现开机还是GRUB就是因为没搞清楚真正掉链子的环节其实在配置文件上。2. 手动引导不重装系统一条命令一条命令启动2.1 第一步用 ls 找出“系统盘在哪”在GRUB环境下没有任何图形界面也没有 man 手册唯一的工具就是 GRUB 内建命令。好在 GRUB 2 自带一套精简的命令集足够我们完成手动引导。第一件事搞清楚硬盘和分区的情况。输入lsGRUB 会列出它能识别的所有设备常见的输出是这样(hd0) (hd0,msdos1) (hd0,msdos2) (hd1) (hd1,gpt1) (hd1,gpt2)解释一下(hd0)是第一块物理硬盘(hd0,msdos1)表示第一块硬盘上的第一个 MBR 分区(hd1,gpt2)表示第二块硬盘上的第二个 GPT 分区。如果你以前用过 fdisk这里的命名逻辑和 /dev/sda1、/dev/nvme0n1p2 一一对应只是换了套马甲。我的习惯是继续用ls带路径的方式逐个分区探测文件系统找到那个装着/boot目录的分区。GRUB 的ls支持查看指定分区的文件列表操作方式ls (hd0,msdos1)/如果分区是 Linux 文件系统你会看到boot/、etc/、home/之类的顶层目录如果分区是 NTFS 或 FAT会看到 Windows 相关的目录结构。通常/boot目录就在根分区的boot/子目录里或者单独划了一个/boot分区——后一种情况下你会直接在某个分区根目录下看到grub2/、vmlinuz-*这些文件。注意如果你在某个分区上执行ls (hd0,msdos1)/得到了error: unknown filesystem说明这个分区不是 GRUB 能直接识别的文件系统直接跳过继续下一个。2.2 第二步设置 root 和 prefix让 GRUB 找到自己家找到了装有/boot的分区之后我们得告诉 GRUB 两件事根分区在哪配置文件目录在哪。把刚才确定的那个分区设置为 rootset root(hd0,msdos1)然后告诉 GRUB 去哪里找它的模块和配置文件这一步叫设置 prefixset prefix(hd0,msdos1)/boot/grub2注意不同发行版路径不一样。CentOS、RHEL 系是/boot/grub2Ubuntu、Debian 系是/boot/grub用哪个取决于你的发行版建议先用ls (hd0,msdos1)/boot/看一眼实际目录名再设置。设置完后可以验证一下能不能正常读取ls $prefix如果正常你会看到 grub.cfg、fonts、locale、i386-pc或 x86_64-efi等目录和文件。到了这一步GRUB 基本上苏醒了大半接下来就要加载内核。2.3 第三步加载内核并启动linux initrd boot设置好 root 和 prefix 后我们要做两件事加载内核镜像加载 initramfs 内存磁盘镜像。这两个文件都在/boot目录下注意版本号要和实际文件匹配建议先用ls (hd0,msdos1)/boot/看看文件名再操作。加载内核的命令linux /boot/vmlinuz-3.10.0-1160.el7.x86_64 root/dev/sda1注意两点。第一/boot/vmlinuz-*前的/boot路径可否省略取决于你的 root 分区是不是根分区本身。如果 root 是单独挂载的/boot分区这里直接写/vmlinuz-3.10.0-1160.el7.x86_64而不是/boot/vmlinuz-...。第二root参数指定的是 Linux 根分区的设备名注意这里已经不是 GRUB 的(hd0,msdos1)写法了而是要写成内核能识别的设备名比如/dev/sda1或UUIDxxxx。如果你不确定根分区设备名可以先执行cat (hd0,msdos1)/etc/fstab查看系统自己记录的根分区配置再照抄。接着加载 initramfsinitrd /boot/initramfs-3.10.0-1160.el7.x86_64.img这一步的作用是加载一个包含必要驱动的最小文件系统让内核有能力挂载真正的根分区。有些资料里把它写作 initrd有些写作 initramfs实际在 GRUB 2 中initrd 是通用命令initramfs 是它的别名用哪个都能识别。最后执行boot如果不出意外你会看到内核启动日志哗啦啦输出然后系统顺利进入登录界面。走到这一步数据全在系统也活了心里那块石头算是落地了。重要提示手动引导成功后一定要在系统里继续执行第 3 节的修复操作。如果你重启问题原样重现因为刚才的命令只是“临时救火”并没有把任何改动写入磁盘。3. 真正修复让系统下次不再“掉进”GRUB3.1 进入系统后先确认分区和引导设备登录系统后先别急着执行修复命令先搞清楚现状。用df -h看一下挂载情况确认根分区和 /boot 分区是否正常df -h正常的话你能看到/dev/sda1挂在/boot或根分区下。然后查看一下引导相关文件是否齐全ls -l /boot/检查是否有vmlinuz-*、initramfs-*.img、grub2/Ubuntu 下是grub/这些关键内容。接着查看磁盘分区表的信息lsblk这一步的核心任务是确认——系统里实际存在的磁盘顺序、分区编号是否和刚才GRUB下手动操作时一致。如果系统里有多个磁盘而且你刚才手动引导时是通过逐个尝试找到系统的那几乎可以肯定分区顺序发生变化是这次故障的根本原因。3.2 grub-install 和 update-grub 的正确姿势确认现状以后就可以正式修复了。修复的逻辑分两步重新安装 GRUB 到磁盘的主引导记录让它开机时能找到并读取配置文件重新生成 grub.cfg 配置文件让它包含正确当前的内核和分区信息。第一步安装 GRUB。CentOS/RHEL 系统grub2-install /dev/sdaUbuntu/Debian 系统grub-install /dev/sda注意这里写的是/dev/sda是整个磁盘设备不是/dev/sda1。GRUB 要安装到磁盘的引导区域上分区号是多余的会直接报错。如果你的系统启用了 UEFI 启动那操作方式略有不同需要在 EFI 系统分区上安装grub2-install --targetx86_64-efi --efi-directory/boot/efi第二步重新生成配置文件。CentOS/RHEL 系grub2-mkconfig -o /boot/grub2/grub.cfgUbuntu/Debian 系update-grub执行完成后grub.cfg 会被基于当前系统状态重新生成里面会自动识别新的内核版本、根分区 UUID 等参数。这一步是解决“配置文件损坏或分区变动”的根治手段。跑完这两步理论上你的系统已经具备了正常引导的能力。3.3 修复后验证与测试修复完成后不要急着关机重启先在系统里验证一下配置文件的正确性。用cat查看生成出来的 grub.cfg重点检查菜单入口是否指向了正确的根设备grep root /boot/grub2/grub.cfg正常情况下你会看到类似root/dev/mapper/centos-root或rootUUIDxxxxx这样的参数确认指向的确实是当前的根分区。然后再验证一下 GRUB 的安装情况grub2-install --version接下来就可以重启测试了。但我建议你在重启前多做一件事——拍下当前的引导状态。方法很简单用手机把lsblk的输出、grub.cfg 中 root 参数的部分都拍下来万一重启后又有问题这些信息能帮你快速定位不用再瞎猜。4. 实战故障排查我踩过的坑和排查套路4.1 常见故障快速排查表这么多年和 GRUB 打交道我整理了一份高频问题速查表遇到类似情况可以直接对照现象原因分析快速处置开机黑屏只有 GRUBgrub.cfg 路径不对或文件缺失手动设置 set root、set prefix 后启动执行 ls 时 error: unknown filesystem该分区无 GRUB 可识别的文件系统换其他分区逐个试加载 linux 后提示 file not foundvmlinuz 文件名写错或多个内核版本存在ls /boot/ 确认准确文件名boot 后卡在 kernel panic - not syncingroot 参数不对内核挂载不上根分区查看 /etc/fstab 确认根分区设备名重启后依然进 GRUB只做了手动引导没执行 grub-install/mkconfig进系统后依次执行第 3 节修复步骤双系统开机无 Linux 菜单Windows 覆盖了引导记录Live USB 进系统重装 GRUB4.2 三个容易忽略的细节第一个细节也是我刚开始排查时最容易犯的错GRUB 的设备名和 Linux 设备名不对应。GRUB 里的(hd0,msdos1)不等于 Linux 里的/dev/sda1尤其在有多块硬盘或开启了 BIOS 磁盘映射的情况下顺序可能完全不同。如果你在 GRUB 下手动设置 root 之后加载内核时用了错误的root/dev/sda1内核直接 panic。我现在的做法是在GRUB下尽量用 UUID 指定 root 参数通过ls (hd0,msdos1)/etc/fstab先把系统的原始配置读出来再照抄里面的 UUID稳妥可靠。第二个细节UEFI 和 BIOS 是两套完全不同的引导方案。如果你在 UEFI 模式的机器上用传统的 grub-install /dev/sda会得到一个“假装成功”的安装结果但重启后掉进 GRUB 的概率极高。排查时先确认启动模式开机进 BIOS 设置里看是 Legacy 还是 UEFI或者查看系统里是否有/sys/firmware/efi目录有就是 UEFI没有就是传统 BIOS。UEFI 的 GRUB 修复就要用--targetx86_64-efi参数。第三个细节有些场景下 grub2-mkconfig 生成的配置不一定“认识”最新的内核。尤其是用第三方源手动编译安装内核后grub 的 os-prober 可能探测不到。遇到这种情况修复完 grub.cfg 后还要手动检查/boot/loader/entries/或者配置文件里是否出现了新内核的菜单入口如果没有需要单独把新内核的入口补进去。4.3 特殊情况GRUB 下没有 insmod 模块还有一类更麻烦的情况——连 insmod 命令本身都执行不了。正常情况下GRUB 加载需要的模块文件都在/boot/grub2/i386-pc或x86_64-efi目录下如果你在设置 prefix 之前就执行 insmod系统确实会直接提示 command not found。解决思路是把 prefix 指对然后再 insmod。但还有一种更极端的情况整个 /boot 分区物理损坏或文件丢失连 vmlinuz 都没了。这种状态下手动引导已经没有意义正确做法是使用 Live USB 启动应急系统把 /boot 缺失的内核和 initramfs 文件重新装上再执行 grub-install。这属于大手术但好消息是内核文件可以从发行版的安装镜像中提取不需要重装全部系统。5. 防患于未然让 GRUB 别再出现5.1 备份关键引导文件GRUB 修复一次不难但反复出现就很烦人了。我接到过好几个朋友的求助都是修好了之后过了几个月又掉进 GRUB一问原因全都是改过 /etc/fstab 或者调整过分区之后没有再执行 update-grub。所以防患于未然的第一步是养成“改动系统分区后及时更新引导配置”的习惯。每次修改过 /etc/fstab、调整过分区、或者升级过内核后都顺手执行一下grub2-mkconfig -o /boot/grub2/grub.cfgCentOS/RHEL 系这样Ubuntu 用update-grub。同时把 /boot 下关键文件做一次备份方法很多最最简单的就是压缩打包tar czf /root/boot_backup_$(date %F).tar.gz /boot/grub2 /boot/vmlinuz-* /boot/initramfs-*真到了 /boot 文件损毁的地步这个备份就是你的救命稻草。5.2 大版本升级后的检查习惯系统大版本升级也是最容易把 GRUB 搞坏的场景之一。升级过程中如果网络中断、断电或者包管理器在写入引导器阶段抛异常就可能留下一个残缺的 GRUB。我建议你在每次系统大版本升级比如从 CentOS 7 升到 8或者 Ubuntu 跨版本升级后都主动检查一下grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg不需要每次升级内核都做那样确实有点过度操作。但半年一次、或者重装过一次其他系统之后再来一遍是完全有必要的。5.3 备好 Live USB系统崩溃时的底牌不管多熟练总有第一次对上GRUB的时候。我真心建议所有 Linux 用户不管是服务器还是个人电脑都准备一个通用的 Linux Live USB——用启动盘制作工具把 Ubuntu 或 CentOS 的安装镜像写入 U 盘。不需要多么花哨能用 Live 环境启动就行。真到了系统完全起不来的那天Live USB 能让你进入一个临时系统挂载原硬盘、修复 GRUB、抢救数据非常实用。它的存在意义和家里的灭火器一样平时用不到关键时候能翻盘。6 写在最后一次真实救援现场的回顾说回文章开头那台服务器。我当时远程指导朋友一步步在 GRUB 下执行命令。他先是跑ls发现有(hd0,msdos1)和(hd0,msdos2)两个分区逐个看了之后确定系统在 msdos1 上。然后又跑ls (hd0,msdos1)/boot/发现 grub2 目录和 vmlinuz 都在故障原因基本锁定在 grub.cfg 损坏。设置 root 和 prefix加载内核和 initramfs跑 boot大约三分钟服务器就重新登录进去了。他以为是世界末日的问题其实就是几条命令的事。根据我的个人经验GRUB 修复中最怕的不是命令记不住而是心里发慌。很多人一看到这个界面就以为数据全完了手忙脚乱开始搜“如何恢复 Linux 丢失的分区表”结果本来没事的系统被折腾出了事。其实你只要记住一个事实GRUB是一个活着的、可以交互的环境系统内核和绝大部分数据大概率都完好。先用ls摸清现场再手动引导进入系统最后修复引导配置。这个套路走一遍九成故障都能解决。希望这篇文章能帮你在面对开机进不了系统的时刻多一份从容少一次深夜重装。