Ubuntu 文件系统修复指南

报错

复制代码

/dev/sda1: recovering journal
/dev/sda1 contains a file system with errors, check forced
/dev/sda1: Deleted inode 131220 has zero dtime. FIXED
/dev/sda1: Inodes that were part of a corrupted linked list found ...

recovering journal: 这是在尝试恢复文件系统的"日志（Journal）"。Ext3/4文件系统有个叫"日志"的功能，像是一个临时记事本，先把要做的修改记下来，然后再真正去改账本和书架。即使中途断电，系统也能根据这个"记事本"知道哪些操作完成了，哪些没完成，能大大加快修复速度并减少数据损坏范围。恢复日志是修复的第一步。
Deleted inode ... has zero dtime. FIXED: Inode是文件系统里用来描述一个文件（大小、权限、数据块位置等）的数据结构。dtime 是删除时间。这条信息是说，一个本该被标记为删除的inode，其删除时间记录为零（异常）。fsck发现后自动将其修复（FIXED）。这是一个比较轻微且常见的错误。
Inodes that were part of a corrupted linked list found: 这就是前面说的"损坏的链表"。目录结构、文件扩展块等，在文件系统里都是用链表形式组织的。这条信息说明链表指针出错了，需要fsck去重新梳理和重建这些链接关系。

一步步实操：从错误黑屏到正常登录

好，我们现在回到那个令人紧张的黑屏错误界面。通常，系统会停在一个提示符，或者显示一个菜单让你选择进入"恢复模式"。如果它直接停住了，闪烁的光标在等待输入，那么我们已经处于一个可以执行命令的根文件系统修复环境了。这个环境很可能是一个临时的根文件系统（比如initramfs），而你的实际硬盘分区（/dev/sda1）还没有被挂载为可读写的 /，这正是运行fsck的最佳时机。

1：运行文件系统检查（只读模式）

在直接修复前，我习惯先做一个"只读检查"，看看问题有多严重。输入：

c 复制代码

fsck -n /dev/sda1

2：执行实际修复操作

根据我遇到的情况和原始文章的提示，系统可能已经自动运行了fsck并给出了更具体的指令。有时它会建议你使用特定于文件系统类型的fsck版本。对于Ext4文件系统，就是 fsck.ext4。

1 首先尝试通用命令（这也是原始文章里的第一步）：

c 复制代码

fsck -C0 -N /dev/sda1

这里解释一下参数：

-C0: 这个 -C 后面跟的是数字0，不是字母O。它用于显示进度条。-C0 表示使用进度条样式0（通常是一个简单的旋转光标或进度提示），让你知道检查在继续，没卡死。

-N: "只显示将要做什么，但不实际执行"。这其实是一个"演习"模式。它会把fsck计划要做的所有检查修复操作打印出来，但一动不动。这个命令本身不进行修复，它只是告诉你如果真运行了，会干哪些事。

2 执行真正的修复命令：更常见的情况是，或者在上一步之后，系统/你需要直接运行修复命令。对于Ext4分区，命令是：

c 复制代码

fsck.ext4 -p /dev/sda1
或者，采用更自动化的方式（对所有问题回答yes）：
fsck.ext4 -y /dev/sda1

-p 是"自动修复"（automatic repair）模式，它会安全地修复所有预见到的问题，遇到无法自动处理的才会暂停。-y 则更"暴力"一点，对所有问题一律回答"是"。在大多数因强制关机导致的文件系统错误中，使用 -p 或 -y 都能成功修复。

如果系统明确提示你使用 fsck.ext4 -C0 /dev/sda1（如原始文章所示），那就按照提示来。这里的 -C0 同样是为了显示进度。所以完整的修复命令就是：

c 复制代码

fsck.ext4 -C0 /dev/sda1

执行这个命令后，fsck就开始干活了。屏幕上会滚动大量的检测信息，比如"Pass 1: Checking inodes, blocks, and sizes"、"Pass 2: Checking directory structure"等等。它会遍历文件系统的各个部分，核对并修复元数据。

3：交互式确认（如果需要）

如果你没有使用 -y 或 -p 参数，fsck会在遇到一些它不确定如何处理的错误时停下来，询问你。问题通常像这样：

c 复制代码

/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Free inodes count wrong for group #0 (X, counted=Y).
Fix?

我的建议是：如果你不确定，并且这个虚拟机里没有极其重要且唯一的数据，那么一律输入 y 同意修复。 fsck提出的修复方案在绝大多数情况下是安全且正确的，目的是恢复文件系统的一致性。拒绝修复反而可能导致系统无法启动。

4：修复完成与重启

当fsck完成所有工作后，它会输出一个总结，类似：

c 复制代码

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 1234/655360 files (0.1% non-contiguous), 56789/2621440 blocks

看到"FILE SYSTEM WAS MODIFIED"说明修复操作已经执行。现在，可以重启系统了。输入：

c 复制代码

reboot

或者

shutdown -r now

虚拟机将会重新启动。这次启动，你应该会看到熟悉的Ubuntu启动画面（或滚动日志），然后顺利进入登录界面。有时候，重启后系统可能还会进行一次快速的、不干预的fsck检查，这是正常的。

. 高级排查与预防：让虚拟机更"健壮"

成功修复启动后，别急着庆祝。我们得想想怎么避免下次再掉进同一个坑里，以及如果上述"标准流程"行不通，还有什么后招。

4.1 如果fsck修复后依然无法启动

这种情况虽然不多，但有可能发生。比如文件系统关键区域损坏太严重，或者修复过程中出现了意外。别灰心，我们还有办法：

从Live CD/USB启动：这是最强大的修复方式。你需要一个Ubuntu的安装ISO镜像。在虚拟机设置里，把光驱指向这个ISO文件，并设置从光盘启动。进入Live桌面后，打开终端。
挂载问题分区：在Live环境中，你的虚拟机硬盘不会被系统自动挂载为根目录。你需要手动挂载它。首先用 sudo fdisk -l 或 lsblk 找到你的根分区，假设还是 /dev/sda1。然后创建一个挂载点并挂载：

c 复制代码

sudo mkdir /mnt/repair
sudo mount /dev/sda1 /mnt/repair

在挂载状态下进行更深入的检查？不！记住之前的原则，不能在已挂载的分区上运行fsck。但Live环境给了我们一个机会：我们可以检查挂载后是否能访问数据。如果 ls /mnt/repair 能看到你的家目录等文件，说明数据很可能还在。此时，首要任务应该是备份！把重要数据拷贝到宿主机的共享文件夹，或者另一个虚拟磁盘里。
卸载并执行fsck：备份完成后，卸载分区，然后再对其运行fsck：

c 复制代码

sudo umount /mnt/repair
sudo fsck.ext4 -y /dev/sda1

Live环境下的fsck通常限制更少，可能能处理更棘手的问题。

尝试修复引导：如果文件系统修复好了但还是无法启动，可能是引导程序（GRUB）出了问题。在Live环境中，可以尝试使用 chroot 切换到损坏的系统环境，然后重新安装GRUB。这步操作稍复杂，建议搜索"Ubuntu chroot repair grub"参照详细教程。