半夜被叫起来处理服务器起不来的情况，大概是每个做运维或者自己搭服务器的人都躲不掉的。我遇到过不少次：明明昨天还好好的，一次重启之后就卡在黑屏、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 进程交给 systemd，systemd 按单元依赖关系启动各类服务，最终到达 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> 提示符 | GRUB | grub.cfg 丢失/damaged、/boot 分区不可读 | 手动执行 ls、cat 查看分区与文件 |
| error: no such partition | GRUB | 分区表变化、/boot 所在盘改变 | 用 ls 查看可识别分区，对比 UUID |
| Kernel panic - not syncing | 内核 | 内核文件损坏、驱动异常 | 尝试旧内核启动 |
| 卡在 Loading initramfs | initramfs | initramfs 损坏或缺失 | 使用救援盘 chroot 重建 initramfs |
| 报 device UUID not found | 根文件系统/LVM | fstab 的 UUID 过期、LVM 未激活 | 用 blkid 查看当前 UUID |
| 停在 emergency mode | fstab / 服务 | 某挂载点失败、服务超时 | 按提示输密码进入维护 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单用户/rescue | GRUB菜单可用 | 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 进入编辑模式。找到 linux16（BIOS）或 linuxefi（UEFI）开头的那一行，在末尾追加 systemd.unit=rescue.target，然后按 Ctrl+x 或 b 启动。如果是 Ubuntu，更推荐在 GRUB 菜单"Advanced options"里选择带 recovery mode 的内核，再选 "root - Drop to root shell"。
因为 rescue.target 下根文件系统已经是可读写挂载（在多数发行版中是这样），所以直接执行 passwd root 修改密码即可。但如果你想用 emergency.target（emergency 模式下根是只读的），修改前一定要先 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.unit=rescue.target 改密
这个方案适合"root 密码忘了但没有设置加密盘、不是 LVM 特殊配置"的常规场景。操作步骤如下：
- 重启服务器，在 GRUB 菜单出现后按下方向键选中默认内核条目，按 e 进入编辑。
- 找到 linux16 / vmlinuz-… 这一行，把光标移到行尾，加一个空格后输入 systemd.unit=rescue.target。
- 按 Ctrl+x 或 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 并退出 chroot（exit），再执行 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.unit=rescue.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-root，boot 是 /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 --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub 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 参数自动接受修复，但你要知道它可能会把一些损坏的孤儿文件放到 lost+found 目录，而不是无中生有。
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/固件密码后，不要把密码遗失，更不要在无记录的情况下随意修改启动顺序。
我自己这几年处理系统引导故障，最大的体会是：操作命令不难，难的是在时间压力和现场慌乱中，仍然能按着链路一步步排查。这套排查思路不是一次两次就能形成的，多模拟几次"系统起不来"的场景，你也会慢慢有手感。下次再遇到类似情况，先不要急着重装，想想引导链路里的每一步，大概率能救回来。
