Linux 系统急救：rescue mode、GRUB 修复、fsck 完整操作手册

每个运维工程师都会遇到“系统无法启动”的噩梦：GRUB 报错、内核 panic、文件系统损坏、误删 /etc/fstab……本文是一份完整的 Linux 系统急救手册，按故障类型分类，每种场景给出可操作的恢复步骤。

故障快速定位

系统不能正常启动时，先判断卡在哪个阶段：

启动流程：
BIOS/UEFI → GRUB → 内核加载 → initramfs → /sbin/init → systemd → 服务启动 → 登录

卡在 GRUB         → GRUB 配置/MBR/GPT 问题
内核 panic        → 内核模块/驱动问题、根文件系统损坏
"Failed to mount" → /etc/fstab 配置错误或磁盘故障
systemd 服务失败  → 进入 emergency mode，看 journalctl
登录循环          → PAM/SELinux/图形驱动问题

一、进入 rescue/emergency 模式

Ubuntu/Debian

# 方法1：开机时在 GRUB 界面按 e 编辑启动参数
# 找到 "linux" 行，末尾加：
systemd.unit=rescue.target
# 或更底层的：
systemd.unit=emergency.target

# 按 Ctrl+X 或 F10 启动

# 方法2：直接在 GRUB 选项中选择 Recovery Mode
# 高级选项 → Ubuntu 的 Recovery mode → Drop to root shell

CentOS/RHEL

# GRUB 界面按 e 进入编辑
# 找到 "linux" 或 "linuxefi" 行
# 删除 rhgb quiet，末尾加：
rd.break

# 这会进入 initramfs 的 switch_root 前断点
# 根文件系统挂载在 /sysroot（只读）

# 重新以读写模式挂载根文件系统
mount -o remount,rw /sysroot

# chroot 进入真实系统
chroot /sysroot

# 完成修复后
exit
exit  # 退出 chroot，系统继续启动

通用：单用户模式（init 1）

# GRUB 编辑：linux 行末尾加 init=/bin/bash
# 或加 single 或 1

# 进入后以 root 权限操作，但文件系统可能是只读
mount -o remount,rw /

二、重置 root 密码

# 进入 emergency/rescue 模式后

# Ubuntu 22.04
# GRUB → 编辑 → linux 行末尾加 init=/bin/bash
mount -o remount,rw /
passwd root
# 输入新密码

# 如果启用了 SELinux（RHEL/CentOS）
touch /.autorelabel   # 标记文件系统需要重新打标签（重启后自动处理）

sync && reboot -f

# CentOS/RHEL 7+（使用 rd.break 方式）
mount -o remount,rw /sysroot
chroot /sysroot
passwd root
touch /.autorelabel
exit && exit

三、GRUB 修复

GRUB 引导丢失（常见于 MBR 被覆盖后）

# 场景：安装 Windows 后 GRUB 被 Windows 引导程序覆盖
# 解决：用 Linux Live ISO 启动，重装 GRUB

# 1. 用 Live ISO 启动系统

# 2. 找到根分区
lsblk
fdisk -l
# 假设根分区是 /dev/sda2

# 3. 挂载根分区
mount /dev/sda2 /mnt

# 如果是分离的 /boot 分区
mount /dev/sda1 /mnt/boot   # /boot 分区

# 挂载必要的虚拟文件系统
mount --bind /dev  /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys  /mnt/sys
mount --bind /run  /mnt/run

# 4. chroot 进入系统
chroot /mnt

# 5. 重装 GRUB
# MBR 方式（旧系统）
grub-install /dev/sda   # 注意是磁盘不是分区

# UEFI 方式（现代系统）
# 先挂载 EFI 分区
mount /dev/sda1 /boot/efi   # EFI 分区通常是 FAT32
grub-install --target=x86_64-efi --efi-directory=/boot/efi

# 6. 更新 GRUB 配置
update-grub       # Ubuntu/Debian
grub2-mkconfig -o /boot/grub2/grub.cfg   # CentOS/RHEL

# 7. 退出并重启
exit
umount -R /mnt
reboot

GRUB 配置文件损坏

# 进入 GRUB 命令行界面（启动时按 c）

# 手动指定内核引导（救急方式）
grub> ls                          # 列出分区
grub> ls (hd0,gpt2)/             # 查看分区内容
grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-6.5.0-generic root=/dev/sda2
grub> initrd /boot/initrd.img-6.5.0-generic
grub> boot                        # 启动

# 进入系统后重新生成 GRUB 配置
update-grub

GRUB 找不到配置文件（grub rescue）

# grub rescue> 提示符，说明 grub 模块都找不到

# 先找到 boot 分区
grub rescue> ls
# (hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)

grub rescue> ls (hd0,gpt2)/boot/grub/
# 如果有文件，说明找到了

grub rescue> set prefix=(hd0,gpt2)/boot/grub
grub rescue> set root=(hd0,gpt2)
grub rescue> insmod normal
grub rescue> normal
# 进入正常 GRUB 菜单

四、文件系统修复（fsck）

