凌晨两点半手机在床头柜上疯狂震动。群里一句话让我彻底清醒某台服务器起不来了业务反馈直接中断。我远程连过去一看屏幕停在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 常见引导故障的典型形态把故障形态提前认熟排查时可以省大量时间。我按启动阶段归类整理了一些常见表现启动阶段典型症状大致原因固件黑屏无响应、找不到启动设备磁盘掉线、UEFI 启动项丢失GRUB停在grub rescue、grub引导模块路径不对、grub.cfg 丢失内核Kernel panicVFS 无法挂载根文件系统根分区参数错误、驱动缺失initramfs无法挂载 sysroot、找不到根设备磁盘不被识别、文件系统损坏systemd卡在某个 service、进入 emergency mode服务配置错误、文件系统只读、SELinux 问题故障形态对应的修复路径是完全不同的。固件阶段基本靠硬件层排查比如进 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然后按Ctrlx启动。系统会尝试进入 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.unitemergency.target进入紧急模式。selinux0临时关闭 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 及以上主流版本。完整步骤如下开机进入 GRUB 菜单选中当前内核所在条目按e进入编辑模式。找到以linux或linux16开头的那一行移动到行尾在后面加一个参数rd.break。按Ctrlx启动。系统在 initramfs 阶段中断出现类似switch_root:的提示符 shell。此时根目录还是 initramfs 的真正的根文件系统挂在/sysroot下。先重新挂载为可读写mount -o remount,rw /sysroot切换根目录chroot /sysroot执行密码重置passwd root之后是很多人容易漏掉的一步。因为这次修改发生在 initramfs 环境下进程的 SELinux 上下文比较混乱为了让系统重启后按正常安全策略重新标记文件在当前根目录下创建一个标记文件touch /.autorelabel连续执行两次exit第一次退出 chroot第二次退出当前 shell系统会继续正常的启动流程并自动重启。第一次操作时很多人会在touch /.autorelabel上犹豫觉得这步可有可无。我的建议是除非你的系统本来就关闭了 SELinux否则都做这一步代价仅仅是重启时会有一个文件重标记过程耗时几分钟但能避免若干诡异问题比如重启后系统提示 “Failed to load SELinux policy”。3.2 场景二系统完全起不来用救援模式 chroot 重置如果你的系统连 GRUB 菜单都不显示了停留在grub rescue那就放弃单用户模式这条路直接上安装介质进救援模式。步骤如下用安装光盘或 U 盘启动选 “Troubleshooting” → “Rescue a system”。当提示选择 Continue、Read-Only、Skip 时默认选 1Continue。系统会尝试把原系统挂载到/mnt/sysimage。挂载完成后chrootchroot /mnt/sysimage现在你已经在原系统的根文件系统里了直接重置密码passwd root退出 chrootexit重启系统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/shadowPAM 的问题则更多出现在一些做过加固、改了/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.cfgUEFI 启动模式grub2-install --targetx86_64-efi grub2-mkconfig -o /boot/grub2/grub.cfg这里的关键坑在于 UEFI 模式的移动介质引导上来时可能已经在读 EFI 分区里的文件了直接跑grub2-install有时会装到介质所在环境上。稳妥的做法是先确认挂载状态在 chroot 之前看看 EFI 分区是否已经被挂载到/mnt/sysimage/boot/efi。如果没挂载手动挂载一下再 chrootmount /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 故障速查表日常排障时有一张速查表会非常有用。我按“症状、方向、处理手段”三个维度整理了一张症状可能原因核心处理手段grub rescue且 ls 报 unknown filesystemGRUB 无法识别分区或文件系统模块缺失手动 set prefix insmod normal失败则救援模式重装grub菜单内启动报 file not foundgrub.cfg 或 vmlinuz 文件缺失/路径不对手动 linux initrd boot进系统后重新生成 cfg内核启动后 VFS panic根分区参数错误或 root 分区不可识别检查启动参数中的 root 设备号就近 fsck文件系统只读无法修改异常断电/脏数据单用户或救援模式里fsck修复root 密码正确但登录被拒SELinux 上下文或 PAM 配置问题restorecon /etc/passwd /etc/shadow检查 securetty修改密码重启后系统长时间停滞重标记SELinux autorelabel 过程一般等待即可若反复标记则检查磁盘空间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这种问题完全可以杜绝。整个引导修复的过程说到底就是“确认阶段、进入环境、定点修、验证重启”四个步骤。多练几次你会发现那些让人手忙脚乱的场景其实每个都有清晰的解决路径。下次遇到半夜的告警电话至少你能在连接服务器之前在心里把排查路线图大体过一遍心里不慌手上的命令自然就不会乱。