Which Apple Silicon Macs work: M1, M2 and M3 compatibility for AsahiLocker

Every M-series Mac, laptop and desktop, and what is actually known about AsahiLocker on each. Nothing in the tooling is model-specific — partitions, subvolumes, the boot layout, the disk's sector size and the initramfs contents are all read at run time — so the question is never "does the script know this Mac" but "does Fedora Asahi Remix boot it, and has anyone run the encryption there".

How to read the tiers

The device-tree column is a fact about the shipped kernel: on Fedora Asahi Remix 44, 7.1.13-402.asahi, /usr/lib/modules/<kver>/dtb/apple/ carries one file per machine below. A device tree is necessary for Linux to boot the machine; it is not proof that the installer, m1n1 or U-Boot are there yet.

The matrix

Model names are matched to the j-codes from Asahi's platform list. If a specific code matters to you, confirm it against /proc/device-tree/model on the machine.

What the tooling actually touches, and why none of it is model-specific

• Disk. Apple's internal NVMe presents 4096-byte logical sectors on every M-series Mac, which is what the 4096-byte LUKS sector logic is built around. The script reads the sector size and the btrfs sectorsize at run time and never assumes either.
• Keyboard at the passphrase prompt. Fedora Asahi's dracut ships the whole Apple input stack in every initramfs regardless of which Mac built it — spi-hid-apple + spi-apple (M1 laptops), dockchannel-hid (M2 and later laptops), hid-apple, dwc3-apple + xhci-plat-hcd (USB). Verified by lsinitrd on the M1 Pro above. The deploy's own dracut config adds only crypt dm btrfs and pins dm-crypt; it leaves input to the distro, and its verification pass checks that an input driver is present.
• Power. The battery check walks /sys/class/power_supply and applies only where a battery exists. On a desktop it finds none and moves on.
• Boot chain. m1n1 → U-Boot → GRUB, the ESP stub, ubootefi.var, BLS entries: identical across the line. The boot guards do not look at the model.

Desktops: read this before you start

The laptops are where this has been run. Desktops share every code path, but they change the operating conditions in ways the script cannot detect:

1. A Bluetooth keyboard cannot type the passphrase. There is no Bluetooth stack in the initramfs. An Apple Magic Keyboard paired over Bluetooth — the default on an iMac, and common on a Mac mini or Studio — is a brick wall at the LUKS prompt. Plug a keyboard in over USB (a Magic Keyboard on its charging cable enumerates as USB HID and works) before the first encrypted boot, and keep one within reach after. The deploy's initramfs check will report OK here, because the USB driver is present; it has no way to know your only keyboard is wireless.
2. No battery means no buffer. The script refuses to run on a laptop below 50% without AC because power loss mid-encryption is the worst case. A desktop has no battery at all: a mains dip is an instant interruption. The encryption is resumable — re-run the script and it finishes with --resume-only — but a UPS turns a recovery exercise into a non-event. Use one.
3. Have a display attached for the first encrypted boot. The prompt is on the console. A headless Mac mini or Studio can still be unlocked blind over a USB keyboard, but you want to see the first one. On M3 and later, external display support through DCP is still maturing in Asahi; check that your monitor works under Linux before encrypting, not after.
4. Extra disks score like the internal one. A Mac Pro with PCIe NVMe cards, or any Mac with a Thunderbolt NVMe enclosure, presents more than one nvme* device, and the partition menu's NVMe preference applies to all of them. The label scoring and the fstab cross-check still identify the right install; read the menu rather than pressing Enter on reflex.

Mac Pro (2023). Same M2 Ultra as the Mac Studio and the same device tree family; the differences are the PCIe slots and their contents. Nothing here cares, but nothing here has been run on one either.

What would move a machine up a tier

A run on any C or D machine, written up like the M2 Max entry in TESTED-SYSTEMS.md: the model string, the kernel, what the deploy reported for sector sizes, the ALL CHECKS PASSED line, and whether the passphrase prompt took keystrokes from the keyboard you actually use. Open an issue or a PR with it.

Tested systems

The machines behind the ✅ claims: every row here has had a real in-place encryption by luks-deploy.sh and boots from it, or an end-to-end run of the script on a disk image that was then booted — with what was found on the way. Nothing is listed on the strength of a dry run or a unit test alone. Same format as linux-backup-system's.

The loopback suite (tests/loopback-core-test.sh, 36 checks) runs on every push on aarch64 runners: shrink, in-place reencrypt with the script's exact flags, header and content survival, recovery-key enrolment with the AF hash pinned, resume after --init-only and after a hard kill (cryptsetup repair), 4096-byte sectors on a 4Kn and a 512-byte device, and the GPT-tail alignment run by the script's own function. It is not a boot.

← Back to the full guide: encrypt Fedora Asahi Remix with LUKS2, in place