M4 recovery matrix: Valve’s five rows mapped onto mica’s ChromeOS mechanisms

Written 2026-11-05, 10:58 AM EST [15:58 UTC], task #32 (owner decision 2026-11-05 on steamos-arm.md, “Decisions”, 1). Planning material for M4 (daily-drivable, Gate 3: ADR 0010: “installed on the spare SSD, with dual-boot or a documented return to stock”). Nothing here was run on the device; no ADR is written yet (the slot policy is an open owner decision below). Every row carries one of three labels: proven on mica (an attempt id or log row), proven in source (a research note’s file:line at its pin), or inference / untested. The vboot and depthcharge citations come from fit-packaging.md and chromeos-boot-path.md, both pinned at firmware-bluey-16702.B; this note does not reopen the source.

Answer in short

M4’s “documented return to stock” is already proven except for the physical swap. ADR 0002 puts M4 on a spare M.2 2230 SSD with the stock drive in a drawer, and ADR 0003 forbids writing the stock drive, so dual-boot on the stock SSD is excluded; “dual-boot” today is stick in, stick out (status row “Reboot back to stock”: stock boots once the stick is out, proven 2026-11-02-2 and 2026-11-03-5). Return at M4 is therefore: power off, put the stock SSD back, power on, Boot from internal disk, and Lock bootloader if a locked device is wanted. Lock bootloader wiping the data and relocking without the recovery stick is proven (project log 2026-11-02, “Unlock day, relock test passed”; recon.sh read green, flash.locked=1, locked). What is untested is what ADR 0002 already lists: does the firmware accept an unlisted drive, does a blank drive still reach recovery and fastboot, and is the drive bound to the device. That turns M4’s gate from “design a recovery system” into three owner-run probes (section “Test plan before M4”).

The Frame’s five rows and mica’s answers:

1. Previous slot: what vboot does, and what the owner can do

• Selection (fit-packaging.md section 5, vboot at firmware-bluey-16702.B): GptNextKernelEntry skips entries with neither successful nor tries and picks the highest priority (cgptlib.c:44-120); a booted entry with successful=0 loses a try (2load_kernel.c:768-779); with successful=1 tries are ignored (cgptlib.c:135-144); a failing entry is marked bad, 0/0, and the next one is tried (2load_kernel.c:742-743).
• On mica today: the stick’s KERN-A is written -S 0 -T 15 -P 15 (scripts/package-in-container.sh, retro-7/08): depthcharge takes one try per boot, nothing marks the kernel successful, and successful=0 keeps the 0/0 mark a rejected kernel gets (“No valid image detected”, runbook section 8). attempt.sh stick prints the tries left and new warns at 0. Proven on mica: 3 tries ran out after 3 boots on 2026-11-04.
• The Frame’s set-state good maps to cgpt add -i <N> -S 1 on the boot disk from the running OS after a verified boot (cgpt add -S/-T/-P, cmd_add.c:16-33). Two consequences:
  • The rootfs has no cgpt today (rootfs/packages.txt, read 2026-11-05); Debian ships it in cgpt (source vboot-utils): a package to add for M4, to be checked with scripts/size-rootfs.sh first.
  • It is a GPT write to the boot disk: M4 work under the owner’s OK, never in the stick era, where the stick is the only disk gbook writes and the build host writes it.
• “Previous” without a menu: with two kernel partitions on the SSD (KERN-A, KERN-B), “boot the previous OS” is either the automatic fallback (the new slot’s tries run out, or it is rejected and marked 0/0, and vboot takes the other) or an explicit cgpt add -i <old> -P <higher> before reboot. Neither is a key press at power-on. The firmware-fastboot oem set-priority and oem set-successful exist (chromeos-boot-path.md section 4) but need an ALink or PL27A1 bridge or a USB-Ethernet adapter over DHCP: not available with the current hardware.
• The policy decision (open, grilling question 1): keep the stick’s count-down (-S 0 -T n, a bad kernel marks itself 0/0, a good one still runs out of tries unless something writes successful), pmbootstrap’s installed-system values (-S 1 -T 5 -P 10, unlimited boots, no 0/0 signal), or two slots with the OS flipping successful after a verified boot (Valve’s shape; the “verified” test is gbook’s: m3-end reached, the names heard, the audio state read).

2. Reset the OS, keep user data

Nothing exists. Today the whole ROOT partition is rewritten from the build host (attempt.sh root-cmd, root-verify), which is the stick’s “reinstall”. At M4 the analogue is a root partition per slot (ROOT-A, ROOT-B) and a separate data partition (home, or Valve’s var + home split), so that a root rewrite leaves the data. Valve’s update discipline (write the inactive slot, read back, compare, only then switch) is the one attempt.sh verify already follows for the stick; keep the ordering when KERN-B comes (steamos-arm.md, section 5, second proposal). Inference throughout; no partition layout is decided.

