DESKTOP-DGJP6BI · Windows 11 + Ubuntu 24.04 (WSL2) · Ryzen 9 9950X3D · 61.6 GB RAM · RTX 5090 32GB
体检 2026-07-29 15:11 → 修复 2026-07-31 00:36 ·
执行方式：Claude 主会话直接取证 ＋ Codex 两轮独立并行审计（26 min + 33 min），双方交叉验证
按「会不会真的丢东西 / 是不是正在出错」排序，不按修起来难不难。
后台常驻的 mcp-memory-tunnel.sh 陷入无限重连，MCP memory service 完全不可用。
127.0.0.1:8765 — Connection refusedtailscale ping gpu13 → 6 ms 直连，完全正常根因不是网络。Tailscale ACL 对该 SSH 规则启用了 check mode（周期性强制浏览器认证），而隧道脚本用 ssh -o BatchMode=yes —— 自动化进程在架构上不可能完成交互式认证，于是每 5 秒重连一次，每轮生成一个新的 login URL。
一个根因，两处症状。同一条 ACL 规则同时导致：① MCP memory 隧道刷屏 1124 次；② bbhouse 备份 7/28 少了一行 gpu13 ok。后者安静得几乎不可能被人发现 —— 这正是备份必须有主动告警、而不能靠人读日志的原因。
体检开始时 /mnt/data（2 TB，339 GB 数据）根本没有挂载，而 Windows 计划任务报告 LastTaskResult: 0（成功）。
根因链：--bare attach 之后立刻执行 mount LABEL=aidata，但块设备枚举与 label 注册需要数秒 → mount 失败 → 失败被 || 短路吞掉 → bash -lc 的退出码取自末尾的 chown（总是成功）→ 任务永远报成功，磁盘永远没挂上。
修复：轮询等待 label 就绪（最多 20 s）＋ 失败时真的返回非 0 ＋ 写审计日志。验证时任务写出了 MOUNT_OK。
万幸挂载点目录只有 4.0 K —— 没有数据被误写到未挂载的挂载点上，这是这类故障里最危险的场景。
Codex 第二轮的核心发现，与主会话的排查互相印证：
/mnt/data/projects 43 个项目中 32 个无独立备份models/（61.9 GB）被 .gitignore 排除，Git 完全不保护ai-daoshi ahead 6、storeysg ahead 9、ghosthand dirty 18…）~/Claude Config 路径已不存在，两个 folder 都无 versioning —— 误删会同步传播到所有节点/.snapshots、~/.local/share/Trash、/mnt/data/.Trash* 全部不存在，删除操作没有任何后悔窗口清理磁盘不解决这个。真丢数据是从这儿丢的。
按回收量排序。每一项都在删除前做了引用检查，去重则用 hardlink 而非删除。
| 盘 | 体检开始 | 现在 | 回收 | 使用率 |
|---|---|---|---|---|
/ 系统盘 | 331 GB | 316 GB | 15 GB | 34% |
/mnt/data 数据盘 | 339 GB | 268 GB | 71 GB | 14% |
去重那步刻意没有删除任何一份：用 ln B A.hltmp && mv -f A.hltmp A 把两份合并成 hardlink —— 两个路径都保留、所有引用不受影响、内容零变化，中断也不丢文件。合并后重新计算 SHA-256 确认与合并前一致。
删一份要先搞清楚哪个路径被谁引用（ComfyUI 配置、workflow JSON、脚本里的绝对路径都可能指向任一份），判断错了就是坏引用。hardlink 把「回收空间」和「保留路径」解耦。代价是共享写语义，所以只适合模型这类只读资产。
| # | 项目 | 验证方式 |
|---|---|---|
| 1 | DNS 顺序：去掉 rotate，最快的排前面 | 4 个关键域名解析正常，6 ms |
| 2 | mount-ai.cmd 挂载竞态：轮询重试 ＋ 失败真返回非 0 | 任务返回 0，日志写出 MOUNT_OK |
| 3 | 9 个 .env/.npmrc 权限 → 600 | 逐个 stat 确认 |
| 4 | 凭据泄漏排查 | git 侧干净：.gitignore:31 有 **/.env，历史 0 命中 |
| 5 | 清理 8 个 pip 解包残留 | 回收 3.8 GB |
| 6 | 清理 journald 死数据 | 先确认最后记录停在 5/6 且无进程，531 M → 4 K |
| 7 | 清理 5 个失效 symlink | 顶层断链 5 → 0 |
| 8 | wrangler 4.82.2 → 4.115.0 | 版本号确认 |
| 9 | 6 组重复模型 hardlink 合并 | 合并后重算 SHA-256 与合并前一致 |
| 10 | 删除 32 GB 死 swapfile | 五重确认：swapon / /proc/swaps / 全配置搜索 / lsof / allocated blocks |
| 11 | 删除 11 GB 历史 audit 产物 | 删前查看内容并确认别处无副本 |
| 12 | 9 个代码仓库抢救推送 | 逐个 ahead 归零 |
| 13 | 本地备份体系（53 个单元） | 逐个校验文件数 ＋ 总字节 ＋ HEAD |
动手之前先挖出了一个长期隐患 —— 这个比抢救本身更重要。
$ ssh -T git@github.com
Hi shuaige121/claude-configs! You've successfully authenticated...返回 Hi <user>/<repo>! 而非 Hi <user>! —— 这是 deploy key 的标志，只绑定 claude-configs 一个仓库，对其它任何仓库都没有写权限。这一条解释了三个迷惑现象：
| 现象 | 真相 |
|---|---|
storeysg 报 "Repository not found" | 仓库存在且是 PRIVATE（7/28 刚推过）。GitHub 对无权访问的 private repo 统一报 404 而非 403，避免泄露"这个仓库存在" |
zhouruby.com 能读却不能写 | 它是 PUBLIC repo，读谁都行，写需要权限 |
gh repo create --push 建出空仓库 | gh 给 remote 设的是 SSH URL，push 立刻被 deploy key 拦掉 |
有效凭据是 gh token（scopes: repo），因此全程改走 HTTPS。
| 仓库 | 动作 | 结果 |
|---|---|---|
~/storeysg | 推 9 commits | ahead 0 |
~/leonardchow-work/zhouruby.com | 推 1 commit | ahead 0 |
~/.claude | 提交 14 文件 ＋ 推送 | untracked 归零 |
DATA/vlab | 新建 private repo ＋ 推 16 commits | ahead 0 |
~/ascend-sg | 新建 private repo ＋ 推 9 commits | ahead 0 |
~/zhouruby-portfolio | 新建 private repo ＋ 推 2 commits | ahead 0 |
~/ghosthand | 新建 private repo ＋ 推 1 commit | 历史已保护 |
DATA/maple-selector | 新建 private repo ＋ 推 15 commits | 历史已保护 |
DATA/roomforge | 无需推送 | 本地是过期副本，落后远端 53 个 commit |
推送前每个仓库都过了凭据门禁（检查被 git 跟踪的文件 ＋ git 历史）。命中的 4 个文件全部人工判定为非 secret：.npmrc 只有 legacy-peer-deps=true；.env.example 里是 URL 和 Cloudflare ID（wrangler whoami 本来就明文输出 Account ID）。zhouruby.com 是 PUBLIC repo，额外审了那 175 行新增：无密钥前缀、无 password/secret 赋值，3 个长串都是 CSS class。
不依赖 GitHub。备份盘与源数据物理隔离。
| 磁盘 | 型号 | 盘符 | 角色 |
|---|---|---|---|
| #0 | Samsung 9100 PRO 1TB | C: D: | 系统 |
| #1 | Samsung 990 PRO 4TB | E: | 源数据（ai.vhdx → /mnt/data） |
| #2 | Samsung 990 PRO 4TB | F: | 备份目标（1.2 T 可用） |
首次 rsync 后校验发现 sg-ea-research 少了 3 个文件（源 2490 / 备 2487）。定位后确认根因是备份盘 F: 为 NTFS，经 DrvFS 挂载后文件名大小写不敏感：
sci_gebiz_ds_q_SCIENTEC.json ↔ sci_gebiz_ds_q_ScienTec.json
..._EA_REG_ID_R1981125.txt ↔ ..._EA_Reg_ID_R1981125.txt
..._MOM_LICENSE_NO_16C7994_.txt ↔ ..._MOM_License_No_16C7994_.txt3 组冲突精确对应 3 个缺失文件。同目录下只差大小写的两个文件被折叠成一个 —— 而 rsync 退出码是 0。
解决：对存在冲突的项目改用 tar.zst 归档（tar 内部保留原始文件名，不受文件系统限制）。826 MB → 184 MB，2490 文件全部保留，6 个冲突文件逐一验证在档。这个检测逻辑已写进备份脚本，自动分流。
| 脚本 | 频率 | 内容 |
|---|---|---|
backup-git-mirrors.sh | 每天 04:30 | 24 个 repo push --mirror，含分支与 tag |
backup-projects-rsync.sh | 每天 05:00 | 29 个非 git 项目；自动检测大小写冲突并分流 rsync / tar |
两个脚本都遵循同一条原则：备份盘不可用时立刻失败退出，绝不把「盘没挂上」静默当成「没有文件要备份」 —— 这次体检里发现的备份类问题，几乎全部源于静默失败。
PCIe 不是降级。看到 Gen 2 / max 5 差点报故障，跑真实 CUDA 负载后：
空闲: Gen 2, P3, 1192 MHz, 68 W
负载: Gen 5, P1, 2512 MHz, 595 W, 98% 利用率Gen 2 是空闲省电，满载跑满 Gen 5，600 W 功耗墙也吃满。凡是带「当前值」的指标，都要先问一句「当前处于什么状态」。
Cloudflare 那个 401 是端点选错。Account API Token 本来就查不了 /user/tokens/verify，换 /accounts/{id}/tokens/verify 是 200，R2 bucket 也能正常列出。
RefreshWSLPortproxy 计划任务已不存在 → LAN 进 WSL 的 2222 端口完全不通（四条独立路径验证）.13/.6」已不符 —— Wi-Fi 网卡处于 Disconnected，实际只有 10G 有线在用Journal stopped）。所以「journalctl 查不到今天的错误」不等于「今天没错误」1.1.1.1（37.6 ms）放在第一位还开了 rotate，而 8.8.8.8 只要 2.2 ms — 约一半查询白白多花 35 ms（已修）| 服务 | 状态 |
|---|---|
| 1Password | 正常 CLI 2.34.0 已登录 |
| Cloudflare | 正常 token 有效，R2 可列 |
| MCP servers | 4 个中 3 个正常；memory 因隧道故障不可用 |
| Gmail | 未配置 缺 app password，daily-ingest 每天跳过 |
| Notion | 零集成 无 MCP、无 API key、无 CLI |
| 显示器 | 未跑满 XG32UCWG 当前 2560×1440@120Hz，驱动报最高 164Hz，EDID 原生 3840×2160 |
| 优先级 | 事项 | 为什么需要你 |
|---|---|---|
| 高 | Tailscale ACL：SSH 规则 "check" → "accept" | 一改修两个故障，需在浏览器操作 |
| 高 | 重建 portproxy ＋ RefreshWSLPortproxy 任务 | 需管理员权限 |
| 中 | gh auth refresh -s workflow | 3 个 repo 卡在此（含 .github/workflows/），需浏览器授权 |
| 中 | Optimize-VHD compact ai.vhdx | 可回收约 412 GB，需 wsl --shutdown |
| 低 | 2 把 SSH 私钥加 passphrase | 需交互输入；7 个 alias 开着 ForwardAgent，含 2 个 root 登录 |
| 低 | 22 个未提交文件 ＋ 8 个 auto-stash | 需逐个看 diff 决定，已提交历史都已有异地副本 |
Codex 跑在 bwrap --unshare-pid --unshare-net --dev /dev 沙箱里，看不到宿主进程、网络和 GPU —— 它在报告里诚实标注了这些盲区，两边正好互补。
| 来源 | 独有贡献 |
|---|---|
| 主会话 | 宿主进程与服务、Docker、监听端口、GPU 实时状态、Windows 侧信息、cron 日志审计、git 状态、Tailscale SSH 故障、portproxy、显示器与驱动、网络连通性 |
| Codex | SRSO 漏洞硬证据、36 GiB 重复模型（SHA-256 ＋ inode ＋ link count 三重验证）、uv cache 精确可回收量、32 GB 死 swapfile、ext4 错误计数器、无备份项目清单、敏感文件权限面、SSH 私钥无 passphrase |
| 双方一致 | /mnt/wsl 无 RAM 泄漏、磁盘/inode/内存/CPU 正常、/tmp 29 G、52 个待更新包、E 盘 81% |
分歧一处：Codex 把 SRSO 推测执行漏洞列为唯一「严重」，主会话下调为「关注」—— Safe RET 缓解已生效，缺的 microcode 只能靠宿主 BIOS，且单用户物理开发机的威胁模型不匹配。Codex 的取证是对的（主会话最初把那条 dmesg 当成 WSL 正常噪声忽略了），分级按威胁模型调整。
health-check-20260729.md / repair-log-20260729.md