[only21mil]

What and why

Follow-up to #490, as invited there: the Arch root on the phone has no
/dev/disk/by-partlabel, so the M0 commands in device/cheetah/MODEM-PLAN.md
(M0.1, M0.5) and device/cheetah/RADIOS-CAMERA-PLAN.md (1.6 M0.1) that found the
radio partitions through it don't work there. Each now finds its partition by
PARTNAME in /sys/class/block/*/uevent, with the same line FB1, F19.0 and
MODEM-PLAN M3.4.2 use. 1.6 lists the PARTNAME lines in place of the
by-partlabel symlinks, and its "take a fresh backup" note now points at
tools/nv-backup instead of a hand-written dd. No step does anything else
differently: the same partitions are read, and nothing is mounted or written.

Left as they were: MODEM-PLAN's M0 result note (2026-10-12), which records what
was run that day, and the comparison against the 2026-10-11 backup in both M0.1
steps. tools/nv-backup --check could replace the M0.1 loop, but it adds checks
the step doesn't make today, so that's left for the same follow-up as FB1.

Device and build

• Phone: none: docs only
• Kernel release (uname -r): n/a
• Packages changed, with versions: none

Checks (no phone needed)

• tools/pr-check origin/main passes
• tests/all passes
• tests/packages passes (or the packages I touched: none)
• Each changed package has its version bumped, and the new version is in the commit subject (no package changed)
• Commits have area prefixes and bodies that say why; any AI help is a Co-Authored-By: or Assisted-by: trailer, never a Signed-off-by:

On the phone

• I ran this on my own phone, booted into this build
• Runbook steps passed (plan, step, result): none run
• What I did not test: nothing ran on a phone. The changed snippets were checked with bash -n/sh -n, and the lookup against a fake sysfs.
• Nothing in this change writes outside slot B and userdata, weakens the storage guard, or reads registers from userspace (AGENTS.md §1)

🤖 Generated with Claude Code

[derekross]

Thanks, Victor, this is exactly the follow-up I asked for in #490. I checked the lookup: it's the same line FB1 and F19.0 already use, grep -x keeps efs from matching efs_backup, and the partition list matches the device descriptor's NV_PARTS, so pointing the fresh-backup note at tools/nv-backup is right too. The checks pass and it merges cleanly. I'll merge it as is.