Battlebox WSL rebuild — finishing handoff

2026-07-30 08:00 CET · for an agent operating via SSH from another machine · continuation of handoff-battlebox-disk-wsl-rebuild-20260730-1201

Summary

All repo work on battlebox's old WSL distro is committed and pushed (zero unpushed commits, audited). Ubuntu 26.04 ("Ubuntu26") is installed on D: and fully bootstrapped (user, dotfiles, SSH, agent CLIs, agent state, t3cc). Backups are staged to D:\wsl-rescue. Remaining: finish/verify D: copies and archives, mirror archives to G:\My Drive\260730_battlebox_backup, verify Ubuntu26 over a few days, then archive the old VHDX and wsl --unregister Ubuntu (frees ~242 GB on C:). The retirement step MUST be done from outside the old distro — hence this handoff.

Access & environment

SSH to the Windows host (Windows OpenSSH, user ai), then drive WSL via wsl.exe from PowerShell. Tailscale is installed on the host if direct LAN fails.
Distros: Ubuntu = old 20.04 (241.8 GB VHDX on C:, to be retired). Ubuntu26 = new 26.04 at D:\WSL\Ubuntu2604.
Ubuntu26: default user ai (uid 1000, NOPASSWD sudo), systemd on. Old distro: user ai, sudo needs password; root only via wsl -d Ubuntu -u root.
A loopback-only sshd runs inside the old distro (127.0.0.1:22 in the WSL VM, root key = /home/ai/.ssh/id_ed25519_bitbucket_battlebox) — reachable only from within the VM; used by the in-distro agent, not needed from outside.

Known trap: WSLInterop binfmt flush recurring

