Linux引导故障全解析：从GRUB修复到root密码重置

凌晨两点半，手机在床头柜上疯狂震动。群里一句话让我彻底清醒：某台服务器起不来了，业务反馈直接中断。我远程连过去一看，屏幕停在grub rescue>提示符上，引导文件找不到，系统连内核都没开始加载。这种事，做运维的人多少都碰过一两回。今天我把 Linux 引导和系统修复这摊事完整梳理一遍，从启动链路讲起，覆盖单用户模式、救援模式、GRUB 修复、root 密码重置这些核心操作，既是记录，也希望帮刚入门的朋友少走几个弯路。

1. 先搞清楚：Linux 构建启动的完整链路

1.1 从按下电源键到登录界面，中间发生了什么

很多人一遇到系统起不来就慌，其实大部分引导问题都能通过“定位启动到哪一步挂了”来解决。Linux 启动链路大致可以分成四个阶段：固件初始化、引导加载器、内核与 initramfs、systemd 初始化用户环境。

固件阶段是 BIOS 或 UEFI 的工作，它负责做自检、识别磁盘，然后把控制权交给磁盘上特定位置的引导代码。BIOS 时代是读取 MBR 里的引导程序，UEFI 时代则是通过 EFI 分区里的.efi文件来启动。这个阶段挂了，通常什么都看不到，或者停留在黑屏加光标。

第二个阶段是引导加载器，现代 Linux 几乎都是 GRUB2。GRUB2 要做的事有两件：加载自身的核心模块，然后读取/boot/grub2/grub.cfg配置文件，把菜单显示出来。我们平时看到的开机菜单就是 GRUB2 在跑。这阶段如果挂了，典型症状就是grub rescue>或者grub>提示符。

第三个阶段是内核和 initramfs。GRUB2 加载 vmlinuz 内核镜像和 initramfs（常常叫 initrd），然后内核解压，initramfs 被挂载为临时根文件系统，里面包含各种硬件驱动和存储驱动，目的是让系统能够识别真正的根分区。然后内核把根文件系统挂载到/，从 initramfs 切换到真正的系统根目录。

第四阶段是 systemd 接管。它启动默认目标（通常是 multi-user.target 或者 graphical.target），依次挂载分区、启动服务、拉起网络和业务进程。这阶段的问题更多表现为“卡在某某服务启动”或进入 emergency 模式。

启动链路就像坐地铁换乘：固件是第一站，GRUB 是换乘通道，内核是列车，systemd 是出站后的接驳车。任何一个环节断掉，人就走不到目的地。排查引导故障，本质上就是在回答“我到底在第几站下的车”。

1.2 GRUB2 在系统中到底是什么角色

GRUB2 之所以重要，是因为它承担了“把内核从磁盘找出来并交给 CPU”的关键工作。它分成三部分：第一部分写进了 MBR 或 EFI 启动项，第二部分是/boot/grub2/目录下的 core 镜像和模块，第三部分是配置文件grub.cfg。

很多引导故障其实是第二部分或第三部分出了问题：MBR 里的引导代码没坏，但它找不到/boot分区上的 core.img，或者找到了 core.img 但读不出grub.cfg，这时候就会落到grub rescue>提示符。注意rescue模式意味着 GRUB 只加载了最基础的内置模块，几乎所有文件系统模块都没加载，所以它能用的命令非常有限。

理解这一点有个直接好处：当你看到grub rescue>时，不要下意识认为“系统废了”。只要磁盘本身没坏，用set prefix和insmod手动把 GRUB 模块指对路径，就能进入正常菜单，或者直接手动引导内核启动。后文我会把具体命令写出来。

1.3 常见引导故障的典型形态

把故障形态提前认熟，排查时可以省大量时间。我按启动阶段归类整理了一些常见表现：

故障形态对应的修复路径是完全不同的。固件阶段基本靠硬件层排查，比如进 BIOS/UEFI 设置看磁盘是否识别、调整启动顺序；GRUB 阶段靠手动引导或重装 GRUB；内核和 initramfs 阶段靠调整启动参数或者修文件系统；systemd 阶段则更多是进单用户模式修配置。

2. 修复工具箱：单用户、救援模式与临时启动参数

2.1 单用户模式：最小化环境救急

