AsahiLocker 2.0.0 — a second supported environment, a hard refusal, and every M-series Mac on the record

The major is for what changed in the contract, not the size of the diff:

• Two environments are supported to run the encryption from, not one.
  A Fedora Asahi live USB, as before — or a second, minimal Asahi install on
  the same internal disk, for the many Apple Silicon machines that will not
  enumerate a USB stick in U-Boot at all. The script recognises which it is
  on, and the partition menus exclude the running system's devices outright.
• The system you are booted from cannot be selected as the target. There
  is 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 old
  behaviour — a LIVE prompt up front and an obscure umount / failure an
  hour later — is gone.
• docs/COMPATIBILITY.md states, machine by machine, what is verified,
  what is expected and what is not claimed. Laptops and desktops, M1 through
  M4. M4 is listed as not supported: the kernel ships its device trees, but
  Asahi does not boot it yet.

No existing encrypted volume is touched by any of this, and nothing needs
re-running.

Since 1.13.1: nine review findings, each reproduced before it was fixed

A full read of bin/, boot-guards/, extras/, tests/ and tools/. Five
of the nine were in the 1.13.0 second-install work; four predate it.

luks-deploy.sh

• The closing banner told the operator to copy the pre-luks state from
  /mnt after the run — but the EXIT trap has unmounted /mnt and closed the
  mapper by the time that banner is read, so the copy would have landed on the
  rescue install they were about to erase, and they would have deleted it
  believing the recovery material was safe. The script now makes that copy
  itself, while the target is still mounted, into the target's own /root;
  the banner says the recovery key still belongs on a USB stick, because a
  copy inside the volume it unlocks cannot help with a forgotten passphrase.
• RUNNING_DEVS was seeded from every mount on the box, so a target that
  udisks had automounted under /run/media — the documented live-desktop
  case — counted as "the running system": refused in every menu, with the
  unmount offer that exists for exactly that case never reached. Only the
  OS's own mountpoints count now.
• partition_number() read trailing digits, so a mapper's dm-1 was
  partition 1 and the BOOT/EFI neighbour bonus could go to an unrelated
  unlocked volume. It reads /sys/class/block/<p>/partition, which the kernel
  does not create for dm devices.
• The manual-entry branch accepted any block device on [ -b ] alone: a
  whole disk, or the ESP typed at the BOOT prompt, would have been mounted as
  /boot after the point of no return. It gets the same fstype check and
  confirmation as the menu path.
• A rescue system on a Thunderbolt or USB4 NVMe enclosure (TRAN=nvme,
  removable=0) was classed as a sibling install and walked through the
  SIBLING confirmation. TRAN in usb|thunderbolt|usb4, or HOTPLUG=1, is
  live media; Apple's internal NVMe reports HOTPLUG=0, checked.
• One block_slaves() helper where there were two hand-rolled /sys walks.

save-luks-recovery-bundle.sh — the same dm-name path bug 1.13.0 fixed in
the partition menu, in a third place: /dev/<dmname> does not exist, so every
LUKS volume sitting on LVM or RAID was silently left out of the bundle with
FAILS still 0. lsblk -rpno, as luks-tune.sh already did.

boot-guards/install.sh — the shipped unit's ConditionPathExists
hard-codes EFI/fedora while the installer detects the vendor directory, so on
any other ESP layout the guard was installed, enabled and inert: the timer
fired every minute and the service was skipped on the unmet condition. A
drop-in now points the unit at the stub that was actually found.

extras/bin/luks-fetch-cache — run unprivileged with a cache past
MAXAGE (a two-hour suspend does that; the timer's clock is monotonic) it
printed "no encrypted volumes detected" on a fully encrypted machine. Non-root
now shows the cache root wrote.

luks-fetch-cache reads its own layout

The fastfetch readout's continuation lines were indented by a constant, 17 —
the width of Disk Encryption: — with a comment asking that it be kept in
step with the config by hand. It now reads the config back: the calling user's
($SUDO_USER's through sudo), else the system one. The first module that
calls it supplies the key, keyWidth and separator that set the indent; the
number of such modules is the number of lines fastfetch will ask for, and with
more volumes than modules the last line carries (+N more) instead of
dropping them. The cache is stored unpadded and laid out for whoever reads it.
Rename the key or add lines freely; sudo in the module text is optional.

Testing that found a second unprivileged bug behind the one above: without
root, luksDump fails but the awk still printed a line — nvme0n1p6 LUKS , iters, — non-empty, so the stale-cache fallback never saw an empty sweep. A
dump that yields no version now yields no line.

Compatibility, all form factors

The shipped kernel (7.1.13-402.asahi, Fedora Asahi Remix 44) carries a device
tree for 37 Apple Silicon Macs. Nothing in the tooling reads the model: the
disk's sector size, the btrfs sectorsize, the initramfs contents and the power
supply are all read at run time, and Fedora Asahi's dracut ships the M1
(spi-hid-apple) and M2+ (dockchannel-hid) keyboard stacks in every image.

What a desktop changes, now written down: a Bluetooth keyboard cannot type the
passphrase and the initramfs check will still say OK; there is no battery to
ride out a mains dip, so use a UPS; check external display support before
encrypting on M3 and later; a Mac Pro's PCIe NVMe or a Thunderbolt enclosure
scores like the internal disk in the menu.

Also

• CI runs on aarch64 only; x86_64 in-place encryption is
  LinuxLocker's job.
• The README badge says M1–M3.
• Contributions from an end-to-end run on any machine in the C or D tier are
  what moves it up — see the last section of docs/COMPATIBILITY.md.

Upgrading: nothing to do. No existing volume is touched, no configuration
changes, nothing needs re-running. If you installed the boot guards on a
non-Fedora ESP layout, re-run boot-guards/install.sh once so the drop-in is
written and the stub guard actually runs.