3. Wipe user data without booting the OS

Nothing exists. Proposal: /init takes a command-line flag (gbook.wipe=data, name open) and runs mke2fs on the data partition, after printing what it is about to erase on the AP console and the panel, with a countdown. It needs mke2fs in the initramfs (busybox has mkfs.ext2 only; check before relying on it) and a way to set the flag without a rootfs: on the stick era that is a repackage; at M4, cgpt can only set attributes, not the command line, so the flag would live in the FIT’s command line of a dedicated “wipe” kernel entry (inference), or the wipe stays a the build host-side operation on the swapped-out drive. Task #36 covers the read-only lock in /init; this flag is its M4 sibling.

4. Reinstall from USB: the recovery stick

• Proven: Device Recovery Utility media reaches the recovery screen with Esc + F2 and serves 16560795, the installed build (Gate 1, 2026-11-02; ADR 0001 update). A full copy is in dumps/gate1/.
• Never run: Use USB drive. Runbook section 9: it erases the disk and installs 16560795; the stick’s ROOT-B carries chromeos-firmwareupdate, so a recovery may rewrite AP and EC firmware (inference).
• Two hazards Valve’s recipe has no analogue for:
  • the recovery keys with the image stick inserted mark KERN-A bad (runbook section 8; proven on mica, wifi-2026-11-03.md: the owner powered on with the recovery keys and the stick was rejected), so the image stick and the recovery stick are different Lexar drives and the recovery one stays out unless a recovery is intended;
  • with the spare SSD installed, Use USB drive would install stock onto the spare drive (inference), which is the “unlisted drive” probe’s second half: does it install, and does the result boot.

5. Unbrick the boot firmware

No EDL path is documented for mica. The boot firmware is depthcharge (Google_Mica.16702.*); CCD stays Locked and the agent rules forbid every firmware write (ADR 0001, ADR 0006, CLAUDE.md). ChromeOS recovery mode plus the recovery stick’s firmware updater (inference, section 4) is the only path on record. Valve’s QDL package is an answer for a Qualcomm device whose PBL exposes EDL; whether mica’s does is unknown and stays untested: an EDL probe would need a cable in the data lines at power-on and is outside every gate.

6. Know the state

The netlog is the fallback when the SuzyQ is out, not a replacement: it starts after Wi-Fi joins (about 35 s) and shows nothing of depthcharge. The three release boots of 2026-11-05 ran that way (log row “Release bar met for v2026.11.05”).

Test plan before M4 (owner only, no agent writes)

Each step opens the case: ADR 0002’s prerequisite (disconnect the battery-cable bracket, hold power 20 s, Service Manual) and the warranty note apply. In order, each one a dated recon note:

1. Blank-SSD probe (project log Phase 3 list): the spare SSD, empty, installed; power on with no keys. Learns whether recovery and fastboot live in the 32 MB firmware flash (fastbootd lives on the SSD), and what the firmware shows with no bootable disk (the dev-mode menu, or recovery). The SuzyQ records it.
2. Unlisted-drive probe (ADR 0002): the spare SSD with a gbook install written on the build host (the stick’s layout: KERN-A plus ROOT, cgpt attributes as decided in grilling question 1). Boot from internal disk. Pass = m3-end on the netlog and the names heard. Dell lists “Google Qualified” drives; this is the test of whether an unlisted one is accepted at all.
3. Swap-back probe: the stock SSD returns; power on; Boot from internal disk; stock boots (recon.sh reads orange, unlocked, the installed build). Then, if the owner wants the locked state: Lock bootloader (wipes; proven to relock without the recovery stick on 2026-11-02), stock boots, recon.sh reads green, flash.locked=1, locked. This probe is the one that closes M4’s “documented return to stock”.

Optional, after 2: the recovery stick with the spare SSD installed (section 4’s second hazard), only if the owner wants stock on the spare drive too.

Commands (named, not run)

Decisions (owner, 2026-11-05, 11:02 AM EST)

Grilling round; the owner took every recommendation:

1. Slot policy: two kernel partitions on the SSD; the OS marks the booted one successful after the verified-boot test (m3-end reached, the names heard), so a bad update falls back by itself. cgpt joins the rootfs for M4.
2. The stick stays as a second recovery path at M4.
3. The data-wipe flag in /init comes at M4, when a data partition exists (not with task #36).
4. The M4 ADR is written after the three probes, with their results.

Open questions (grilling round, as asked)

1. Slot policy for the SSD install (section 1): count-down as the stick, installed-system values, or two slots with the OS flipping successful after a verified boot.
2. Whether M4 keeps the stick as a second recovery path (the proven one; it costs nothing).
3. The data-wipe flag in /init (section 3): with #36 now, or at M4.
4. The ADR: now, or after the three probes.

Sources