单用户模式（single user mode）是 Linux 运维的看家本领。它的原理是让 systemd 运行一个最简目标，只挂载必要的文件系统，不启动网络和业务服务，直接给你一个 root shell，用来修复系统。

在 RHEL/CentOS 7 之后的 systemd 时代，通过编辑 GRUB 启动参数进单用户模式，有几种常见做法。一个传统做法是在 GRUB 菜单选中内核后按字母e进入编辑界面，找到以linux开头的那一行（可能是linux或linux16），在行尾加上single，然后按Ctrl+x启动。系统会尝试进入 single.target，但这里有个坑：较新版本的 RHEL 系系统进入单用户模式时，如果 root 有密码，会再次要求输入密码。如果你本来就是来重置密码的，这条路就走不通了。

所以实际的密码重置场景里，我更推荐另一个参数rd.break。同样是在内核启动参数行尾加rd.break，启动过程会在 initramfs 阶段和真正根文件系统切换之前中断，此时你直接获得一个无密码要求的 shell，可以操作/sysroot目录（也就是最终要挂载为根的文件系统）。这两个参数的区别很关键：single是“系统尽量正常地进入维护态”，rd.break是“在切换根目录前强行暂停”，后者对忘记密码来说是真正的后门。

进入单用户模式后还有个常见问题：根文件系统常常是只读挂载的。这是因为系统此时还没有完整启动，文件系统以只读方式打开更安全。需要先执行：

mount -o remount,rw /

或者操作/sysroot时：

mount -o remount,rw /sysroot

不重新挂载为读写，后面的修改会直接报只读文件系统错误。

2.2 救援模式：当系统完全起不来时的救生圈

如果 GRUB 损坏到手动引导都困难，又或者系统分区本身有问题，单用户模式可能都进不去。这时候你需要一张安装介质——光盘或 U 盘都行——通过介质引导进入“救援模式”。

以 RHEL/CentOS 系列为例，从安装介质启动后，选择 “Troubleshooting”，再选 “Rescue a system”，安装程序会尝试自动发现磁盘上的 Linux 系统。它会问你三个选项：Continue（继续并挂载）、Read-Only（以只读方式挂载）、Skip（跳过不挂载）。正常修复选 Continue，系统会被挂载到/mnt/sysimage这个目录下。

救援模式的核心价值在于chroot。执行chroot /mnt/sysimage后，你在这个环境里的根目录就变成了原系统的根目录，可以直接调用原有的命令、脚本和配置来修复系统。这一步做完，修密码、重装 GRUB、修复软件包都变得和在一台正常运行的系统上操作一样。后面要涉及的密码重置和 GRUB 重装，都是基于救援模式 + chroot 这套组合。

一个细节：如果你选的是 Continue 但挂载失败了，别硬来，退回去改选 Skip，手动先修文件系统。系统提示挂载失败往往意味着分区有文件系统错误，这时候优先跑一下fsck才是正路。

2.3 临时修改内核启动参数：沿用本次生效

GRUB 菜单里按e修改参数，这种修改是临时的，只在当前这次启动生效，重启后恢复原状。它的好处是风险低，改坏了也就影响这一次启动，重启还能再改。日常最常用的临时参数有这几个：

• single或1：进入单用户模式。
• rd.break：中断在 initramfs 阶段。
• systemd.unit=emergency.target：进入紧急模式。
• selinux=0：临时关闭 SELinux，用于排查 SELinux 导致的启动问题。
• rw init=/bin/bash：直接用 bash 代替 systemd，启动后直接得到一个 root shell。

最后一个init=/bin/bash也值得掌握。把内核参数里的rhgb quiet删掉，改成init=/bin/bash，内核启动后不会启动 systemd，而是直接执行/bin/bash。这种方式的优点是极简，不受 systemd 和 SELinux 策略干扰；缺点是很多文件系统不是你想要的状态，很可能需要手动mount -o remount,rw /，而且这种方式下/proc、/dev等虚拟文件系统也没挂载，某些命令可能行为异常。它的应用场景很明确：用于单用户模式都进不去、但内核能正常加载的情况。

2.4 三个工具的适用场景怎么选

经常有人问：“我应该用单用户模式还是救援模式？”其实判断标准很简单：看你还能不能进 GRUB 菜单。能进就用单用户或临时参数，这是最省事的；如果 GRUB 已经坏了、屏幕上是grub rescue>，那基本只能靠救援模式或者手动引导。

