Rootfs from USB: the first two ROOT boots (2026-11-04)

Read 2026-11-04 (6:00 PM ET) from the AP console log, /init’s netlogs and the rootfs’s persistent journal (read from the stick’s partition 2 on the build host after boot 1). Attempts 2026-11-04-18 (warm start) and -19 (cold). Kernel #29 7.3.0-gbook-g82c43ed, KERN-A image 645d9f3dc3ab525c (15 tries), rootfs builds of 2026-11-04 (306, then 307 packages; snapshot=none: deb.debian.org and offline builds). MACs, SSIDs and serials redacted; no identifier is quoted.

What worked

• /init found ROOT by kern_guid (root-lookup: the booted disk’s partition 2 is gbook-root), mounted it (init=/sbin/init), sent its netlog, and exec switch_rooted (GBOOK: switch_root=/dev/sda2), both boots.
• systemd 262.1 booted Debian sid arm64 from the stick; the journal is persistent on ROOT.
• Mesa on the GPU (M3 criterion): eglinfo -B: OpenGL 4.6 Core and Compatibility, vendor freedreno, renderer “Adreno X1-85”, Mesa 26.2.6-1; kmscube -D /dev/dri/card2 -c 120: exit 0, OpenGL ES 3.2, renderer “Adreno X1-85”; cage (-d): “EGL driver name: msm”, “GL renderer: Adreno X1-85”, GLES2 renderer on eDP-1 at 2560x1600, 120 Hz. /dev/dri/by-path: platform-3d00000.gpu-card -> card1, -render -> renderD128, platform-ae01000.display-controller-card -> card2 (msm.separate_gpu_kms=1).
• Ghostty 1.4.0+gbook (the cross build) ran under cage as user gbook with a bash shell; the owner typed in it (which ghostty gave /usr/local/bin/ghostty). Boot 1’s m3-cage=inactive was an ordering bug (After=gbook-m3 held the unit until the capture script ended); boot 2 captured it active with the renderer line.
• Wi-Fi in userspace (M3 criterion), boot 2: with 10-wlan0.link the interface kept its name; wpa_supplicant@wlan0 (reading /run/gbook/wpa_supplicant.conf) joined: Connected, 6135 MHz, -38 dBm, rx 1297 / tx 3843 Mbit/s 320 MHz EHT; networkd: “State: routable (configured)”, “Online state: online”, a DHCPv4 address via .
• Audio state known (M3 criterion): aplay -l: “no soundcards found” (no sound node in the DTS; ticket 10).
• Both boots powered down cleanly on the owner’s command (reboot: Power down, EC G3).

What failed, and the fix in the tree

Timings

The sweep is the next target (a fast path when ROOT is present), an owner decision.

Boot 3 (attempt 2026-11-04-20, cold; read 6:54 PM ET)

Rootfs round 3 (321 packages: mount, iputils-ping, openssh-server, sudo; DHCP client id = MAC; the cage unit no longer waits for gbook-m3) and a KERN-A image carrying the ssh keys in the hand-off (ADR 0012 update, decisions 5 and 8):

• gbook-m3 at 156 s; the rootfs netlog arrived from the device’s first lease (sent 2175 lines ... exit=0), with a 1180-line redacted journal section; ping to the gateway 3 of 3; networkctl routable, online, lease .204.
• ssh from the build host works (ssh mica, key-only, user gbook, one attempt): hostname = mica, sudo -n runs (warning “unable to resolve host mica”: no /etc/hosts in the apt variant, fixed in the tree); zero failed units.
• Vulkan on Turnip works: over ssh, vkcube --wsi wayland --c 120 through cage’s socket: “Selected GPU 0: Adreno X1-85, type: IntegratedGpu”, exit 0; the device-select layer lists one device, 5143:43050c01 "Adreno X1-85". vulkaninfo --summary fails on vkGetPhysicalDeviceDisplayPlanePropertiesKHR (ERROR_OUT_OF_HOST_MEMORY) with the GPU-only card, a tool limitation; gbook-m3 captures vkcube instead from the next build. The first vulkaninfo attempt had an empty VK_DRIVER_FILES (the ICD is freedreno_icd.json, no architecture infix): fixed.
• cage on the Adreno again (GL renderer: Adreno X1-85); m3-ssh=active listening 0.0.0.0:22.
• The parked touchscreen failure printed as one KNOWN: line per segment (before and after GBOOK: begin).