何时用 fsck

不能在已挂载的文件系统上运行 fsck！
需要先 umount，或在系统未启动时操作。

自动触发场景：
- 文件系统标记为 dirty（非正常关机）
- 挂载次数超过 max-mount-count
- 启动时出现 "Checking file system..." 就是在自动 fsck

ext4 文件系统修复

# 检查文件系统（只检查不修复）
fsck.ext4 -n /dev/sda2

# 自动修复（-y 自动回答 yes）
fsck.ext4 -y /dev/sda2

# 强制检查（即使标记为 clean）
fsck.ext4 -f /dev/sda2

# 详细输出
fsck.ext4 -v /dev/sda2

# 典型输出：
# /dev/sda2: Inode 12345 has invalid mode.
# Fix? yes
# /dev/sda2: Inode 12345: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
#
# /dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
# /dev/sda2: 125432/3276800 files (0.2% non-contiguous), 4523456/13107200 blocks

XFS 文件系统修复

# XFS 修复工具是 xfs_repair（不是 fsck）
# 必须先 umount

umount /dev/sda3

# 检查（不修复）
xfs_repair -n /dev/sda3

# 修复
xfs_repair /dev/sda3

# 如果 journal 损坏（常见于突然断电）
xfs_repair -L /dev/sda3   # -L 清除 journal（最后手段，可能丢少量数据）

# 如果设备 busy
# 先找谁在用
fuser -mv /mount/point
lsof /mount/point
# 杀掉进程后再 umount

启动时文件系统 fsck 失败进入 emergency mode

# 现象：启动时停在 "Press Enter for maintenance (or press Control-D to continue)"

# 输入 root 密码进入 maintenance shell

# 查看 journald 日志（看哪个分区 fsck 失败）
journalctl -b -p err
# 或
dmesg | grep -i "error\|fail\|fsck"

# 找到问题分区，手动 fsck
fsck.ext4 -y /dev/sdb1

# 如果问题是 /etc/fstab 配置错误
# 以只读方式挂载根分区然后修复
mount -o remount,rw /
vi /etc/fstab   # 注释掉有问题的行

# 正常重启
reboot

五、关键文件恢复

/etc/fstab 损坏或误删

# 进入 rescue mode 或 Live ISO

# 如果根分区能挂载，先把 fstab 恢复
mount -o remount,rw /

# 最简 fstab（先让系统能启动）
cat > /etc/fstab << 'EOF'
# <device>         <mountpoint>  <type>  <options>         <dump> <pass>
UUID=xxx-xxx       /             ext4    defaults,errors=remount-ro  0 1
UUID=yyy-yyy       /boot/efi     vfat    umask=0077       0 1
EOF

# 查找正确的 UUID
blkid
# /dev/sda2: UUID="abc-123-def" TYPE="ext4"

# 临时挂载验证
mount -a   # 挂载 fstab 中所有条目
# 无报错说明 fstab 正确

/etc/passwd、/etc/shadow 损坏

# 进入 rescue mode

# 查看 /etc/passwd 是否可读
cat /etc/passwd | head

# 如果文件损坏，从备份恢复
ls /etc/passwd- /etc/shadow-   # Linux 自动保留上一版本

# 恢复
cp /etc/passwd- /etc/passwd
cp /etc/shadow- /etc/shadow

# 如果连备份都没有，只能从相同版本的 ISO 或其他同版本服务器复制基础账户
# 复制后 root 的密码需要重置

grub.cfg 或内核文件丢失

# 进入 Live ISO

# 挂载根分区
mount /dev/sda2 /mnt
# 挂载虚拟文件系统（同前面）

# chroot 重新安装内核
chroot /mnt
apt-get install --reinstall linux-image-$(uname -r)
# 或安装最新内核
apt-get install linux-image-generic

update-grub

六、常用急救命令速查

# 查看哪个服务导致 emergency mode
systemctl --failed
journalctl -xb -p err

# 强制跳过某个失败的 mount（临时）
systemctl mask dev-sdb1.mount   # 禁用该 mount unit

# 清理 systemd 状态（某些僵尸服务）
systemctl reset-failed

# 文件系统标记为 clean（绕过 fsck，不推荐）
tune2fs -C 0 /dev/sda2   # 重置挂载计数

# 查看磁盘健康
smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable"

# 查看内核 panic 原因（需要 kdump 配置）
ls /var/crash/
ls /var/crash/*/vmcore

# 救援模式下查看 systemd 日志（即使没有完整系统）
journalctl --file=/run/log/journal/*/*.journal

小结

Linux 系统急救的思维框架：先判断卡在启动的哪个阶段 → 对应找入口（GRUB 命令行/rescue mode/Live ISO）→ 修复最小问题让系统能启动 → 进系统后再深入排查。最常见的三类问题：GRUB 引导丢失（重装 GRUB）、fstab 写错（rescue mode 编辑）、文件系统损坏（fsck/xfs_repair）。每次维护前务必做快照或备份——GRUB 操作失误很容易让系统完全不可启动，而有备份时恢复只需 5 分钟。