2026 年 01 月 30 日 22 时至 24 时#

本人对系统进行了更新, 运行了如下命令

1
sudo pacman -Syu --noconfirm

由于 2026-01-30 (UTC), linux 以及 linux-zen 发布了 6.18.8 稳定版本, 导致了该系统更新更新了 kernel (内核)

但是, 在初次更新内核时, 出现了 DKMS (内核模块) 安装失败的问题, 我尝试了

1
sudo pacman -S linux-zen

成功后便认为更新成功, 随即关闭了计算机

2026 年 01 月 31 日 16 时至 17 时#

本人如往常般打开计算机, 但发现 Grub 引导美化主题背景图丢失, 以为可能是更新导致 Grub 配置失效, 重新安装主题即可, 便忽略了该问题随机进入系统引导

后, 发现系统启动失败, 在系统启动失败的 fallback 的 Shell 中, 发现任何命令无法运行, 根目录无法挂载

本人联想到先前 Btrfs 出现物理可用区域满 (数据在物理磁盘的末尾导致没有空余), 可能是该原因导致类似问题, 便想着进入 ISO 镜像环境使用 btrfs balance 或许可以恢复

后进入 ISO 安装镜像, 开始修复系统

2026 年 01 月 31 日 17 时及后#

本人尝试修复 Btrfs 文件系统, 通过查阅 Archwiki, 进行状态检查后, 发现 super chunk (超级块) 的地址指向了 800+ GiB 的位置, 包括用于备份的另一个 super chunk, 远超分区实际大小的地址上限, 无论是 btrfs check 还是 btrfs rescue 均报错

挂载报错

1
[xxx] BTRFS error (device nvme1n1p4): failed to read chunk tree: -5
2
[xxx] BTRFS error (device nvme1n1p4): open_ctree failed

²

上图是进入 ISO 镜像环境的 Archlinux 进行挂载的画面

btrfs check 报错, 显示存在 checksum failed 的块

1
Opening filesystem to check...
2
checksum verify failed on xxx wanted 0xxxx found 0xxxx
3
...

其中, 这几个报错的地址都是 800+ GiB 的不存在地址, 必定会导致 checksum failed

通过和 Archlinux-CN Telegram 群的群友们交流, 得知由于两个 super chunk 均已损坏, 无法修复文件系统, 群友说似乎 super chunk 的内容已经不在硬盘上存在了

2026 年 02 月 01 日#

我怀揣着不甘, 在 Gemini 的帮助下, 尝试通过全盘扫描 _BTRFS_M 魔法头, 找到 chunk tree 实际位置

通过 smartctl 和 nvme 工具的信息, 硬盘健康度貌似没有问题. 有群友认为, 可能是早期 致态 固件存在问题, 导致部分写入会存在 bug, 从而丢失数据

不过经历无数次的尝试, 最终还是未能恢复数据

扫描到的魔法头地址, 但是没一个可以用的