2.0 KiB
M3 static Rust tooling validation
Development reference and historical context. For current operating instructions, use the user manual. Acceptance applies only to the source and artifacts identified in each record.
Validated on 2026-09-21 (Asia/Shanghai), x86_64 Arch Linux with pinned Rust 1.98.0. This records the M3 diagnostic foundation before M4 adds the real boot handoff. See tooling usage and the through-M12 ledger.
Commands completed successfully:
make tooling
make tooling-test
make bootstrap
make smoke-test
make check
Both exported binaries were AArch64 static ELF executables without a dynamic
interpreter, shared-library requirements or GLIBC symbol requirements. Supplemental
ldd printed not a dynamic executable. At this milestone:
| Artifact | Bytes | SHA-256 |
|---|---|---|
out/fds |
537424 | 04052554eef3c592230aa912d6dbcaec9bc37c168c0e240b924a4fb215a68815 |
out/fds-stage0 |
375824 | 930afd537aaf8e90715e5ec73d70480b44fbe9dfe3c0615014ed78b36239bd7c |
Six shared-library tests passed. Actual ARM execution then verified tool identity, JSON output, the master-plan manifest example, strict/bounded manifest rejection, missing/unique/ambiguous SYSTEM selection, device-path rejection, explicit recovery selection, and duplicate boot-option rejection. All filesystem fixtures were temporary; no physical block device or monitor was accessed.
Build/source hashes are in out/manifests/fds-tools*.sha256; logs are in
out/logs/m3-tooling.log, m3-tooling-test.log, m3-bootstrap.log,
m3-smoke-test.log, and m3-check.log. Later milestones will replace these tool
artifacts; the hashes above describe the validated M3 version.
The M0 smoke script's optional host-PATH QEMU execution was skipped, as before; the M3 integration script explicitly ran both ARM tools using container QEMU. No physical Pi result or boot-speed claim is made. M3's stage0 refused normal boot invocation rather than claiming its diagnostic skeleton could switch roots.