单用户模式适合系统本身能启动，但需要修复配置、改密码、禁用某个服务、修 fstab 这类场景；救援模式适合 GRUB 损坏、文件系统异常、系统无法挂载根分区这类“硬件还能认辨，操作系统已经指望不上”的场景；临时内核参数则是前两者的敲门砖，几乎所有修复技巧的第一步都是通过编辑启动参数进入一个能操作的环境。

3. root 密码遗忘了？按场景分成三类解法

3.1 场景一：能进 GRUB，用 rd.break 重置密码

这是最经典的密码重置场景，适用范围是 RHEL 7/8/9、CentOS 7 及以上主流版本。完整步骤如下：

1. 开机进入 GRUB 菜单，选中当前内核所在条目，按e进入编辑模式。
2. 找到以linux或linux16开头的那一行，移动到行尾，在后面加一个参数：rd.break。
3. 按Ctrl+x启动。
4. 系统在 initramfs 阶段中断，出现类似switch_root:的提示符 shell。
5. 此时根目录还是 initramfs 的，真正的根文件系统挂在/sysroot下。先重新挂载为可读写：

mount -o remount,rw /sysroot

6. 切换根目录：

chroot /sysroot

7. 执行密码重置：

passwd root

8. 之后是很多人容易漏掉的一步。因为这次修改发生在 initramfs 环境下，进程的 SELinux 上下文比较混乱，为了让系统重启后按正常安全策略重新标记文件，在当前根目录下创建一个标记文件：

touch /.autorelabel

9. 连续执行两次exit（第一次退出 chroot，第二次退出当前 shell），系统会继续正常的启动流程并自动重启。

第一次操作时，很多人会在touch /.autorelabel上犹豫，觉得这步可有可无。我的建议是除非你的系统本来就关闭了 SELinux，否则都做这一步，代价仅仅是重启时会有一个文件重标记过程，耗时几分钟，但能避免若干诡异问题，比如重启后系统提示 “Failed to load SELinux policy”。

3.2 场景二：系统完全起不来，用救援模式 chroot 重置

如果你的系统连 GRUB 菜单都不显示了，停留在grub rescue>，那就放弃单用户模式这条路，直接上安装介质进救援模式。

步骤如下：

1. 用安装光盘或 U 盘启动，选 “Troubleshooting” → “Rescue a system”。
2. 当提示选择 Continue、Read-Only、Skip 时，默认选 1（Continue）。
3. 系统会尝试把原系统挂载到/mnt/sysimage。挂载完成后，chroot：

chroot /mnt/sysimage

4. 现在你已经在原系统的根文件系统里了，直接重置密码：

passwd root

5. 退出 chroot：

exit

6. 重启系统：

reboot

这个方法本质上和场景一是一样的，区别只在于环境来源：一个是内生的临时 shell，一个是外来介质搭起的临时环境。如果是在救援模式里重设了密码，同样建议回到原环境后确认 SELinux 策略状态，必要时也做touch /.autorelabel，或者对/etc/shadow单独执行：

restorecon -v /etc/shadow

这里要提醒一句：不要觉得有安装介质就能为所欲为，救援模式同样依赖系统分区能被正常识别。如果磁盘硬件已经故障，或者文件系统损坏严重，救援模式也会卡住。

3.3 场景三：密码改完了，系统还是进不去

改完密码后重启，结果还进不去系统，这种情况我在实际运维中遇见过不止一次。排查方向主要有两个：一个是 SELinux 的问题，一个是认证模块（PAM）的问题。

SELinux 的问题表现很典型：root 登录时提示密码错误，或者明明输对了密码却被拒。原因通常是/etc/shadow或/etc/passwd的 SELinux 标签被改坏了。上文提到的touch /.autorelabel就是为此准备的。如果当初没做这步，可以在能进的单用户或救援模式下执行：

restorecon -v /etc/passwd /etc/shadow

PAM 的问题则更多出现在一些做过加固、改了/etc/pam.d/下配置的系统上。这种情况排查起来更麻烦，常见做法是在单用户模式下按faillock --user root --reset清理登录失败记录，或者检查/etc/securetty是否把虚拟终端限制住了。如果这些都没问题，再去看系统日志/var/log/secure和/var/log/messages中的认证记录。

