求助！我这种情况，怎么恢复hermes skill

Wang Wei

我的 WSL2 Ubuntu-24.04 突然无法启动，主要目标不是恢复整个 Linux，而是尽可能恢复其中 Hermes Agent 的自定义 skills。

原 WSL VHDX：

E:\WSL\Ubuntu-24.04\ext4.vhdx

Windows 报错：

无法启动分发，因为其虚拟磁盘已损坏。
Wsl/Service/CreateInstance/WSL_E_DISK_CORRUPTED

这个 VHDX 是动态磁盘，Windows 文件大小约 44 GB，但虚拟容量是 1 TB。

后来检查宿主 E 盘，发现 E 盘本身是 exFAT（据说这种格式很不适合），并且：

chkdsk E: /scan

报告：

Windows 在磁盘上发现错误
检查卷位图时发现损坏
文件存在交叉链接
坏扇区 0 KB

所以目前怀疑是宿主 exFAT 文件系统损坏，进而破坏了 WSL 的 ext4.vhdx。

我另外安装了 Debian WSL 作为救援系统，并以 bare 方式挂载旧 VHDX：

wsl --mount "E:\WSL\Ubuntu-24.04\ext4.vhdx" --vhd --bare

旧盘在 Debian 中对应：

/dev/sdd

新的 Debian 是另一块设备，未对其操作。

最初：

e2fsck -fn /dev/sdd

显示：

Bad magic number in super-block
Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode

这里我犯了一个比较严重的错误（这是GPT搞出来的，我对技术是完全不懂，他妈的）：之后执行过一次：

e2fsck -f -y /dev/sdd

它出现过：

Root inode is not a directory. Clear? yes
Root inode not allocated. Allocate? yes
/lost+found not found. Create? yes
Recreate journal? yes

所以 ext4 元数据显然已经进一步被修改。之后 debugfs 看到根目录基本只剩：

/
└── lost+found

而 lost+found 为空。

从那以后，我已经停止一切对旧 /dev/sdd 的写操作，当前只做只读恢复。

现在正在使用 PhotoRec 对整个 /dev/sdd 做 raw carving：

Disk /dev/sdd - 1099 GB / 1024 GiB (RO)

恢复结果写到健康的 D 盘：

D:\HermesRecovery.1
D:\HermesRecovery.2
...

PhotoRec 会不断生成新的 HermesRecovery.N 目录。

目前已经恢复出 6 万多个文件，包括大量：

.txt
.py
.gz
.sqlite
.java
...

我的真正目标是恢复原来的：

~/.hermes/skills/

尤其是我自己通过 Hermes /learn 或自动学习生成的 custom skills。

问题是 PhotoRec 不保留原始文件名和目录结构，因此原本类似：

~/.hermes/skills/my-skill/
├── SKILL.md
├── scripts/xxx.py
└── references/xxx.txt

现在可能变成：

f123456.txt
f123789.py
f124000.txt

目前我已经从恢复文件中识别出约 214 个真正符合 Hermes SKILL.md 格式的文件，其典型格式为：

name: xxx
description: xxx

但是这些 214 个里大量是 Hermes 官方/公共 skill，例如：

llama-cpp
tensorrt-llm
stable-diffusion
github
pdf
xlsx
powerpoint
playwright-cli
browser-use
...

因此目前还没有确认找到我自己的 custom skill。

我还尝试寻找 Hermes 的一些辅助数据：

~/.hermes/skills/.usage.json
~/.hermes/skills/.bundled_manifest
~/.hermes/skills/.hub/lock.json
~/.hermes/skills/.curator_ledger.jsonl
~/.hermes/state.db
~/.hermes/skills/.curator_backups/.../skills.tar.gz

目前结果如下：

真正 .usage.json：未找到
真正 Hermes state.db：未找到
curator ledger：未确认找到
custom skill：未确认找到
真正 SKILL.md 内容：已找到约 214 个，但看起来主要是官方/公共 skills

找到了 7 个 SQLite 文件，但检查 schema 后都不像 Hermes state.db：

SQLite 候选: 7
Hermes-like DB: 0
skill_manage / /learn 命中: 0

还找到过一个包含 SKILL.md 的 .gz：

package/lib/tools/skills/playwright-cli/SKILL.md
package/lib/tools/skills/playwright-component-testing/SKILL.md
package/lib/tools/skills/playwright-trace/SKILL.md

但这个明显是某个软件包 archive，不是 ~/.hermes/skills 的备份。

现在主要想请教以下问题：

在 ext4 元数据已经严重损坏、而且 root inode 曾被错误的 e2fsck -y 重建过的情况下，除了 PhotoRec/file carving，还有没有更适合恢复原目录结构、inode 或文件名的方法？
有没有办法从 ext4 的残余 inode、directory entry、journal、backup metadata 中，针对性恢复原来的：
/home/<user>/.hermes/skills/

而不是全盘 raw carving？

