Files
LithosAnanake/disk
Robert Allan JamesandClaude Sonnet 5 ea5d2c7ceb FABRIC-2.md: riscv64 re-verified 30/30 PASS for item 4.6's Artemis stress campaign
Closes the last open item in Section H. amd64 and aarch64 were already
confirmed post-quota-grant-fix; riscv64 was pending. Temporarily re-enabled
ART-STRESS-CAMPAIGN (block 4170, disabled since Section L) for this one
headless run, confirmed 30/30 reps / 1500/1500 trials passed with a clean
CAMPAIGN-DONE, then reverted the capsule back to its committed disabled
state (byte-identical to HEAD, mkcapsule --lint clean).

Two SUMMARY lines (reps 4, 15) printed visually garbled from concurrent
[HADES][DOE] console writes -- confirmed cosmetic only by grepping the full
log for refused (result=0) trials: zero matches across all 1500.

Also includes: the two DoE CSV exports and serial logs from this session's
riscv64 runs (audit artifacts per repo convention), and the resulting
Artemis disk image state from real block writes during the stress test.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-19 11:26:23 -04:00
..

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.

These are regenerable QEMU raw disk images, not source — see .claude/ARTEMIS.md for the storage model they exercise.