Encrypt Asahi Linux with LUKS2, in place: no reinstall

Why Asahi Linux needs this

Every mainstream Fedora installer offers to encrypt the disk. The Asahi installer does not: it installs Fedora Asahi Remix alongside macOS with a plain btrfs root, and adding LUKS has meant doing it yourself afterwards, by hand. On a laptop that is the gap that matters. A lost or stolen MacBook running Asahi gives anyone your home directory, your browser profiles and your SSH keys, with no passphrase in the way.

macOS on the same disk is protected by FileVault. Linux on that disk can be protected too. The difference is that Linux cannot use the Secure Enclave, so the protection has to come from a strong key-derivation function and a good passphrase. AsahiLocker is built around that.

Your options in 2026

There are three practical ways to get an encrypted Asahi system today:

1. Do it by hand. David Alger's 2023 guide is the original walkthrough, and Christian Horn's 2026 update covers what has changed since. Both are good reading if you want to understand every command. You boot a Fedora Asahi live USB, encrypt the root partition, then edit the boot configuration and rebuild the initramfs yourself.
2. Run a tool that does the same steps for you, with checks. That is what AsahiLocker is. It automates the hand-editing, then verifies the result before you reboot. The rest of this page covers it.
3. Wait for the installer. Encryption at install time has been requested of the Asahi installer for years. Until it ships, encrypting means doing it after install, by hand or with a tool.

What AsahiLocker does

• In-place btrfs → LUKS2 conversion. No reinstall, no backup-and-restore round trip, no second disk. Subvolumes, snapshots and the btrfs UUID survive; the partition simply gains an encryption layer.
• Every boot file rewritten, then verified. crypttab, fstab, /etc/kernel/cmdline, GRUB defaults, all BLS entries, dracut config and all initramfs images, behind a 12-point gate that refuses to let you reboot into a broken system.
• Pinned argon2id, never pbkdf2. AES-256-XTS with argon2id at 4, 2 or 1 GiB of memory per guess, benchmarked on your own machine before you choose. Every profile is stronger than cryptsetup's own default on that machine; the script checks that at run time and there is no flag to opt out.
• Resumable after any interruption. LUKS2 re-encryption is journaled. Lose power, close the lid, kill the terminal: re-run the script and it finishes the job.
• A --dry-run that really is dry. Detection, menus, fstab cross-checks and the KDF benchmark all run, and it prints the exact cryptsetup reencrypt command it would issue, then stops before changing anything.
• Recovery you can actually use. An optional 64-hex-character recovery key in a second keyslot, plus a labelled bundle containing the LUKS header and every changed config.
• Asahi-specific boot guards. One stops a stray grub2-mkconfig from overwriting the ESP stub and dropping you into grub rescue>. The other clears stale U-Boot EFI entries from ubootefi.var, the file they actually live in.

How the encrypted boot works on Apple Silicon

U-Boot provides the UEFI environment, and GRUB loads the kernel and initramfs from an unencrypted ext4 /boot. The initramfs reads rd.luks.uuid from the kernel command line, asks for your passphrase, runs argon2id, opens the LUKS2 container and mounts root. GRUB never has to unlock anything, which matters because GRUB 2.12 (current in Fedora 44) has no argon2 support at all.

nvme0n1
  p1  APFS    iBootSystemContainer
  p2  APFS    macOS            ← untouched
  p3  APFS
  p4  vfat    EFI   /boot/efi  ← stays plain
  p5  ext4    BOOT  /boot      ← stays plain
  p6  btrfs   fedora  / /home  ← becomes LUKS2(btrfs)
  p7  APFS    RecoveryOS

Partition numbers are detected at run time; that is just the common Asahi shape.

Before you start

• An installed Fedora Asahi Remix system with a btrfs root, a separate ext4 /boot and a vfat EFI partition. That is the standard layout; check with lsblk -f.
• A verified backup: one you have actually browsed or restored from. In-place re-encryption rewrites every sector of the root partition.
• Somewhere to run the encryption from. The script will not encrypt the filesystem it is booted from, and has no override for that. Use a Fedora Asahi live USB (a stock Fedora ISO will not boot on Apple Silicon) or, if your Mac will not boot USB, a second minimal Asahi install.
• The charger plugged in, and 15–60 minutes for the encryption itself (60–90 minutes all in).
• A passphrase you have chosen in advance and written down somewhere physically safe. There is no TPM on Apple Silicon: the passphrase, or the optional recovery key, is the only way in.

Step by step

1. Get the kit and build a live USB

   On your installed system, clone AsahiLocker and build a Fedora Asahi live USB with leifliddy/asahi-fedora-usb. build.sh erases the target device, so identify the stick carefully.

   git clone https://github.com/doug445/AsahiLocker.git
   
   sudo dnf install arch-install-scripts bubblewrap dosfstools e2fsprogs \
                    gdisk mkosi openssl pandoc rsync systemd-container
   git clone https://github.com/leifliddy/asahi-fedora-usb.git
   cd asahi-fedora-usb
   lsblk -o NAME,SIZE,TYPE,MODEL,VENDOR    # find your USB stick, NOT nvme0n1
   sudo su -                               # build.sh refuses to run under sudo
   ./build.sh -d /dev/sdX                  # ← your USB device

   Then copy the AsahiLocker folder onto the stick (./build.sh mount, copy into mnt_usb/root/, ./build.sh umount), so the script is not sitting on the filesystem it is about to encrypt. The live USB's root password is fedora.

