半夜被叫起来处理服务器起不来的情况大概是每个做运维或者自己搭服务器的人都躲不掉的。我遇到过不少次明明昨天还好好的一次重启之后就卡在黑屏、grub 提示符、或者一堆 filesystem 报错面前。尤其是 root 密码忘记了手边又没留救援盘那种感觉确实很慌。这篇文章就是围绕 Linux 引导和系统修复来写核心内容是三块Linux 从按电源键到登录界面到底经历了什么、出了故障怎么判断卡在哪一步、以及 root 密码忘记之后怎么通过救援环境/单用户模式/chroot 方式把系统救活。不管你是刚入门的运维新人还是自己折腾服务器的爱好者这套思路和命令都是通用的学完之后至少再遇到系统进不去这类问题不会第一反应就是重装系统。1. 引导过程的完整链路为什么修复前必须先弄懂启动顺序很多人一遇到系统起不来就急着搜命令结果越修越乱原因就在于没搞清楚系统现在的启动流程走到了哪一步。修复的前提是理解正常情况下的链路否则你连问题出在哪个环节都判断不出来。1.1 从按下电源键到登录提示符之间发生了什么以最常见的 x86_64 服务器为例一台 Linux 系统从开机到登录提示符大致要经历以下这几个阶段固件阶段BIOS 或 UEFI 完成自检根据启动顺序找到磁盘上的引导程序。你可以在固件设置里调整启动顺序比如让 U 盘优先、硬盘优先。引导加载器阶段这里是 GRUB2 的主战场。GRUB2 读取 /boot/grub2/grub.cfg 这个菜单配置文件把内核和 initramfs 镜像加载进内存然后把控制权交给内核。内核阶段内核开始初始化硬件、加载驱动然后解压 initramfs。initramfs 阶段initramfs初始内存文件系统的作用很关键它包含磁盘控制器、LVM、文件系统等必要模块负责把真正的根文件系统挂载起来。如果根文件系统在 LVM 逻辑卷或加密分区上这个阶段会完成卷组激活和解密。systemd 接管真正的根文件系统挂载成功后内核会把 PID 1 进程交给 systemdsystemd 按单元依赖关系启动各类服务最终到达 multi-user.target 或 graphical.target你就能看到登录提示符了。这五步里每一环都可能有自己的故障形态。简单说固件阶段出问题通常开机黑屏、无提示GRUB 出问题屏幕停在 grub 或报 no such partition内核或 initramfs 出问题可能出现 Kernel panic 或卡在内核早期日志根文件系统挂载失败会提示 UUID not found 或进入 emergency mode。1.2 每个环节最容易出事的点我自己的经验是真实生产故障里bootloader 和文件系统这两块出问题占比最高root 密码忘记则是所有软故障里最尴尬的。GRUB 配置损坏常见于 /boot 分区空间被写满、grub.cfg 生成失败、手工修改了 /etc/grub.d/ 下的脚本后又执行了错误的命令。内核和 initramfs 不匹配比如内存中加载的内核与 initramfs 版本不一致或者 initramfs 被误删。根文件系统 UUID 变了尤其是数据盘或系统盘被重新格式化、克隆迁移后磁盘分区的 UUID 变了但 /etc/fstab 还写着旧 UUID。文件系统元数据损坏突然断电、强制关机后ext4 或 XFS 出现不一致系统尝试自动检查失败后进入维护模式。root 密码忘记在 RHEL7/CentOS7 之后的版本里单用户模式不再默认免密所以远程操作更要谨慎。理解这些链路之后下面的排查方法才有意义。你会发现大多数修复工作其实可以归结为两件事一是绕过当前损坏的环节二是进入系统后用 chroot 修好出问题的那个环节。2. 故障分类与症状识别先判断到了哪一步再动手修复系统最忌讳的就是不做判断直接执行命令。同样是系统起不来grub 和 Kernel panic 的处理思路完全不同。我建议你先根据屏幕上的最后几行提示判断当前卡在哪一环。2.1 常见故障现象与根因对照表下面这张表是我在实际排障中总结的不是教科书里的理论每一行都对应过真实场景屏幕表现故障环节常见根因检查手段开机黑屏、无 BIOS 自检固件/硬件内存、电源、引导介质丢失看固件灯、进固件设置检查启动项停在 grub 提示符GRUBgrub.cfg 丢失/damaged、/boot 分区不可读手动执行 ls、cat 查看分区与文件error: no such partitionGRUB分区表变化、/boot 所在盘改变用 ls 查看可识别分区对比 UUIDKernel panic - not syncing内核内核文件损坏、驱动异常尝试旧内核启动卡在 Loading initramfsinitramfsinitramfs 损坏或缺失使用救援盘 chroot 重建 initramfs报 device UUID not found根文件系统/LVMfstab 的 UUID 过期、LVM 未激活用 blkid 查看当前 UUID停在 emergency modefstab / 服务某挂载点失败、服务超时按提示输密码进入维护 shell 检查日志一直循环重启固件/内核引导参数问题、内核 oops进入救援模式检查日志这张表不用背只要记住一句话屏幕上最后一行有意义的报错信息就是你排查的起点。2.2 用最快的方法判断卡在哪一环如果你没有屏幕只有远程控制台或者云平台上的 VNC/KVM 窗口也一样能判断。方法就是看最后出现的关键字如果出现 GRUB 菜单但选择后直接重新重启一般是内核加载失败或者引导参数问题。如果出现 Started Update UTMP about System Runlevel Changes 这类 systemd 日志停在某处通常是某个服务启动超时优先看 fstab 和网络配置。如果出现 Give root password for maintenance说明根文件系统已经挂载成功只是某个挂载点出错处理等级低很多只需修复 fstab 即可。实际操作中我一般先用排除法看看是不是硬件层如果不是再分辨是 bootloader 层还是内核层最后才考虑文件系统层。判断得越准确后面用的命令就越少系统恢复也越快。3. 绕过坏系统直接修救援环境与单用户模式的进入姿势系统进不去不代表这个系统就没救了。几乎所有的 Linux 发行版都提供了绕过当前系统直接操作文件系统的路径关键是你得知道每种路径适合什么场景。3.1 三种进入救援环境的路径及其适用场景第一种是用安装介质启动。不管你是 CentOS、Ubuntu 还是 Debian用官方 ISO 做的启动盘都可以进入 Rescue mode 或 Troubleshooting - Rescue a CentOS system 这类选项。它会尝试发现你硬盘上已安装的系统并提供选项让你 chroot 进去。这是最稳定、最通用的方式适合 GRUB 完全损坏、内核文件丢失这类引导链断裂的情况。第二种是从现有 GRUB 菜单直接进入单用户模式或救援目标rescue.target。这个方式的优点是不需要额外介质缺点是如果 GRUB 已经进不去这个方法当然也就用不了。第三种是硬件辅助方式比如虚拟化平台的快照、云主机的救援模式、LiveCD 引导。云厂商的控制台一般都有救援模式入口本质是给你一台临时 Linux把原来系统的系统盘挂载上去操作。这个方法我整理在下面的表格里方式需要的条件适用场景注意事项安装介质 Rescue一个 ISO/U盘GRUB坏、内核坏、文件系统问题需要光驱或U盘启动可能要改固件启动顺序GRUB单用户/rescueGRUB菜单可用root密码忘、fstab小问题RHEL7下如果root有密码要先过认证云平台救援模式控制台操作所有无法本地操作的环境本质是 LiveCD需要会看挂载路径3.2 单用户模式/rescue.target 的修改密码思路先解释一个容易混淆的点RHEL7/CentOS7 之后曾经的单用户模式变成了 rescue.target 和 emergency.target 两个单元。进入方式不再是在 GRUB 菜单里输入 single 或者 1 那么简单虽然系统仍然接受这些参数但如果你给 root 设置了密码单用户模式也会要求你输入 root 密码才能进入 shell。这就意味着对于忘记 root 密码这个场景单用户模式不一定能直接救你除非你确认 root 密码为空。在 GRUB 菜单界面选中你想启动的内核条目按 e 进入编辑模式。找到 linux16BIOS或 linuxefiUEFI开头的那一行在末尾追加 systemd.unitrescue.target然后按 Ctrlx 或 b 启动。如果是 Ubuntu更推荐在 GRUB 菜单Advanced options里选择带 recovery mode 的内核再选 root - Drop to root shell。因为 rescue.target 下根文件系统已经是可读写挂载在多数发行版中是这样所以直接执行 passwd root 修改密码即可。但如果你想用 emergency.targetemergency 模式下根是只读的修改前一定要先 mount -o remount,rw /。3.3 为什么 rd.break 是当前最稳的方案在忘记 root 密码且你还有 GRUB 菜单可用的情况下我强烈推荐 rd.break 这个参数而不是单用户模式。rd.break 的意思是让内核在 initramfs 阶段暂停进入一个临时的 shell 环境此时系统还没有要求任何密码认证因为你还没走到真正的用户认证阶段。具体操作还是先按 e 编辑 GRUB 菜单在 linux16 或 linuxefi 行末尾追加 rd.break然后启动。你会看到系统停在 switch_root:/# 这样的提示符。这时你真正要修改的根文件系统被挂在 /sysroot 目录下不过它是只读的。所以需要先重新挂载为可写再 chroot 进去修改密码。为什么说它比单用户模式稳因为它在系统尚未正式启动时就介入了绕过了需要密码的关口也不需要你在 rescue.target 里跟 pam 认证机制打交道。它是内核参数层面提供的调试入口所有 RHEL7 和 systemd 发行版都支持不掉链子。4. root 密码遗失修复实操三种方案的完整步骤与对比这一节是标题里点名的重点我把三种方案的操作步骤全部写出来并且给出对比和注意事项。三种方案都要求你能编辑 GRUB 菜单如果连 GRUB 菜单都进不去请参考下一节的 chroot 修复法。4.1 方案一编辑 GRUB 菜单追加 systemd.unitrescue.target 改密这个方案适合root 密码忘了但没有设置加密盘、不是 LVM 特殊配置的常规场景。操作步骤如下重启服务器在 GRUB 菜单出现后按下方向键选中默认内核条目按 e 进入编辑。找到 linux16 / vmlinuz-… 这一行把光标移到行尾加一个空格后输入 systemd.unitrescue.target。按 Ctrlx 或 b 启动系统会进入 rescue.target 并提示你按 Enter 进入维护模式。如果 root 密码为空或系统没有强制认证你会直接获得 shell否则会要求输入 root 密码那这个方法就不适用直接跳到方案二。在维护 shell 里执行 passwd root按提示输入两遍新密码。如果系统开了 SELinux执行 touch /.autorelabel让系统在下次正常启动时重新标记文件上下文。执行 reboot 正常重启。这个方案的优点是操作简单但缺点就是上面说的如果 root 有密码rescue.target 也会要求认证。在 CentOS 6 和更老的版本里单用户模式是不问密码的但老版本也有自己的一套玩法新系统不建议太依赖这个历史行为。4.2 方案二rd.break 改密与 SELinux 处理这是我最喜欢用的方案步骤也不复杂在 GRUB 编辑界面还是找到 linux16/linuxefi 行末尾追加 rd.break。启动后进入 switch_root:/# 提示符。此时根文件系统挂载在 /sysroot但只读。执行 mount -o remount,rw /sysroot。执行 chroot /sysroot此时你就进入了真实的系统环境。执行 passwd root输入新密码。如果启用了 SELinux执行 touch /.autorelabel 并退出 chrootexit再执行 exit 让系统继续启动。有一个细节要提醒在 chroot 环境里你看到的提示符可能和平时不太一样因为没有加载系统服务网络也没有配置。千万不要在这个时候启动什么服务你只需要改密码。关于 SELinux 的 autorelabel如果系统启用了 SELinux修改密码后在下次启动时重新标记文件上下文是比较稳妥的。缺点是大分区上 autorelabel 会耗时很长几次启动后才恢复正常。如果确认你的修改不涉及 SELinux 上下文变化比如只是 update 已有文件可以跳过但我个人习惯还是 touch 一下多等几分钟总比后面反复登录异常强。4.3 方案三init/bin/bash 改密的原理与局限第三种方案是在 GRUB 的 linux 行尾追加 init/bin/bash让内核跳过 systemd 直接启动 bash。这个方案原理上可以但有个硬伤根文件系统通常只会以只读方式挂载。所以你需要先执行 mount -o remount,rw /然后才能 passwd root。这个方案在 RHEL8/9 上也有效但我不太推荐作为首选原因是它跳过了太多系统初始化某些系统上有内核模块和文件系统驱动未加载的坑。比如根文件系统在 LVM 逻辑卷上时bash 启动时可能根本没激活卷组。相比之下rd.break 在 initramfs 阶段LVM/加密模块已经加载了介入点更靠前也更深层。4.4 改密之后必须做的事改完密码不代表马上可以交差。我每次都会做这几步reboot 重启前确认没有把 rd.break、systemd.unitrescue.target 这类临时启动参数留在内核命令行配置里否则每次重启都会进入维护模式。登录后执行 passwd -S root 查看密码策略状态顺便确认 root 的密码期限不是你之前误设的 expired。如果是生产环境立刻生成一个新的随机密码并妥善保存到密码管理工具里不要继续用1qaz2wsx这种自己都记不住的弱密码。检查 /var/log/secure 或 journalctl确认没有其他异常登录事件。改密码后出现一次正常登录即可。5. chroot 修复法系统修复的万能手术台如果说前面对付的是软件配置层面的故障那 chroot 修复法就是真正的手术台。无论 GRUB 坏了、内核丢了、还是文件系统检查失败只要你能启动到安装介质救援环境就能通过 chroot 进入受损系统进行修复。这一节讲清楚挂载顺序和三个高频场景。5.1 chroot 前要正确挂载哪些目录chroot 的原理是切换根目录让新环境中的 / 指向你的旧系统根分区。但仅仅挂载根分区远远不够因为新环境还需要访问内核设备节点、进程信息、虚拟文件系统否则很多命令会报错或直接失效。以下是典型的分区布局和挂载顺序# 先用 lsblk 确认设备和分区名称 lsblk # 假设根分区是 /dev/mapper/vg1-rootboot 是 /dev/sda1 mount /dev/mapper/vg1-root /mnt mount /dev/sda1 /mnt/boot # 绑定虚拟文件系统 mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev/pts /mnt/dev/pts # 如果是 UEFI 机器还要挂载 EFI 系统分区 mount /dev/sda2 /mnt/boot/efi # 最后进入 chroot chroot /mnt /bin/bash这套挂载顺序要记牢尤其是不要漏掉 /dev、/proc、/sys。漏掉之后进入 chroot 环境执行 grub2-install 时会提示找不到设备因为你没有把当前救援系统的设备节点带进去。5.2 场景A重建丢失的 GRUB我在实践中遇到最多的一种情况是系统盘分区表还在文件也都完好但 GRUB 的引导代码损坏或者 grub.cfg 被误删导致开机直接停在 grub。处理思路就是用 LiveCD 启动挂载根分区和 boot 分区chroot 进去然后重建引导。如果是传统 BIOS 启动执行grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg如果是 UEFI 启动则要grub-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idgrub grub2-mkconfig -o /boot/grub2/grub.cfg这里有一个关键点执行 grub2-install 的目标是整块磁盘比如 /dev/sda而不是分区/dev/sda1。因为引导代码是写在磁盘的主引导记录或 EFI 分区里的。很多新手都会写错成 grub2-install /dev/sda1然后来问我为什么没反应就是这个原因。5.3 场景B内核损坏与 initramfs 重建有时候 /boot/vmlinuz-xxx 这个文件被误删或者 initramfs 镜像损坏系统会报 Kernel panic。你可以在 chroot 环境中用发行版的包管理器重新安装内核或者手动重建 initramfs。RHEL/CentOS 系列# 查看当前安装的内核版本 rpm -qa | grep kernel # 如果有对应版本的内核包直接重装 yum reinstall kernel-$(uname -r) -y # 或者手动重建 initramfs dracut -f /boot/initramfs-$(uname -r).img $(uname -r)Ubuntu/Debian 系列apt install --reinstall linux-image-$(uname -r) update-initramfs -u update-grub这里要注意chroot 之后如果没有外网yum 或 apt 可能无法下载软件包。如果只是 initramfs 损坏但有内核文件在dracut 和 update-initramfs 这种本地重建命令是不需要网络下载的优先用它们。5.4 场景C修复写错的 /etc/fstab/fstab 写错是启动卡在 emergency mode 的元凶。修改方法说穿了很简单进入救援环境挂载根分区直接编辑 /etc/fstab把错误行注释掉或修正。但是要注意在 emergency mode 下你系统的根文件系统通常是只读的直接 vi 修改会失败。需要先执行mount -o remount,rw /然后再修改。修改完成后建议顺手执行 mount -a它会把 fstab 里所有条目按当前配置挂载一遍看有没有新的报错。如果能顺利执行完至少说明语法和路径没有大问题能减少一次重启失败的风险。6. 文件系统损坏导致无法启动的处理套路除了密码忘记和引导损坏另一类高频故障是文件系统本身的问题。最常见的触发原因是突然断电、强制重启、或者磁盘提前出现坏道。这类故障的修复规则跟前面不太一样因为错误的修复命令可能导致数据二次损坏。6.1 ext4 与 XFS 的修复工具差异千万不要用一个工具去修另一种文件系统。很多网上经验是把 fsck 当作万能命令其实 XFS 文件系统根本不使用 fsck 作为常规修复工具而是用 xfs_repair。ext4 系列的修复步骤一般是先确认分区处于未挂载状态然后执行 e2fsck -f /dev/sdX 或 fsck -y /dev/sdX。fsck 在有需修复项时会问你 yes/no生产环境中可以用 -y 参数自动接受修复但你要知道它可能会把一些损坏的孤儿文件放到 lostfound 目录而不是无中生有。XFS 系列的修复要格外小心# 卸载或确认未挂载后 xfs_repair /dev/sda1如果 XFS 日志损坏严重xfs_repair 会提示你使用 -L 参数清空日志。注意-L 这个选项会丢弃日志里的未提交操作相当于放弃最近一小段时间的数据。所以执行之前要确认这能接受尽量先做一次快照或完整备份。我在生产环境里用 xfs_repair -L 的场合都是已经确认分区数据不抢救不行了绝不轻易尝试。6.2 LVM 与加密分区在救援环境下的激活顺序如果你的根文件系统在 LVM 逻辑卷上很多发行版默认如此在救援环境里直接 lsblk 可能看不到逻辑卷设备因为卷组还没有被激活。此时需要手动执行pvscan vgscan lvchange -ay /dev/vg1/root # 或者激活所有卷组 vgchange -ay激活之后逻辑卷设备就会出现在 /dev/mapper/ 下再挂载即可。加密分区的处理顺序类似——你需要先把加密层打开cryptsetup luksOpen /dev/sda2 systemroot执行后要输入密码然后会在 /dev/mapper/systemroot 出现解密后的设备再对这个设备做 LVM 激活或直接挂载。这一块我的经验是先查看 /etc/fstab 和 /etc/lvm/backup 下的卷组备份文件确认逻辑卷名称。不要靠猜否则挂载到错误设备上会把数据搞得更乱。6.3 fstab 检查与 mount -a 的验证习惯所有和启动挂载相关的修复最后都绕不开 mount -a 的验证。它会把 /etc/fstab 中所有条目都尝试挂载一遍报错信息会直接告诉你哪一行、哪个设备出了问题。修复完成之后我一般还会做三件事用 blkid 对比分区当前 UUID 与 fstab 中的 UUID确认没有因为重新格式化导致的漂移。用 df -h 看挂载点是否确实生效尤其是 /boot 和根分区。记录修改时间改动 fstab 前先 cp /etc/fstab /etc/fstab.bak.$(date %F)这是成本最低的回滚保险。7. 一次完整的故障救援复盘从报错到恢复理论讲再多不如看一个真实场景的排障过程。这里我用一个自己印象比较深的案例来说明为方便叙述统称某服务器。7.1 故障现象与初步判断某台服务器某天在机房重启后一直无法进入系统。控制台截图显示屏幕停在 grub 提示符输入任何命令都没有菜单加载。从镜头上看这是典型的 GRUB 配置丢失或 /boot 引导信息损坏。我初步判断是引导阶段的问题根本不涉及内核和系统文件所以优先考虑重建 GRUB。7.2 排查链路与根因定位我带着系统安装盘前往机房从光驱启动选择 Rescue 模式。系统自动探测到旧系统并问要不要挂载我选择了 Continue 后进入 shell。首先用 lsblk 确认磁盘布局然后再用 blkid 比对分区 UUID。结果发现 /boot 分区居然写满了。进一步排查发现这台机器的 /boot 分区只有 200M而旧内核长久没有清理堆积了三四个内核版本每个内核加 initramfs 大约占 60 到 80M再加上 grub 相关文件空间彻底耗尽。之前的某次升级中grub2-mkconfig 生成菜单时因为磁盘空间不足写入了不完整的配置文件之后重启就再也进不去了。7.3 修复操作与验证过程在救援 shell 里我按顺序执行了以下操作# 挂载根分区到 /mnt mount /dev/mapper/centos-root /mnt mount /dev/sda1 /mnt/boot # 绑定虚拟文件系统 mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt /bin/bash # 查看已安装的内核 rpm -qa | grep kernel # 删除旧内核只保留当前正在使用的最新版本 yum remove kernel-3.10.0-327.el7.x86_64 ... # 确认 /boot 空间 df -h /boot # 重建 grub 配置 grub2-mkconfig -o /boot/grub2/grub.cfg # 写回主引导记录 grub2-install /dev/sda重启之后系统正常进入 GRUB 菜单成功启动。整个修复过程大概十分钟但排查根源花了更久——如果最开始没有发现 /boot 空间已满而是直接重建 grub.cfg重启后大概率还会再次失败。7.4 事后加固与经验总结这个案例给我留下的教训是/boot 分区不能给太小。现代内核和 initramfs 越来越大建议至少 1G 空间如果条件允许直接用独立分区并且监控使用率。其次是升级内核后要及时清理旧内核一般保留最近两个版本就够。最后修改任何引导相关内容之前先确认 /boot 剩余空间再执行 grub2-mkconfig避免再次生成失败。8. 运维日常里最容易翻车的操作清单系统修复这个事儿真正的功力往往体现在提前避免翻车上。我在最后整理一份踩过坑之后形成的操作清单每一条都有血泪在里面。改 /etc/fstab 前必须备份并执行 mount -a 验证。远程服务器修改 GRUB、内核相关文件时一定要先确认有带外管理或控制台通道。如果只剩 SSH 一条路尽量不要动态改引导配置否则重启时连不上就非常被动。不要随手 chmod 或 chown /boot 下的文件尤其是 grub.cfg权限和上下文错误都会导致引导异常。不要在没有确认磁盘盘符的情况下执行 dd、mkfs、grub-install。某些救援环境里盘符和你记忆中的不一样先看 lsblk再看 /dev/disk/by-id 里的符号链接。文件系统修复前先考虑快照或备份。云主机可以先做磁盘快照物理机有条件就做整盘镜像避免修复命令本身造成二次损失。定期记录系统根分区和 /boot 分区的 UUID、卷组名、逻辑卷名放到文档或者笔记里。故障时省下大量猜设备的时间。生产服务器设置 BIOS/固件密码后不要把密码遗失更不要在无记录的情况下随意修改启动顺序。我自己这几年处理系统引导故障最大的体会是操作命令不难难的是在时间压力和现场慌乱中仍然能按着链路一步步排查。这套排查思路不是一次两次就能形成的多模拟几次系统起不来的场景你也会慢慢有手感。下次再遇到类似情况先不要急着重装想想引导链路里的每一步大概率能救回来。
