sunfish-adminandCursor
2d145c2878
Restore disable_configstore, EuiccDisabler and thermal CDEV guards, branding and rebuild/sync helpers; document device roles, laptop migration, and Gitea. Co-authored-by: Cursor <cursoragent@cursor.com>
2.9 KiB
Status: historical. Do not use as execution order. Resume:
009-handoff-20261008.md.
Verification of clean C and X experiments — 2026-09-27
Independently parsed the binary dumps and recorded kernel/boot properties in:
.local-artifacts/009-v4-clean-c-20260927T190738Z/.local-artifacts/009-v4-x-persist-20260927T191143Z/
The clean C test removes the earlier X/latch confounder: T2 has a zero failure zone and a fresh v4 #29 boot; T3 reports kernel_panic on an intermediate v4 boot; T4 is combo4 #16. No complete failure record is present after C. The intermediate boot prevents localization of loss to the panic itself versus later boot stages.
The X test demonstrates that all eight complete 55-byte X records survive the normal recovery to combo4 unchanged. It does not include the panic transition of the C test, so it is a recovery control rather than the same full sequence.
Precision correction: T3 and T4 are NOT identical binary dumps. Their first 128 bytes match, but 7,213 bytes differ across 4 MiB, including six bytes in the first 1 KiB. Likewise X2 and X3 have 79 differing bytes, despite their complete X records surviving intact. These differences do not negate X persistence, but avoid describing entire zones or dumps as identical. Their cause is not yet established.
Next diagnostic should check a full C record (primary and mirrors, expected event/id/caller/terminator) immediately after its writer and before panic. The success/failure result must be observable independently of the storage whose survival is under test. A print to a console that cannot be retrieved, or another flag only in the same alt region, would repeat the observability problem. A control-only two-phase arm/readback/trigger protocol can expose the record and status through adb before deliberately entering panic; document the changed timing and validate the actual immediate path subsequently. Keep normal FORTIFY failure behavior intact.
This establishes a narrower investigation: the writer plus normal recovery can work; a clean panic experiment still loses or fails to produce the record. Selective AES overwrite and a safe alternative offset remain unproven.
Follow-up: two-phase arm/readback/panic (same evening)
Artifact:
.local-artifacts/009-v4-twophase-x-then-c-20260927T191809Z/
Using existing v4 (no rebuild): SysRq-x → adb dump confirms eight
complete AXPDIAG1,X records → SysRq-c (latch no-ops C write; panic runs)
→ intermediate v4 (kernel_panic) → combo4.
Result: pre-verified X is absent at P3 and P4. Independent channel was adb, not alt-only flags. Timing caveat: adb RTT between arm and panic; type X not C. Narrow reading: fail-zone content verified before panic does not survive this panic/reboot path; soft recover without panic still preserves X.