2. Boot the live USB

   Easiest: with the stick plugged in, run this on the installed system, reboot, and pick the new GRUB entry.

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg

   That exact path, never the ESP one. On Asahi, /boot/efi/EFI/fedora/grub.cfg must stay a small chainload stub. Overwriting it drops an encrypted system into a GRUB rescue prompt.

   Or interrupt U-Boot ("Hit any key to stop autoboot") and boot it from the => prompt. If the stick does not show up, run usb start first. An unenumerated port is the usual reason a Mac looks like it "cannot boot USB".

   => usb start
   => bootflow scan -l
   => bootflow select <N>     # the usb0 entry, not nvme0
   => bootflow boot

3. Dry-run it, then encrypt

   From the live environment. The dry run shows everything it detected and the exact command it would run, and changes nothing:

   sudo /root/AsahiLocker/bin/luks-deploy.sh --dry-run
   sudo /root/AsahiLocker/bin/luks-deploy.sh

   The script auto-detects root, /boot and EFI, cross-checks them against the target's own fstab, offers a read-only btrfs check, benchmarks your Mac, and asks you to pick a KDF profile. It then shows a pre-flight summary. Read it, and type ENCRYPT to begin. Caps Lock is checked for you: an inverted passphrase verifies fine twice and only fails at the boot prompt.

   Encryption takes 15–60 minutes. Then come eight configuration steps and the 12-point gate. If any check fails it says so and refuses to declare success. Do not reboot until it passes.

4. First encrypted boot

   Reboot and remove the USB. The passphrase prompt often scrolls behind boot text. If the screen looks frozen just after GRUB, it is waiting for you: type the passphrase and press Enter. Unlock takes about 2–10 seconds depending on the profile.

5. Finish on the encrypted system

   sudo ./AsahiLocker/bin/post-encryption-setup.sh
   sudo ./AsahiLocker/boot-guards/install.sh

   This saves a recovery bundle, creates snapper subvolumes on the encrypted volume, restores the boot splash, and installs the two boot guards. Then copy the recovery bundle off the machine. On the drive it protects, it is no use to you.

6. Verify

   lsblk -f | grep crypt
   sudo cryptsetup luksDump /dev/nvme0n1p6   # PBKDF: argon2id, AF hash: sha512
   grep rd.luks /boot/loader/entries/*.conf
   systemctl --failed

Something went wrong? Nothing is lost yet. The recovery guide starts with a table: what you see, what state that means, and what to do. It covers an interrupted encryption, a box that will not boot, SELinux denials, a damaged header and a grub rescue> prompt.

Choosing an argon2id profile

The key-derivation function runs once at every boot, and once per guess for anyone attacking a copy of your disk. argon2id is memory-hard: every guess needs gigabytes of RAM, and that memory requirement limits how many guesses a GPU or ASIC can run at once. The installer benchmarks your machine and shows an estimate for each profile:

All three use 4 threads, AES-256-XTS and sha512. All three are safe on any Asahi-supported Mac, including an 8 GB M1, because the memory only has to be allocatable in the initramfs. You can re-cost a keyslot later without re-encrypting anything, using bin/luks-tune.sh. The full reasoning is in CRYPTO.md, including how this compares with FileVault's KDF on the same disk.

Manual encryption vs AsahiLocker

Which Macs

Every M-series Mac that Fedora Asahi Remix boots, laptop or desktop: MacBook Air and Pro, Mac mini, Mac Studio, iMac and the 2023 Mac Pro, across M1, M2 and M3. Nothing in the tooling is model-specific; partitions, sector size and initramfs contents are all read at run time.

• Verified in production: MacBook Pro 16" M1 Pro and MacBook Pro 14" M2 Max, both encrypted in place and unlocked at every boot.
• Reported working: M3 MacBook Air, via the second-install route (Noah Petherbridge's write-up).
• Not claimed: M4. The kernel ships its device trees, but Asahi does not boot it yet.

Desktop owners should read the compatibility notes first: a Bluetooth keyboard cannot type the passphrase at boot.

Risks: read these

• No TPM on Apple Silicon. You type the passphrase at every boot. That is the platform, not a limitation of the tool.
• Forget the passphrase and the data is gone, unless you enrolled the recovery key and can still find it. There is no backdoor.
• Have a verified backup. Re-encryption rewrites every sector of the root partition.
• LUKS protects data at rest, not boot integrity. /boot is unencrypted and unsigned; an attacker with repeated physical access could tamper with the initramfs.
• You cannot brick the Mac. macOS lives on APFS partitions this tool never touches, and Apple Silicon DFU and System Recovery always work.
• This is unofficial. It is not part of, or supported by, Asahi Linux or the Fedora Project. Please do not take problems with it to their trackers; open an AsahiLocker issue instead.

Frequently asked questions

Credits and further reading

• Fedora Asahi Remix on Apple Silicon with LUKS encryption, David Alger (2023): the manual method, and where most people started.
• Fedora Asahi Remix with LUKS encryption in 2026, Christian Horn: the manual method, updated.
• Asahi Linux with LUKS Encryption, Noah Petherbridge (September 2026): a real end-to-end AsahiLocker run on an M3 MacBook Air. AsahiLocker's second-install route came out of it.
• asahi-fedora-usb, Leif Liddy: the live USB builder this guide uses.
• Asahi Linux: the project that makes any of this possible.