Robert Allan JamesandClaude Sonnet 5
35f84d4a45
Resolves the acl_pinned punch-list item's open question: credential data (ZUSE-CERT-LO/HI, ACL-CA-KEY-LO/HI) are CONSTANT words, i.e. real DictEntrys, and acl_pinned's enforcement (vm_create_word()'s unconditional shadow-refusal for any pinned name) already covers this generally -- no new flag needed, zuse.4th's ACL-ZUSE-BOOT already pins both cert constants today. That investigation surfaced a real gap: ACL-ZUSE-BOOT pins the cert constants unconditionally on every boot, before any legitimate mint could ever run, permanently locking in the 0 placeholder on the very first boot. This directly shaped Captain Bob's next design pass: a dedicated zuse.img test thumbdrive, "bleachable" back to pristine state for repeated first-boot testing; a one-time mint-then-pin flow (fixing the gap above); a separate ongoing S" name" MINT word for minting additional regular users; and an explicitly-deferred Zuse recovery path question. This commit is the first piece: disk/zuse.img (64MB blank, matching the existing USB-fixture convention) + scripts/bleach_zuse_img.sh (idempotent reset). Verified live via QMP hotplug -- reads back as HOMEBLOCKS_SIG_BLANK, correctly simulating a genuine first boot. Deliberately flat/raw, not GPT-partitioned, matching homeblocks_sig_check()'s current sig_start_fblock=0 assumption; both move to a real GPT-relative offset together once a parser exists. No kernel code touched -- host-side test tooling only, no 3-arch acceptance boot needed. Still open: the mint-then-pin boot fix, the MINT word, Zuse recovery. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn
110 lines
6.8 KiB
Markdown
110 lines
6.8 KiB
Markdown
# disk/
|
|
|
|
QEMU disk images used for Artemis (block-storage VM) persistence testing.
|
|
Mounted via `Makefile.starkernel`'s `ARTDISK` variable (default
|
|
`disk/artemis.img`) as a `virtio-blk-pci` device on all three
|
|
architectures' kernel QEMU boots — not `scripts/rundisk.sh`, which targets
|
|
a separate, currently-unused `disks/` (plural) directory for the *hosted*
|
|
VM's `--disk-img=` flag instead.
|
|
|
|
- `artemis.img` — standard Artemis persistence test disk. **Reformatted
|
|
2026-08-02**: this image had been stuck in a corrupted state (valid
|
|
`LithosAnanke` magic header, but data not matching what
|
|
`ART-READ-TEST` expects) since before this repo's own git history
|
|
begins (`git log` shows it already broken at the initial commit,
|
|
carried over from the pre-split monorepo). Chasing down the resulting
|
|
persistent `FAIL: persist-read` traced to the *data*, not the code —
|
|
the write→reboot→read round trip works correctly on a fresh image
|
|
(see `artemis-debug-roundtrip.img` below). Reformatted by blanking the
|
|
file and letting a normal boot format+write-test it; verified
|
|
`PASS: persist-read` on amd64, aarch64, and riscv64 against the same
|
|
image afterward (cross-arch resume, matching the arch-neutral on-disk
|
|
format `.claude/ARTEMIS.md` specifies).
|
|
- `artemis-debug-roundtrip.img` — round-trip regression fixture created
|
|
during that investigation. Known-good: format → self-test → write-test
|
|
→ reboot → resume → `PASS: persist-read`, confirmed 3 times in a row.
|
|
Keep this in a passing state; if a future change breaks it, that's a
|
|
real regression, not a stale-fixture artifact like `artemis.img` was.
|
|
- `artemis-persist-test.img` — persistence round-trip test image
|
|
(pre-existing; history/state not re-verified during the above
|
|
investigation).
|
|
- `artemis-poison.img` — a separate test image (exact scenario not
|
|
documented elsewhere in the repo as of this writing; name suggests an
|
|
adversarial/corruption test, not confirmed).
|
|
- `artemis-unrecognized-test.img` — exercises `ART-HALT-UNRECOG`
|
|
(`.claude/ARTEMIS.md` acceptance criterion #6). **Regenerated
|
|
2026-08-02**: the previous copy of this file had itself been silently
|
|
reformatted by a since-fixed bug in the *generic* block subsystem
|
|
(`src/block_subsystem.c`) — it carried a valid low-level `'STFR'`/v2
|
|
header despite being meant to represent foreign disk content, direct
|
|
forensic evidence of the bug described in `.claude/ARTEMIS.md`'s
|
|
Build Status item 6. Regenerated as 30MB of a repeating
|
|
`POISON-UNRECOGNIZED-DISK-TEST-FIXTURE--NOT-BLANK-NOT-STFR-NOT-ARTEMIS--`
|
|
ASCII pattern — deliberately neither blank, nor the block subsystem's
|
|
own `'STFR'` magic, nor Artemis's `"ARTEMIS\0"` marker. Verified on
|
|
amd64 and riscv64 post-fix: boot correctly halts
|
|
(`ARTEMIS HALT: unrecognized disk content`) and the file's sha256 is
|
|
now byte-for-byte identical before and after boot. Keep this fixture
|
|
in this poisoned state — if a future change makes its sha256 change
|
|
across a boot, that is exactly the regression this fixture exists to
|
|
catch.
|
|
|
|
Note on incidental header churn: `artemis.img` picks up a few changed
|
|
header bytes on every ordinary boot even though no user data changes —
|
|
`blk_subsys_attach_device()` always records a fresh `mounted_time` on a
|
|
successfully recognized disk, which gets flushed at shutdown. This is
|
|
expected bookkeeping, not a bug; revert it before committing rather than
|
|
carrying timestamp noise in git history.
|
|
|
|
- `usb-thumbdrive-test.img` — 64MB raw image backing a QEMU `usb-storage`
|
|
device attached to the xHCI controller's bus (`xhci0.0`) for Milestone 2e/
|
|
2h hotplug testing, added 2026-08-22. Blank (all zero) — `blkio_usb.c` +
|
|
`blk_subsys_attach_device()` wiring (Milestone 2h, done 2026-08-25) attach
|
|
it as `BLK_FMT_PROVISIONAL` every time, which is the intended, exercised
|
|
state; not yet `BLK_FMT_FORMATTED` via `BLK-CONFIRM-FORMAT`.
|
|
- `usb-thumbdrive-test2.img` — 64MB raw image, added 2026-08-25 for
|
|
Milestone 2h hot-detach/re-attach verification. Filled with a repeating
|
|
`HOTDETACH-REATTACH-FIXTURE-2026-08-25--` ASCII pattern, deliberately
|
|
distinguishable from `usb-thumbdrive-test.img`'s all-zero content — the
|
|
point is proving a block read *after* detaching `usb-thumbdrive-test.img`
|
|
and re-attaching this one actually returns this pattern rather than
|
|
silently replaying the old device's cached (all-zero) content, which is
|
|
exactly the class of bug a same-LBN-range device swap can cause if the
|
|
VM block window cache (`vm->blk_vm_cbuf[]`) isn't re-validated on a hit.
|
|
- `artemis-reloc-test.img` — 64MB raw image, added 2026-08-25 for single-block
|
|
relocation (`RELOCATE-BLOCK`) persistence verification. Blank at creation;
|
|
a genuinely *fresh* volume was required (not `artemis.img`) because
|
|
relocation-table capacity (`reloc_start`/`reloc_devblocks` in
|
|
`blk_volume_meta_t`) is only reserved by `blk_compute_fresh_geometry()` on
|
|
a fresh format — `artemis.img` predates the feature and correctly reads
|
|
back `reloc_devblocks=0` from what was previously unused header padding.
|
|
Attach via `make -f Makefile.starkernel ARTDISK=disk/artemis-reloc-test.img
|
|
...` (the Makefile's `ARTDISK` var is `?=`-overridable). Not yet
|
|
`BLK-CONFIRM-FORMAT`-committed in the repo copy — commit that step live if
|
|
reusing this fixture for further reloc-table testing.
|
|
|
|
- `zuse.img` — 64MB raw image simulating the physical Zuse superuser
|
|
thumbdrive for QEMU testing (FABRIC-3.md, Phase 8: `zuse.img` "bleach"
|
|
mechanism, added 2026-08-26). Blank (all zero) at creation — reads back
|
|
as `HOMEBLOCKS_SIG_BLANK` via `homeblocks_sig_check()`, confirmed live
|
|
(`xhci: USB drive not recognized (blank or foreign media)`), simulating
|
|
a genuine first boot for exercising the still-to-be-built one-time
|
|
mint-Zuse flow. **"Bleach" it back to this pristine/unminted state with
|
|
`scripts/bleach_zuse_img.sh`** before each first-boot test run, rather
|
|
than hand-regenerating the file — same all-zero content either way, the
|
|
script just makes the reset a single documented, repeatable command.
|
|
Deliberately a flat/raw image, not GPT-partitioned, matching
|
|
`homeblocks_sig_check()`'s current call site (`repl.c`,
|
|
`sig_start_fblock=0`) — both will move to a real GPT-partition-relative
|
|
offset together once a GPT parser exists, not attempted ahead of that.
|
|
|
|
**Convention, standing as of 2026-08-22: every virtual disk/thumb-drive image
|
|
used for testing — Artemis persistence disks above, and USB Mass Storage
|
|
backing images alike — lives in this directory and is a tracked, committed
|
|
file, never scratchpad.** This was already `artemis.img`'s convention;
|
|
`usb-thumbdrive-test.img` and any future USB test images follow the same
|
|
rule. Confirmed no `.gitignore` in this repo excludes `disk/*.img`.
|
|
|
|
These are regenerable QEMU raw disk images, not source — see
|
|
`.claude/ARTEMIS.md` for the storage model they exercise.
|