有些时候，进不去的根源甚至不是密码，而是/etc/shadow文件被锁定了。检查一下 shadow 文件中 root 这行的第二个字段：如果看到root:!!:...或者root:*:...，说明账户密码被锁或禁用，用passwd -u root解锁即可。

3.4 密码修复后的加固建议

密码修好后别急着关机收工，顺手做几件事可以避免下次再翻车：

• 将 root 密码放入企业内部密码保险箱或至少用密码管理器保存，避免只存在某个人的脑子里。
• 为 root 登录配置多因子认证或限制 SSH 直接 root 登录，改用普通用户加 sudo 的方式管理服务器。
• 记录清楚系统是 RHEL 系还是 Debian 系，发行版不同，配置路径（比如/etc/grub2/grub.cfg还是/boot/grub/grub.cfg）和命令（grub2-mkconfig还是update-grub）都不同，操作前先确认一下。这一点对基础操作者来说非常实用，很多人第一次翻车就是因为照搬了一个其他发行版上的教程。

4. GRUB 引导文件损坏的修复实操

4.1 引导损坏的典型表现与成因

GRUB 相关故障绝对是 Linux 服务器不能启动的“头号嫌疑”。比较典型的表现有：

• 启动后停滞在grub rescue>提示符，输入命令都会报 “unknown filesystem”。
• 启动后进入grub>提示符，没有菜单，没有grub.cfg。
• 启动时报 “error: file/boot/grub2/grub.cfgnot found”。
• 屏幕上只有GRUB或GRUB Loading...就卡住不动了。

成因方面，常见的有这么几类：磁盘分区布局变化（比如有人重新调整过分区）、MBR 或 EFI 启动项被覆盖、/boot分区写满了导致新内核文件写入失败、误删了/boot下的文件，以及/etc/default/grub配置被改坏后重新生成配置时出错。

排查引导损坏前，先确认一个问题：是不是磁盘故障导致的？如果grub rescue>出现后连ls命令都看不到磁盘列表，或者磁盘在 BIOS/UEFI 里都不见了，那引导问题只是冰山一角，优先处理磁盘才是重点。

4.2 在救援模式下重装 GRUB 两步走

最稳妥的修复方式还是救援模式 + chroot。进入救援模式并chroot /mnt/sysimage后，重装 GRUB 一般就两个命令，但对不同启动模式要注意区分。

BIOS 传统启动模式：

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

UEFI 启动模式：

grub2-install --target=x86_64-efi grub2-mkconfig -o /boot/grub2/grub.cfg

这里的关键坑在于 UEFI 模式的移动介质引导上来时，可能已经在读 EFI 分区里的文件了，直接跑grub2-install有时会装到介质所在环境上。稳妥的做法是先确认挂载状态：在 chroot 之前看看 EFI 分区是否已经被挂载到/mnt/sysimage/boot/efi。如果没挂载，手动挂载一下再 chroot：

mount /dev/sda1 /mnt/sysimage/boot/efi chroot /mnt/sysimage

另外要提醒：grub2-mkconfig生成的配置文件会继承/etc/grub2.cfg软链接和/etc/default/grub里的配置，运行前可以先用cat /etc/default/grub确认 GRUB_TIMEOUT、GRUB_DEFAULT 这些参数没有明显错误。

4.3 不重装也能救：grub 命令行手动引导

有些场景下你不想依赖安装介质（比如手边没有），但系统停在grub rescue>或grub>。这种情况下还有一条路：手动让 GRUB 加载内核并启动。

如果是grub rescue>模式，先要加载常规模块并进入 normal 模式。假设你的/boot分区在第一块磁盘的第一个分区：

grub rescue> set prefix=(hd0,msdos1)/boot/grub2 grub rescue> insmod normal grub rescue> normal

如果这一步成功，屏幕会回到熟悉的 GRUB 菜单。如果 normal 命令执行报错，说明 GRUB 模块文件本身也缺失了，那就只能靠救援介质。

如果已经进入grub>模式（模块已在内核列表里），可以直接手动引导内核。在命令行分别设置根设备、加载内核、加载 initramfs、启动：

grub> set root=(hd0,msdos1) grub> linux /vmlinuz-4.18.0-477.10.1.el8_8.x86_64 root=/dev/sda2 grub> initrd /initramfs-4.18.0-477.10.1.el8_8.x86_64.img grub> boot

命令中的文件名要以/boot目录下实际存在的为准。不确定当前有什么内核时，可以先在 GRUB 命令行执行：

