4.0 KiB
Milestone 9 diagnostics
Current execution state and acceptance are in PLANS.md. This file records bounded host preparation failures, not systemd acceptance evidence. All timestamps are UTC; the VM is disposable and contains synthetic data only.
2026-10-25T18:28:55Z — M9.1-R8, initial create parse
python3 tests/vm/create.py registered only
wga-m9-debian137-20261025 (UUID
b14c850b-a21e-4a56-acca-785590f0c4ac) and stopped before VM configuration.
Cause: actual VirtualBox 7.2.8 machine-readable output contains an indented
rec_screen0 recording section marker. The strict parser rejected it. Read-only
inventory showed the target powered off with only its .vbox file; the existing
Windows VMs were unchanged. A narrow marker parser repair and synthetic test
passed independent re-review. Creation cannot be rerun because the target path
is occupied; a UUID-pinned resume procedure was reviewed instead.
2026-10-25T18:35:00Z — M9.1-R5/R8, resume final guard
python3 tests/vm/resume.py verified the exact partial target, then configured
the VDI, pinned installer ISO, NAT-only NICs, and private host marker/manifest.
Its final read-only guard refused actual quoted SATA attachment keys and
per-port metadata. python3 tests/vm/guard.py check first reported an
unrecognized machine-readable key; after quoted-key parsing it reported an
unrecognized attachment-shaped metadata key. Read-only showvminfo identified
SATA-IsEjected-1-0 among the actual metadata. Focused repairs accepted only
the observed key forms, required the exact SATA controller, and rejected
unrecognized/extra media and a symlinked target folder. Independent re-review
closed the findings; the integrated synthetic VM suite passed 26/26 and the
actual read-only guard.py check exited 0. No second resume or VM start occurred.
2026-10-25T18:47:20Z — M9.1 unattended prerequisite (recorded)
The first no-change VBoxManage unattended install ... --dry-run --start-vm=none
refused a single-label hostname. Repeating with the fully qualified synthetic
hostname wga-m9-debian137.invalid exited 0, including a separate dry run with
the local Guest Additions ISO. Both used current-user mode-0600 private
synthetic password files. VirtualBox prints password values in dry-run output;
the wrapper redacted them before display. These runs created no files or VM
configuration changes. Actual installer preparation, boot, Guest Additions,
and guest systemd remain unverified.
2026-10-25T18:53:05Z — M9.1 installer preparation (recorded)
Independent review found that the first prepare-only script omitted the
required --iso and used an unsupported root-password option; its media
comparison also rejected VirtualBox's empty SATA ports. M9.1-R9/R10 repairs
passed re-review and 33/33 synthetic VM tests. The corrected
python3 tests/vm/install_prepare.py exited 0 outside the sandbox with
password-bearing VirtualBox output suppressed. Read-only showvminfo showed the
same pinned VM powered off, NAT-only, with its one VDI at SATA 0 and the private
generated Unattended-<UUID>-aux-iso.viso at SATA 1. Generated installer files
were mode 0600 in the mode-0700 target folder. The normal guard intentionally
refuses .viso; first start awaits a separately reviewed installer-state guard.
2026-10-26T20:30:15Z — User stopped M9.1
The installer-state guard and start code passed independent review after a
hard-link isolation repair; the full synthetic VM suite passed 44/44. Actual
python3 tests/vm/install_boot.py check and start exited 0 against only the
pinned target. Read-only list runningvms listed only that VM; a private
console screenshot showed Debian base-system installation at 6%. Completion
was not observed. After the user explicitly stopped Milestone 9, the exact VM
was powered off; a subsequent read-only running-VM inventory was empty. Guest
installation, Guest Additions, systemd, WireGuard, and M9 acceptance remain
unverified. No existing Windows VM, production resource, Git commit, or
deployment was touched.