AsahiLocker 1.13.0 — encrypting from a second Asahi install, for machines that will not boot USB

The live-USB route has always depended on something Apple Silicon is not
reliable about: U-Boot enumerating a USB mass storage device. The documented
fallback — a second, minimal Asahi install on the same internal disk — worked,
but the tooling did not know about it, and the one place that mattered got it
dangerously wrong.

This release comes almost entirely from a write-up of a real M3 MacBook Air
run by Noah Petherbridge ("Asahi Linux with LUKS
Encryption", 19 Sept 2026), who took that route and documented the parts that
did not go smoothly.

The bug it found (luks-deploy.sh)

"when it listed the various disk partitions on my Macbook, it wanted to
default to the AsahiRecovery partitions (the ones I was currently booted
from!)"

That is exactly what it did, and the cause is the situation itself. Candidate
partitions were penalised 200 points for sitting on the same disk as the
running system — correct on a live USB, where the USB is the one device you
must never pick. From a sibling install the target is on the same disk by
definition, so the penalty applied to both installs equally and cancelled
itself out. Two Fedora roots, both labelled fedora, both on NVMe: the score
tied, and the recommendation fell to whichever the kernel enumerated first.
On a layout where the rescue install sits between macOS and the daily driver,
that is the rescue install.

Nothing protected against acting on it, either. Selecting the running system
failed late and obscurely — an hour of prompts later, when umount / refused.

What it does now

• Every device the running system is on is off limits. All mounts and
  swap, followed through device-mapper to the backing partition, are marked
  IN USE in the menus: never the recommendation, not selectable by number,
  and refused when the device path is typed by hand.
• Targeting the running system is a hard stop, checked before anything is
  touched, with no override word. Re-encrypting the blocks under a mounted
  root can be neither finished nor undone, so there is nothing to consent to.
• The same-disk penalty applies only on live media. On a sibling install
  the running partitions are excluded individually instead, so the penalty
  can no longer rule out the right answer along with the wrong one.
• BOOT and EFI default to the neighbours of the chosen ROOT, since an
  Asahi install lays its three partitions down consecutively. The fstab
  cross-check still has the final say; this only stops the default being wrong.
• A root-vs-root tie breaks on size, so a 20 GiB rescue install stops
  outranking a 250 GiB daily driver when both answer to fedora.
• The LIVE prompt is gone. Running from an installed system is a
  recognised environment now, not an override. It prints the install you booted
  and the install about to be encrypted, one above the other, and asks for a
  typed SIBLING. LUKS_ACK_SIBLING=1 pre-acknowledges it for fleet use.
• The recovery material gets a warning it badly needed. On this route the
  header backup, the pre-encryption state and the recovery key land on the
  rescue install — which the operator then erases from macOS to reclaim the
  space. Said at the point of consent and again at the end of the run.

A device-mapper bug underneath it

Found while testing the above, and older than it. lsblk names a
device-mapper device by its dm name, and there is no /dev/<dmname> node —
only /dev/mapper/<dmname>. The menu built the former, so the path did not
exist, and blkid, blockdev and the in-use check all quietly did nothing
for that candidate. A rescue system whose own root is encrypted was therefore
offered its own container back as a target.

Tests

tests/multi-install-selection-test.sh builds a sparse, file-backed GPT disk
laid out like the real thing — two consecutive (EFI, boot, root) triplets, a
200 GiB daily driver and a 20 GiB rescue install, both labelled fedora — and
drives the real pick_partition() against it from the rescue install, from a
live USB and from the main install, plus the device-mapper case. 11 assertions,
run in CI on x86_64 and aarch64. The image is sparse, so the 230 GiB layout
costs a few MiB and no real disk is touched.

Documentation

• docs/SECOND-INSTALL.md — the route end to end: sizing and installing the
  minimal system, bringing it up (nmcli, dnf install git), what the new
  prompts mean, getting the recovery bundle off before you erase anything, and
  the diskutil cleanup with the Startup Disk change that has to come first.
• docs/LIVE-USB.md now leads its troubleshooting with usb start. A
  stick with no activity LED and nothing in bootflow scan -l is U-Boot's
  normal state before usb start — it does not power or enumerate the port
  until asked, and nothing asks on its own. That symptom reads exactly like a
  machine that cannot boot USB. There is also a new section on drive choice,
  because plenty of sticks build fine under Linux and are simply never visible
  to U-Boot.
• README: 1035 → 418 lines. The argon2id material moved to
  docs/CRYPTO.md and the questions to docs/FAQ.md; the parameter and
  profile tables and the case for aggressive stay on the front page.

Also

The logo lost the causeway leading into its base, sits on pure #000000 with
no bloom, and its wordmark is recut as white type.

Upgrading: nothing to do. No existing volume is touched, no configuration
changes, and nothing needs re-running. This is a change to how the deployment
script chooses and guards its target, plus documentation.