从Grub到fsck：Ubuntu紧急救援模式实战排错指南

1. 当Ubuntu无法启动时，你该怎么做？

遇到Ubuntu系统无法正常启动的情况，很多新手会感到手足无措。其实大多数启动问题都可以通过紧急救援模式来解决。我遇到过无数次类似情况，从个人笔记本到服务器集群，掌握这套排查方法真的能救命。

最常见的症状是：系统启动时卡住，或者直接进入一个黑屏界面，显示"emergency mode"字样。这种情况八成是文件系统出了问题。别慌，这时候Grub就是我们的救命稻草。Grub全称是GRand Unified Bootloader，它是Linux系统的守门人，负责在开机时加载操作系统内核。

提示：在开始操作前，建议先准备好一个Ubuntu安装U盘。万一救援模式也失效，还能用Live CD模式抢救数据。

2. 进入Grub救援模式的正确姿势

2.1 唤醒Grub菜单

大多数Ubuntu系统默认隐藏Grub菜单，需要手动唤醒。这里有个小技巧：在开机BIOS画面结束后立即长按Shift键（传统BIOS）或反复按Esc键（UEFI）。我实测过不下20台设备，这个方法在90%的情况下都有效。

如果没反应也别急，可能是按键时机不对。多试几次，在主板LOGO消失的瞬间按键最稳妥。成功的话你会看到一个蓝底白字的菜单，这就是Grub的庐山真面目了。

2.2 认识Grub选项

Grub菜单通常包含这几个关键选项：

• Ubuntu：正常启动
• Advanced options for Ubuntu：高级选项
• Memory test：内存测试（与我们无关）

我们要选的是"Advanced options"。这里有个坑：不同Ubuntu版本菜单略有差异。在18.04上这个选项可能在第二页，需要按方向键往下翻。我曾在凌晨三点因为这个细节折腾了半小时，希望大家引以为戒。

3. 深入救援模式核心操作

3.1 选择正确的内核版本

进入Advanced options后，你会看到多个内核版本，每个都对应一个普通版和一个恢复版(recovery mode)。这里有个重要原则：选最新版本对应的恢复模式。比如列表中最上面的是"Ubuntu, with Linux 5.15.0-76-generic (recovery mode)"，就选它。

为什么强调最新版本？因为旧内核可能缺少对新硬件的支持。上周我就遇到个案例：用户选了旧版内核，结果因为不识别NVMe SSD导致修复失败，白白浪费两小时。

3.2 救援模式菜单详解

成功进入恢复模式后，会出现一个包含多个选项的菜单：

• fsck：文件系统检查与修复（重点）
• clean：尝试清理磁盘空间
• dpkg：修复损坏的软件包
• grub：更新Grub引导加载程序
• network：启用网络连接
• root：进入root shell

我们最关心的是fsck，但别急着选它。建议先选"root"进入命令行，执行以下命令确保文件系统可写：

mount -o remount,rw /

这个命令我称之为"救援模式万能钥匙"，它能解除只读挂载，让后续操作顺利进行。记得有一次我跳过这步直接fsck，结果所有修复都无法保存，不得不从头再来。

4. 使用fsck修复文件系统

4.1 确认问题分区

执行df -h查看已挂载分区，但更关键的是lsblk -f，它能显示所有磁盘分区的文件系统类型。常见问题分区是根目录(/)和/boot，在输出中通常对应/dev/sda1、/dev/sda2等。

这里有个血泪教训：一定要确认分区号！有次我把sda1和sdb1搞混，结果修复了错误磁盘，差点酿成数据灾难。稳妥的做法是先用blkid核对分区UUID是否匹配/etc/fstab中的记录。

4.2 fsck命令实战

最安全的修复命令是：

fsck -y /dev/sda1

这个-y参数表示自动回答"yes"到所有问题，避免修复过程中卡住。但如果你不确定问题严重程度，可以先不加-y，手动确认每个修复项：

fsck /dev/sda1

我曾遇到过fsck运行时间超过3小时的情况，别担心，耐心等待。期间它会输出大量信息，重点关注这几类：

• "Inode X has imagic flag set"：索引节点异常
• "Unexpected inconsistency"：严重结构错误
• "Free blocks count wrong"：空间计数错误

4.3 高级修复技巧

如果标准fsck无效，可能需要使用备用超级块。先用mkfs.ext4 -n /dev/sda1查看备用超级块位置，然后：

fsck -b 32768 /dev/sda1

这个32768就是查到的备用超级块位置。去年我处理过一块频繁掉电损坏的硬盘，原始超级块完全损坏，靠这个方法才救回数据。

修复完成后，务必执行sync确保所有写入落地，然后reboot重启。如果问题依旧，可能需要考虑更复杂的方案，比如从Live CD运行fsck，或者检查硬盘SMART状态。

5. 常见问题与避坑指南

5.1 修复后无法进入图形界面

这种情况我遇到过不下十次，多半是因为显卡驱动或显示管理器损坏。可以先在Grub菜单的Linux启动行末尾添加"nomodeset"参数临时进入系统，然后重装显卡驱动：

ubuntu-drivers autoinstall

5.2 密码错误无法进入救援模式

如果提示root密码错误但你又没设置过，试试直接回车。Ubuntu默认不设root密码，用sudo权限即可。实在不行可以在Grub启动参数中添加"init=/bin/bash"进入单用户模式。

5.3 文件系统只读无法修改

除了前面提到的remount命令，有时还需要检查磁盘错误计数：

tune2fs -l /dev/sda1 | grep -i count

如果错误计数过高，系统会强制只读。可以用tune2fs -c 0 -i 0 /dev/sda1重置计数器。

6. 预防胜于治疗：日常维护建议

与其等系统崩溃再抢救，不如平时做好预防。我给自己管理的每台服务器都设置了定期fsck检查：

tune2fs -c 100 /dev/sda1

这个命令表示每100次挂载后自动检查。对于关键服务器，我还会每月手动执行一次：

fsck -nf /dev/sda1

-n参数表示只检查不修复，相当于给文件系统做"体检"。

另外，养成定期备份的好习惯。我习惯用rsync做增量备份，命令很简单：

rsync -avz --delete /重要数据 /备份目录/

这个习惯曾多次救我于水火，特别是遇到物理磁盘损坏时，数据恢复的成本和成功率远不如备份来得可靠。