Release boots (attempts 2026-11-04-21, -22, -23, all cold; read 8:37 PM EST)

The release rootfs, built from snapshot 20261104T000000Z (321 packages, rootfs.ext4 sha256 4b0e2e027c0b2d74…; the afternoon’s deb.debian.org build differed in six package versions), written to ROOT with attempt.sh root-cmd and read back block by block by root-verify (ROOT == rootfs.ext4, 1048576 blocks of 4 KiB); the KERN-A base image 9673d6d782ef4cdb unchanged. Each boot from G3 (the EC’s own reset, then G3->S5), with one ssh mica read:

• attempt.sh tally '^2026-11-04-2[123]$': boots=3 known=3 stalled=0 clean=3, SCMI replies 0.1 ms, no polls.
• /init switched to ROOT on each boot; gbook-m3 at 156, 155 and 156 s; m3-end at 177.5, 176.1 and 177.2 s.
• kmscube, cage and vkcube on “Adreno X1-85” (Mesa 26.2.6-1) on all three; m3-ssh listening; the rootfs netlog arrived each time (2168, 2171 and 3498 lines).
• Over ssh: hostname mica, getent hosts mica = 127.0.1.1 (the /etc/hosts fix is live), systemctl is-system-running = running, zero failed units, sudo -n runs, wlan0 .204, aplay -l no soundcards (unchanged). The journal’s only error-level lines are sudo’s pam_env “Unable to open env file: /etc/default/locale” from the build host’s ssh sessions and one pam_systemd Varlink ReleaseSession line at logout; harmless, noted.
• Boot 3’s journal carried 658 i2c_hid_of 0-0010: i2c_hid_get_input: incomplete report lines within 0.1 s at 139.5 s (the switch_root moment), none on the AP console and none on boots 1 and 2: the parked touchscreen (touch-tpm-2026-11-03.md) bursting; no effect on the boot. The KNOWN: row’s pattern does not cover that message yet.
• Powered off over ssh after each read (sudo systemctl poweroff: “reboot: Power down”, EC to G3), with the owner’s OK.

Fast sweep (attempt 2026-11-04-24, cold; read 9:21 PM EST)

Task #24: /init takes a fast sweep when it finds ROOT (GBOOK: sweep=fast: ROOT found, about 10 s): every instant sysfs read, the Wi-Fi join and the netlog stay; the settles, the owner prompts, the backlight cycle, the standalone scan, the display wait and the *-dmesg greps go. gbook.sweep=full, gbook.suspend=<mode>, a dp-wait image or a stick without ROOT keep the M2 sweep (owner’s four decisions, before the stick write at 9:07 PM EST; .scratch/m3-rootfs/issues/14-fast-sweep.md). Kernel #29, image 6f921ebb, ROOT rewritten first (root-verify found the release boots’ r/w mounts: 4675 blocks differed, journal 1745; after root-cmd: equal).