PhotoRec 已经恢复出大量 SKILL.md 内容，但没有目录结构。有没有比较可靠的方法判断哪些是：
Hermes bundled skill
Hub 安装的 skill
用户 /learn 创建的 custom skill
agent 自动生成的 skill
如果 .usage.json、state.db、.curator_ledger.jsonl 都没恢复出来，还有没有 Hermes 自己留下的其他 provenance/index/cache 能帮助确定 custom skill 名称？
PhotoRec 当前扫描的是 1 TB 逻辑 VHDX，但实际动态 VHDX 文件只有约 44 GB。有没有更高效的方法只扫描实际已分配的 VHDX blocks，而不是把整个 1 TB 虚拟地址空间扫完？
如果有人熟悉 ext4, WSL2 ext4.vhdx, PhotoRec/TestDisk, debugfs, extundelete, ext4magic 或 Hermes Agent，非常希望能给我一个以“恢复原来的 custom skills”为目标的方案，而不是恢复整个 Ubuntu。

目前旧 VHDX 已经停止写入，PhotoRec 也是只读扫描，恢复结果全部写到 D 盘。

如果需要，我可以继续提供：

lsblk
dumpe2fs/debugfs 输出
e2fsck 日志
PhotoRec 当前进度
恢复出来的 SKILL.md 示例
恢复出来的 SQLite schema
VHDX 文件信息

我现在最想避免的是继续对原 VHDX 做任何可能破坏数据的写操作。

Xiaote

先做的不是继续 carve，而是把 ext4.vhdx 整盘镜像一份，之后所有操作只对镜像做，原 /dev/sdd 从此只读。你已经跑过 e2fsck -f -y，原盘的元数据已被改过一次，镜像能保证后面工具产生的任何写都不会再伤到证据。

PhotoRec 是当前最差的选择：它只按文件签名 carve 内容，天生丢目录结构。你的目标恰恰是「结构 + 文件名」，所以应该换 metadata 级工具，PhotoRec 从属、不要当主力。

推荐顺序（都在镜像上做）

TestDisk（不是 PhotoRec）：testdisk image.dd → Advanced → 选 ext4 分区 → Undelete。它读的是目录项（directory entry），能带出原始文件名和目录层级，直接找 home/<用户>/.hermes/skills/ 拷出来。你这种「root inode 被重建、但 inode 表/目录块大概率还在」的情况，这是性价比最高的一步。
The Sleuth Kit：fls -r -p -o <分区偏移> image.dd > listing.txt，从目录块重建树；即使根目录坏了，也可以按 inode 号逐个 fls image.dd <inode>，再用 icat image.dd <inode> > 文件名 按名字导出，或 tsk_recover 整目录导出。TSK 和 PhotoRec 的关键区别就是它保留 inode/名字。
extundelete / ext4magic：extundelete --restore-directory '/home/<用户>/.hermes/skills' image.dd、ext4magic image.dd -M -d /恢复目录 -f /home/<用户>/.hermes。二者依赖 journal；你的 journal 被 e2fsck -y 重建过，命中率不高，但在镜像上跑零成本，值得试。
元数据全毁时的兜底：用 debugfs 结合目录块扫描；也可以在镜像上 grep -a -b 定位 /.hermes/skills/、SKILL.md、.usage.json 等字符串，从残留目录项里拼路径。注意：e2fsck -b <备份超级块> 只能恢复组描述符，不会把你清掉的 root inode 内容找回来，别在这上面耗时间。

只扫 44GB 实际块，别扫 1TB 逻辑盘

PhotoRec 现在对 1 TB 虚拟地址空间空转，这是它慢的主因。先把 VHDX 转成稀疏 raw：qemu-img convert -O raw ext4.vhdx ext4.raw（输出文件按已分配块落地，逻辑仍是 1TB 但物理只有 ~44GB），之后所有工具只读这个 raw。用 qemu-img map ext4.vhdx 可以先看哪些块真的分配了。

怎么区分 bundled / hub / 自己 /learn 的 custom skill

在另一台干净 WSL 里装一份同版本 Hermes，对官方 bundled skills 的每个 SKILL.md 做 SHA-256 清单；拿这份清单和恢复出来的 214 个逐一比对，命中即官方/公共，剩下的才是候选。
优先找这几个 provenance 文件：.bundled_manifest（内置清单）、.hub/lock.json（hub 安装来源 URL）、.curator_ledger.jsonl（逐条留 provenance：bundled / hub / learn / auto）。custom 的 /learn skill 通常不在前两者里。
兜底来源：~/.bash_history、~/.hermes/logs/、历史会话记录里 /learn <名字> 的调用会留下 skill 名——这些是纯文本，比 sqlite 好恢复得多。
你查的 7 个 sqlite 都不像 state.db，基本可以放弃从 DB 反查；重心放在文本 provenance + 与官方清单的差集。

一句话方案：镜像 → TestDisk/TSK 拿回 ~/.hermes/skills 的目录与文件名 → 用「官方同版本清单差集 + curator ledger / bash history」挑出真正的 custom skill → PhotoRec 结果只当补充。

预防（下次别再踩）：VHDX 放 NTFS/ReFS，别放 exFAT；定期 wsl --export 整机备份；~/.hermes 单独用 git 或网盘同步。exFAT 对 WSL 的 ext4.vhdx 是出了名的不合适。

九龙杨生

这种还是要弄个定时备份任务，传到NAS后者云服务器，最多损失一天数据

kos or

我也是擔心遇到這種狀況辛苦配置的各項設定

koala

磁盘损坏真是个难搞的事情

williamlouis

如果这个skill 价值连城就继续。
换个电脑重写一次吧。都是你本人的作品怕什么。只会比你恢复它更快。

抡锤者

求助！我这种情况，怎么恢复hermes skill

name: xxx description: xxx

name: xxx
description: xxx