Table of Contents
include_toc
| include_toc |
|---|
| true |
Native SD migration validation
Hardware setup · Internal storage · EEPROM
The 2026-09-26 revision replaces the primary NVMe boot medium with native microSD
and retains SYSTEM on USB. A separate Raspberry Pi OS USB drive provides
maintenance. Frozen release 0.1.0 and its acceptance records remain unchanged.
Scope
The storage loader accepts native MMC cards of type SD, keeps existing NVMe
support, rejects USB ancestry and refuses multiple eligible internal disks.
Normal boot remains read-only; settings installation and bounded diagnostic
storage remain explicit recovery operations. EEPROM previews now offer SD-only,
SD-then-USB and USB-then-SD profiles. They never apply firmware to hardware.
Pi MMC drivers are explicitly built in. Generic PCI SDHCI is added to exercise
a real Linux MMC card in QEMU's ARM virt machine, not to emulate the Pi SD
controller. No new Rust crate or userspace package is required.
Software evidence
These results apply to the local working-tree revision built as
1.0.r3.ga14ea7714598.dirty, not the frozen release. The manifest
out/manifests/sd-migration.json records the source snapshot, artifact identities,
logs and limitations. Logs are retained under out/logs/sd-migration/.
| Check | Result and evidence |
|---|---|
| Native CLI tests | All seven CLI/program tests pass, including native SD identity, removable-flag independence, preserved NVMe detection, and rejection of USB ancestry, eMMC and unknown transports |
make check and make wiki-check |
Pass; repository policy, formatting, cleanup and wiki checks complete |
| Kernel build | Pass; required FDS and Dasung configuration is checked against the resolved kernel config; final cached build inputs verify |
| CLI and development rootfs | Both rebuilt with the current loader; make rootfs-test passes for each profile |
| Recovery, SYSTEM, initramfs and boot images | Rebuilt and audited; raw/gzip/lz4/zstd initramfs variants produced, both SYSTEM profiles available, complete internal GPT image validated |
make boot-test |
All nine cases pass with the rebuilt Pi kernel on ARM virt; out/m4-vm.KLp2AG includes real stage0, SYSTEM handoff, native s6 PID 1/service checks, recovery and immutable-input checks |
make internal-test |
Full rerun passes under out/m12-internal.k16rdxnn; see the initial shutdown failure below |
make eeprom-test |
Pass under out/m12-eeprom.ixlnzj5p; all three boot orders, immutable firmware payloads, exact rollback and overwrite refusal checked |
make flash-test |
Disposable-file tests pass under out/workstation-flash.gzimnkb2; inspection also accepts the three completed disk images below |
make workstation-test |
Pass under out/workstation-images.z14xle7n, including another flash regression run under out/workstation-flash.qikhs4at |
make emulator-test |
Pass under out/emu-test.6lzniavt; public emulator, guest software, twelve virtual bays, legacy reading and cartridge lifecycle checks complete |
make init-test |
Blocked before guest launch by the unavailable pinned upstream kernel package; not a pass |
The internal-storage suite boots the packaged recovery and SYSTEM with QEMU's
native MMC SD device. It verifies read-only settings loading, explicit atomic
installation, bounded diagnostics, persistence on the next boot, immutable
per-boot settings, normal USB SYSTEM operation and independent ext4 checks.
The persisted status reports source: internal_sd. Existing NVMe tests pass,
USB copies are rejected, simultaneous eligible SD/NVMe disks are refused, and
an unclean SD filesystem falls back without writes. The VM SD backing file is
extended to 2 GiB and its backup GPT relocated for QEMU's power-of-two card-size
requirement; the distributed image geometry is unchanged.
Open validation limitations
The first internal-storage run, out/m12-internal.k1jrziss, stalled during
shutdown after successfully loading persisted SD settings and diagnostics.
Shutdown reached the native s6 TERM/KILL phase but did not report power-down
within 120 seconds. A diagnostic reboot and five further diagnostic repetitions
powered off successfully, and a full rerun of the unchanged test suite passed.
No runtime fix, added retry or relaxed assertion was made. The cause remains
unexplained; the passing rerun does not establish that the intermittent stall
is fixed. The original log and diagnostic repetitions are retained as
internal-first-failure.log, sd-shutdown-diagnose.log and
first-storage-run/ beneath the log directory.
The standalone init suite still pins Void package
linux6.12-6.12.110_1.aarch64.xbps. Its configured upstream URL returned HTTP 404
and no matching cached artifact was available, so make init-test stopped before
launching a guest. The pin was not changed as part of the SD migration. The
separate Pi-kernel boot matrix did execute the M2 guest PID 1 and service-control
checks successfully, but this does not turn the blocked standalone suite into
a pass. See init-checks.log.
Built disk images
Both the SD image and SYSTEM must be updated: the settings loader is included in SYSTEM as well as recovery. These images were rebuilt from the same loader. The 1.75 GiB internal image fits on a 32 GB card; unused capacity remains unallocated.
| Output | Bytes | SHA-256 |
|---|---|---|
out/fds-internal.img |
1,881,145,344 | b7ae58292972d54c81dbb887281ad39cf810199c174c3985a6e44b20c59fcc62 |
out/fds-system-cli.img |
495,976,448 | 3e8813f416c1e91fa827b99db104a3e9b6575884ff1fb5f99f2cda78927ff2d6 |
out/fds-system-development.img |
1,991,245,824 | fcde95d7008981b44a1a2220d82c9a999180ce39a214abae25a22970127b525a |
out/manifests/sd-migration-artifacts.json also records the exact resolved build
directories, kernel, boot volume, recovery, initramfs and three rootfs archives.
out/manifests/sd-migration-images.sha256 provides their checksums for local
verification. These generated files are local evidence, not published wiki
attachments. Final validation notes were written after image construction;
the checkout wiki contains the latest acceptance record.
Physical acceptance
No Pi EEPROM update, physical SD boot, maintenance USB boot, power-loss test or
Dasung power-cycle test was performed by this software run. Follow
the four hardware checks
and record the card identity, boot order, image hashes and observations in
tests/hardware/session-template.json. The added cases remain not_run until
measured. An ARM VM pass cannot substitute for any of these observations.
FDS/OS
Start here
Use the computer
- Use cartridges and run programs
- DATA and persistent files
- WindowMaker and FDS Control
- Dasung Paperlike display
Install and maintain
- Flash disk images
- Internal storage and machine settings
- Pi 5 EEPROM configuration
- Recovery and rollback
- Verify a release
- Reclaim build space
- Troubleshooting
Build and contribute
Home · All pages · Edit the wiki · Source repository
Maintained directly in the fds-os.wiki repository. Historical acceptance applies only to the source and artifacts identified in each record.