• attempt.sh tally '^2026-11-04-24$': boots=1 clean=1 stalled=0, start cold; trace_report.py: replies=78, max 0.1 ms, timeouts 0 (attempt.sh trace scmi itself gave up: its line-count check also counts the rootfs’s later transfer; retro-10 ticket 07).
• Timeline (AP console): begin 6.9 s; Wi-Fi joined at 28 s (link wait 17 s, no scan); gpu-open=opened wait=1s (GMU firmware loaded at 31.0 s); switch_root 32.9 s; systemd 34.3 s; wlan0: associated again at 51.4 s; m3-begin 53.0 s; kmscube on Adreno X1-85 at 56.1 s; cage and vkcube read at 73 to 74 s; m3-end 74.2 s (177 s on -23). The rootfs side is now the larger half: 20 s to m3-begin, 21 s of captures.
• The rootfs side, read 9:31 PM EST from the journal and the AP console (41 s, switch_root 32.9 s to m3-end 74.2 s): systemd’s journald at 35.4 s, basic.target 37.0 s, wpa_supplicant@wlan0 started 37.0 s and connected at 51.4 s (its own scan: 14 s; /init’s association was dropped at switch_root), DHCP 51.5 s, IPv6LL and wait-online done 53.0 s, gbook-m3 from 53.0 s (eglinfo, vulkaninfo, kmscube, ping: to 58.1 s), gbook-cage.service started by gbook-m3 at 58.1 s (the unit is not enabled at boot), then its fixed sleep 15 to the m3-cage read at 73.1 s, vkcube and ssh 74.2 s. So Ghostty came up at about 59 s (cage start plus its own start; unmeasured on the panel), and 29 s of the 41 are the second Wi-Fi scan and the capture sleep. Task #26.
• Over ssh: running, 0 failed units, no error-level journal lines; the rootfs netlog arrived (2181 lines).
• Reads that differ from the full sweep by timing, not by state: ts-vreg disabled users=0 and gpio88 low at 32 s (the parked touchscreen’s supply; -23 read enabled users=1 at 105 s), no hid-over-i2c IRQ line for the touchscreen at 32 s, trace kept 586 lines (no touch window flooding the ring). The edp-reg line reads before the 33 s regulator cleanup; cage on the panel is the proof the panel survives it.
• Powered off over ssh after the read (sudo systemctl poweroff, 9:27 PM EST), with the owner’s OK. Power-on to Ghostty on the panel: unmeasured (cage’s lines at 73 s are gbook-m3’s journal read, not when it drew).

The rootfs side (attempt 2026-11-04-25, cold; read 9:59 PM EST)

Ticket 15 (task #26, the owner’s five decisions, every recommendation taken): gbook-cage.service enabled at boot (WantedBy=multi-user.target, After=seatd.service, conditioned on the Ghostty binary), gbook-m3 skips kmscube when Ghostty is there (cage holds the panel’s KMS device; its GL renderer line is the GPU proof) and polls up to 15 s for cage’s socket and renderer line instead of sleep 15, and /init prepends freq_list=<MHz> from its own joined link to the network block it hands over (GBOOK: wifi-handoff=freq_list=6135; the wpa_supplicant reference config: outside a network block, freq_list limits the scan). Kernel #29, image 6a0cc711, rootfs cbd68763… (321 packages, snapshot 20261104T000000Z, lock_changed=0: the release’s packages, the files of ticket 15). attempt.sh tally '^2026-11-04-25$': boots=1 clean=1 stalled=0, start cold; SCMI replies=78 max=0.1ms timeouts=0.

The rootfs side is 15.6 s now (41 s on -24): 25.5 s saved, 29 s expected (the second scan kept 6.8 s on one channel; a 6 GHz AP’s beacons and the supplicant’s own delays, inference). Over ssh: running, 0 failed units, 0 error-level journal lines; the rootfs netlog arrived (2167 lines). compare shows the new keys (wifi-handoff, m3-kmscube=skipped: cage holds the panel, m3-cage=... wait=0s uptime=) once as changed; ts-vreg read enabled users=1 and gpio88 high this time (timing, as on -24). The Xwayland “Cannot find” line is the known harmless one. Powered off over ssh after the read (sudo -n systemctl poweroff, 10:03 PM EST), with the owner’s OK: reboot: Power down, EC S5->G3, G3 at EC 385 s, then G3->S5 and S5 30 s later with no S5->S3: the EC’s soft-off on AC, the same sequence as after boot -24’s power-off (EC 3351 to 3381 s), not a power-on (a power-on continues S5->S3->S0 within a second, as at EC 0.5 s of this boot).

Open

• release-draft.sh’s bar for M3: met by the release boots above (8:37 PM EST); the owner tags (ADR 0011).
• The boot time: /init’s sweep is 138 s of the 176 s to Ghostty; a fast path when ROOT is present is an owner decision. 2026-11-04, 9:21 PM EST: done, the fast sweep (“Fast sweep” above): m3-end at 74 s. The rootfs side (20 s to m3-begin, 21 s of captures) is the next target. 2026-11-04, 9:59 PM EST: done, ticket 15 (“The rootfs side” above): m3-end at 48.7 s, Ghostty at about 38 s. Left: the wait-online tail after IPv6LL (1.3 s) and /init’s 17 s first scan (only a fixed scan_freq= in the owner’s wifi.conf shortens it).
• Journal timestamps read 2026-10-16: no time source in the rootfs (the RTC is unset); harmless, noted.