The old distro repeatedly loses its WSLInterop binfmt entry (first flush coincided with Ubuntu26's first systemd boot; per-distro binfmt instances have since diverged). Symptom: any *.exe from inside the old distro fails with Exec format error. Fix from PowerShell:

wsl -d Ubuntu -u root bash -c "echo ':WSLInterop:M::MZ::/init:PF' > /proc/sys/fs/binfmt_misc/register"

Note: long-lived shells inside the old distro may hold a stale mount namespace and still not see the entry — new sessions do. systemd-binfmt.service is already masked in Ubuntu26, but the flush still recurred at least once afterwards (second flusher unidentified). Self-heal without Windows access: ssh root@127.0.0.1 (from inside the old distro, battlebox key) and write the register line there — a fresh ssh session always lands in the live namespace.

Current state (as of 2026-07-30 ~08:00)

Repos — all safe verified

12-agent sweep committed+pushed every dirty repo/worktree under /home/ai/dev; final audit found zero unpushed commits on any branch of any repo/worktree. Remaining dirty files are documented generated artifacts/symlinks only.
Highlights: guardrails AI3D-335 noise-wall WIP (3 commits), trajectoryfilter AI3D-303, lanefinder Step5+ driver, orchestrator ai3d-two-stage-step7 branch had never reached Bitbucket — now pushed. linebitmap + lanefinder masters were rebased onto newer origin before push.
tablecloth: remote was a dead local bundle; re-pointed to git@bitbucket.org:ioholding/3dai.iolabs.pointcloud.tablecloth.git — Bitbucket already had everything.
pytorchinstancesegmentation + pdfpropertyai: unreachable via the battlebox SSH key (key lacks access; repos exist). Verified via HTTPS token (ms_iolabs + $T3CODE_BITBUCKET_API_TOKEN from ~/.env) that local history ⊂ remote. Safety bundles at D:\wsl-rescue\*.bundle.
windowchecker pushed via the same HTTPS token workaround (SSH key lacks access there too).

Data moves

~/ai3d339-sweep/tcs_cache (23.2 GB, 1508 files) moved to N:\02_Modelling\05_Rink\02_AI 3D modeling\03_Working folder\tcs_cache (byte-verified, source deleted). N: is Google Drive — confirm the Drive client finished uploading before trusting it fully.
D:\wsl-rescue\: <repo>\.git snapshots (2.3 GB, pre-commit state), dev\ (89 GB, post-commit, rsync exit 0), home-ai\ (45.8 GB, rsync exit 0), 2 repo bundles, agent caches under home-ai\.cache + home-ai\.local. all complete
D:\wsl-rescue-archives\: dev.tar.zst 75 GB, home-ai.tar.zst 28 GB, git-snapshots-pre-commit.tar.zst 2.3 GB, README.txt — all built, exit 0.
G:\My Drive\260730_battlebox_backup\: all 3 archives + 2 bundles + README staged and size-verified (byte counts match D:). Staged into the DriveFS cache (on D:\GDrave_Cache) — confirm the Drive client finished the cloud upload before treating G: as durable.
Excluded everywhere as regenerable: .venv, __pycache__, node_modules, ~/.cache (except agent caches), ~/.local (except cursor-agent), zrange_venv, Anaconda installer.

Ubuntu26 — bootstrapped working

User/dotfiles/SSH migrated (Bitbucket auth tested OK from inside Ubuntu26). .env, bash config, .claude 5G, .codex 647M, .cursor 740M, .config, .t3 638M all copied with permissions (tar-pipes).
Installed: apt base + build-essential, node 22, uv 0.12.0, claude 2.1.220, codex 0.146.0, cursor-agent 2026.07.23, t3cc 0.1.0 (from restored source).

t3cc incident partially recovered

Every file in /home/ai/dev/t3cc was truncated to 0 bytes on 2026-07-29 ~11:22 (cause unknown). Source (771 lines, 8 modules) restored from the uv-built wheel (~/.cache/uv/sdists-v9/.../t3cc-0.1.0-py3-none-any.whl); pyproject/README reconstructed from wheel metadata; committed to a fresh local-only git repo (c5b26ab). Tests are lost (only cpython-314 .pyc files remain). No remote exists — create ioholding/t3cc on Bitbucket or keep the D: copies safe.

Next steps (ordered)

Done by the in-distro agent — D: staging, all archives, and the G: mirror are complete and size-verified (see Current state). Only remaining check: confirm the Drive client finished uploading 260730_battlebox_backup (system-tray / GoogleDriveFS activity) and that N:\...\03_Working folder\tcs_cache finished syncing, before calling either durable.
Ubuntu26 verification (days, per original plan): nvidia-smi / CUDA via WSL driver; re-clone repos (Bitbucket SSH already works) or seed from D:\wsl-rescue\dev; . ./scripts/nexus_credentials.sh && uv sync in lanefinder; run a small pipeline step; launch claude/codex/cursor-agent/t3cc once each.
Retire old distro — only after Miro signs off: wsl --shutdown, locate ext4.vhdx via (Get-ChildItem HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | Get-ItemProperty | ? DistributionName -eq 'Ubuntu').BasePath, copy to D:\wsl-backup\Ubuntu2004-ext4.vhdx, then wsl --unregister Ubuntu (frees ~242 GB on C:). The 33 lanefinder stashes + 3 others live only in this VHDX (Miro chose not to push them).
Optional C: cleanup still pending Miro's approval (from the first handoff): C:\Autodesk 66.8 GB, old download zip 54.9 GB, Google Drive cache 29 GB, misc ~16 GB.

Risks & open questions

rotate Live AWS credentials are committed in pytorchinstancesegmentation history (.aws/credentials, awsCreds, new_user_credentials.csv, IAM user "DockerAI"). Rotate in AWS IAM regardless of anything else.
wt-surface-mesh branch worktree-surface-mesh-redesign pins uv sources to absolute /home/ai/... paths (commit 1364a84) — revert to Nexus sources before merging.
The battlebox SSH key (id_ed25519_bitbucket_battlebox) lacks access to windowchecker, pytorchinstancesegmentation, pdfpropertyai on Bitbucket — grant access or keep using the HTTPS token.
Stashes are not preserved anywhere except the archived VHDX. How long to retain D:\wsl-backup\*.vhdx? (open question for Miro)
t3cc tests unrecoverable as source; regenerate. What truncated the files on Jul 29 is unexplained — watch for recurrence.
The in-distro session may still be running background jobs when you start — check pgrep -af 'rsync|zstd' inside Ubuntu before re-running transfers.