grub> ls grub> ls (hd0,msdos1)/

然后用cat命令配合 Tab 键补全来查看/boot目录下的文件。手动引导成功后，建议还是进入系统执行一次grub2-mkconfig -o /boot/grub2/grub.cfg，因为手动引导只是救急，不会修复配置本身。

4.4 修复完成后的验证与备份

修复完成后重启前，花两分钟做验证，能防止修复完毕后还是起不来白忙一场：

• 确认修复目标磁盘是系统启动盘，而不是误把 GRUB 装到了数据盘上。可以用lsblk检查磁盘分区和挂载点。
• 确认/boot/grub2/grub.cfg里默认内核对应文件在当前/boot目录下。检查时直接看文件名对应关系。
• UEFI 系统上检查 EFI 启动项顺序，可以进 BIOS/UEFI 设置确认，也可以系统启动后用efibootmgr -v查看。

平时就应该做一次引导备份：把grub.cfg备份到系统其他分区，比如/root/backup/，同时记录手动引导命令，这样一旦出错不用翻文档。对靠 UEFI 引导的机器，还可以把 EFI 分区里的 bootloader 文件做一个归档备份，恢复时直接覆盖回去。

5. 常见问题与排查技巧实录

5.1 故障速查表

日常排障时有一张速查表会非常有用。我按“症状、方向、处理手段”三个维度整理了一张：

5.2 排障顺序建议

在服务器前千万不要“想到什么试什么”。正确的姿势是按启动链路的顺序逐步确认：

先确认硬件层：进到固件界面，看一眼磁盘能否识别、启动顺序是否正常；再确认引导加载器：当前停在哪一层、GRUB 是否进入了、能否列目录；接着确认内核与根分区：内核参数里的root=指向是不是实际存在的分区，/etc/fstab里的配置是否正确；最后确认系统服务层：如果已经能进单用户或 emergency 模式，通过日志和服务状态排查具体原因。

有一个非常常见的低级错误是：系统里有多块磁盘，修复时把root=设备号写成了另一块盘，导致内核挂载根失败。这种情况在initrd使用 UUID 标识根分区时其实不太常见，但在手动引导内核时极其容易踩中。手动引导时建议优先采用 UUID 指定根分区，而不是/dev/sdaX这种设备名，因为设备名在系统重启时有可能会变化。

5.3 平时就该做的三项预防措施

我在实际运维生涯里最大的体会是：引导修复操作对熟练度要求非常高，临场学是来不及的。预防措施比修复能力更重要，至少有这三件事值得落实。

第一，给重要系统配置带外管理（IPMI/iDRAC 之类），确保即使系统完全起不来，也能通过网络看到控制台画面。很多引导问题在显示屏前端几秒钟就能判断出来，没有远程控制台就只能跑机房，处理效率完全两回事。

第二，建立操作预案文档，针对每台服务器的启动方式是 BIOS 还是 UEFI、根分区在哪块盘、内核文件通常在哪个目录，写清楚。这份预案平时不用，真出事了就是救命文档。

第三，定期在虚拟机或容器环境里演练一遍“忘记密码 + 引导损坏”的修复流程。不需要很频繁，每季度一次就行。只有练熟了，生产环境出问题时手才稳。事实上我自己第一次成功修复一台 KVM 虚拟机的 GRUB，靠的就是之前在一个完全相同的模拟环境里反复折腾出来的肌肉记忆。

再补一个很多人忽略的细节：执行任何引导修复命令前，先花 30 秒看当前系统的磁盘布局和挂载状态。修复操作本身并不复杂，但操作对象搞错才是真正让运维翻车的原因。曾经有同事在双盘服务器上执行grub2-install /dev/sda时，漏看了 sda 和 sdb 的系统盘顺序，结果把两块盘的 MBR 都装了一遍引导，系统重启后虽然能进，但另一块盘上的数据盘差点被影响。动手前多看一眼lsblk，这种问题完全可以杜绝。

整个引导修复的过程，说到底就是“确认阶段、进入环境、定点修、验证重启”四个步骤。多练几次，你会发现那些让人手忙脚乱的场景，其实每个都有清晰的解决路径。下次遇到半夜的告警电话，至少你能在连接服务器之前，在心里把排查路线图大体过一遍，心里不慌，手上的命令自然就不会乱。