asahi-luks-setup

Add LUKS2 full-disk encryption to an existing Fedora Asahi Remix install on Apple Silicon, in place, without reinstalling.

It encrypts the btrfs root partition with cryptsetup reencrypt, run against the unmounted root. On this hardware you can reach an unmounted root two ways, so the tool supports two flows:

• In Asahi (native): drop to the dracut rd.break=pre-mount shell — prepare → reboot → encrypt → finalize.
• From macOS (offline): pass the Asahi root partition through to a hosted Linux VM and encrypt it there with asahi-luks-mac --offline, never touching the pre-mount console.

See Two flows at a glance to pick one. The in-place method itself is well known from the davidalger / coffeejunk gists — but every guide omits the failure modes that make a first attempt burn hours. This script encodes the correct sequence and the undocumented gotchas, both as comments and as runtime safeguards.

Status: community helper, and a deliberate stepping stone toward built-in installer encryption — see AsahiLinux/asahi-installer#137. The logic is structured so it could be lifted into the installer. A Python port is in progress at python/ (default-on, opt-out UX for the installer integration); see python/docs/installer-integration.md. A ready-to-apply MVP installer fork patch is at installer-fork-patch/ — adds the "Encrypt with LUKS2? (Y/n)" prompt to a fork of asahi-installer and stages the standalone tool + a first-boot login banner into the freshly-installed rootfs, so the user is walked through the standalone flow on first boot. An experimental Full Path v2 at installer-fork-patch/full/ collects the passphrase in the macOS installer and autoencrypts on first boot via a custom dracut module + two systemd units (untested on hardware; see installer-fork-patch/FULL_PATH.md).

Two directions (ROADMAP.md): A — folded into the installer (above); B — a lower-friction standalone, now including the one-command autoencrypt mode.

---

Three flows at a glance

	From macOS (offline VM) ✅	In Asahi: manual	In Asahi: autoencrypt ⚠️
You're booted in	macOS (on a dual-boot Mac)	Fedora Asahi	Fedora Asahi
Driver	asahi-luks-mac → a Linux VM running asahi-luks-setup --offline	asahi-luks-setup	asahi-luks-setup autoencrypt
Steps	asahi-luks-mac encrypt → reboot into Asahi → finalize	prepare → reboot to the pre-mount shell → encrypt → reboot → finalize	one command + reboot; hooks do the rest
Touches the early-boot console?	no	yes (the rd.break shell)	no
Hardware-validated end-to-end?	yes (Apple Silicon laptop + mini, 2026-05)	yes (laptop, 2026-05)	NO — last attempt left an unbootable mini
Best for	the recommended path: clean Alpine env, real chroot for grubby/dracut, output is right there in your terminal	conservative middle ground: keyboard-check fires before the irreversible step	low-friction in theory; experimental until the v0.1.1 fixes are re-validated

All three paths produce the same encrypted result, and all three finish with finalize (which the autoencrypt flow runs for you). The recommended flow is detailed in Running it from macOS; the native manual flow in How it works and Usage; the experimental autoencrypt in One command, hands-off.

---

⚠️ Before you run anything

• You can brick the install. Reencryption rewrites the entire root partition. Have a working backup, and stay on AC power for the whole encrypt step — power loss mid-write can leave the partition unrecoverable.
• Run --dry-run first and read every command it would execute (see below).
• What's been run on real hardware: the from-macOS offline encrypt and finalize have been exercised end-to-end on an M-series Mac (reencrypt → clean encrypted boot → SELinux relabel → finalize → enforcing). The in-Asahi prepare/rd.break/encrypt path is covered by --dry-run and unit tests. Treat your first run on a given machine as experimental and keep your backup.

---

Hard platform constraints

These are properties of the hardware/boot model, not choices. The script refuses to run if they are violated (override with --force only for off-target dry-run testing).

• Apple Silicon (M1/M2), AArch64. Boot chain: m1n1 → U-Boot → GRUB → kernel.
• No TPM, no Secure Enclave key escrow. Unlock is passphrase-only, prompted from the initramfs on every boot.
• USB boot is physically impossible on this hardware (Apple security design). Any guide step that says "boot a live USB and encrypt from there" is a dead end here. That leaves two ways to reach an unmounted root: the rd.break=pre-mount shell (the in-Asahi flow), or — on a dual-boot Mac — a Linux VM hosted under macOS with the root partition passed through (the from-macOS flow). This tool drives both.
• /boot (ext4) and EFI (vfat) stay unencrypted. Only the btrfs root partition is encrypted.

Reference partition layout

The btrfs root is detected at runtime (it is the backing device of /); it is never hardcoded. For reference, the development/test machine looks like:

nvme0n1p4  vfat   EFI - LINUX   -> /boot/efi   (unencrypted)
nvme0n1p5  ext4   BOOT          -> /boot       (unencrypted)
nvme0n1p6  btrfs  fedora        -> / and /home (TARGET; subvol=root, subvol=home)

If detection is ambiguous, the script aborts. You can force the target with --device /dev/nvmeXnYpZ if you are certain.

---

The four gotchas (the real value of this tool)

1. rhgb quiet MUST be stripped from the kernel cmdline when arming rd.break. Leaving them in causes the boot to land in the locked-root emergency screen ("Cannot open access to console, the root account is locked") instead of a usable interactive pre-mount shell. The script strips both rhgb and quiet whenever rd.break=pre-mount is active.

2. Fedora locks the root account by default, which is why the emergency shell can't authenticate. The pre-mount break shell is reached before the root filesystem (where any passwd root change lives) is mounted, so setting a root password on the running system does NOT help the break shell. The fix is gotcha #1 (clean console via stripping rhgb/quiet) so the interactive pre-mount shell comes up directly — not trying to log in as root.

3. SELinux relabel is mandatory after encryption or the system won't boot. The script adds enforcing=0 to the cmdline for the first post-encrypt boot AND runs touch /.autorelabel. finalize removes enforcing=0 after the relabel completes.

4. Early-boot console input is unreliable on Apple Silicon. This is first-class, not an afterthought. Before any irreversible step, the workflow verifies the keyboard works in the target shell. If input is flaky in the pre-mount shell, it will also be flaky at the LUKS passphrase prompt on every boot — which would lock the user out of their own disk. The script performs an explicit keyboard-check gate and refuses to proceed past it. (This gate is never auto-skipped, not even with --yes.)

---

How it works

Because the irreversible step happens where the root filesystem is not mounted, the work is split into phases, with a reboot between each. The table below is the in-Asahi (native) flow. The from-macOS flow reaches an unmounted root a different way — a Linux VM with the partition passed through — so it skips prepare/rd.break and runs encrypt --offline in the VM, then you boot Asahi once for finalize (see Running it from macOS).

phase	where it runs	what it does
prepare	normal Fedora	writes the dracut config (bakes cryptsetup + this script into the initramfs), arms rd.break=pre-mount with rhgb quiet stripped (gotchas #1/#2), rebuilds the initramfs, regenerates grub.
encrypt	the pre-mount shell	keyboard-check gate (gotcha #4) → shrink btrfs by 32M → cryptsetup reencrypt → unlock → mount + wire up /etc/crypttab, /etc/fstab, grub (rd.luks.name, enforcing=0) → sanity-check that crypttab/fstab/grub all agree, abort if not → set up the SELinux relabel (gotcha #3) → drop a "still need to finalize" login notice → disarm rd.break.
finalize	normal Fedora (post-relabel)	removes enforcing=0, restores rhgb quiet, removes the login notice, trims the dracut config, rebuilds the initramfs.
revert-arming	normal Fedora	backout: undoes prepare to return to a clean normal boot without encrypting.

Why both grubby and /etc/default/grub? On Fedora's BLS setup, editing /etc/default/grub + grub2-mkconfig does not change the args of the existing boot entries — those live in /boot/loader/entries/*.conf and are edited by grubby. The script drives grubby (authoritative for current entries) and keeps /etc/default/grub (and /etc/kernel/cmdline if present) in sync so the args survive a future kernel update, and regenerates grub.cfg. A wrong cmdline here is an unbootable machine, so this is belt-and-suspenders on purpose.

---

Requirements

• Fedora Asahi Remix on Apple Silicon, btrfs root (the standard install).
• cryptsetup ≥ 2.4 (LUKS2 online reencryption), dracut, grub2-tools (grubby, grub2-mkconfig), btrfs-progs — all present on a standard install.
• Root / sudo.

---

Usage

asahi-luks-setup [options] <command>

Commands:
  prepare         arm rd.break, stage the initramfs (normal system)
  encrypt         shrink + reencrypt + wire up (pre-mount shell)
  finalize        drop enforcing=0, restore quiet (normal system, post-relabel)
  autoencrypt     one-command low-friction path: arm + reboot, encrypts hands-off
  status          show detected device + current state (read-only)
  keyboard-check  run the gotcha-#4 console check on its own
  revert-arming   undo 'prepare' (also: --revert-arming)
  revert-autoencrypt  undo 'autoencrypt' before reboot (also: --revert-autoencrypt)

Options:
  --dry-run             print every command instead of running it
  -y, --yes             skip the YES confirmation (keyboard-check still runs)
  --force               bypass platform/context guards (testing only)
  --device <dev>        target this device instead of auto-detecting
  --mapper-name <name>  dm name for the unlocked root (default: luks-root)
  -h, --help            help
  --version             version

Full walk-through

# 0. Back up first. Plug in the charger.

# 1. Preview everything (executes nothing):
sudo ./asahi-luks-setup --dry-run prepare

# 2. Arm the pre-mount break + stage the initramfs:
sudo ./asahi-luks-setup prepare

# 3. Reboot. You land in a dracut PRE-MOUNT shell (a bare '#' prompt),
#    NOT the desktop. This is expected.
reboot

# 4. In that shell, run encrypt. It is staged at a stable path so you only
#    type one command. Invoke via 'bash' explicitly (initramfs PATH is minimal):
bash /usr/local/sbin/asahi-luks-setup encrypt
#    -> keyboard check, then it asks you to confirm (YES), then cryptsetup
#       prompts for the new passphrase twice, then it wires everything up.

# 5. Reboot. You will be prompted for the LUKS passphrase (see UX note below),
#    then SELinux relabels the whole disk and reboots itself once.
reboot

# 6. Back at the desktop, finalize (enforcing back on, quiet restored):
sudo ./asahi-luks-setup finalize

Boot-prompt UX note: the first decrypt prompt at boot may be buried in console output and look like a hang. Just start typing your passphrase (characters echo as ***), or press Enter to reprint the prompt.

One command, hands-off (autoencrypt) — ⚠️ experimental

Status: EXPERIMENTAL — known unbootable on at least one Apple Silicon Mac. The bash autoencrypt path's dracut pre-mount hook has been observed killing cryptsetup reencrypt mid-flight on real hardware (M2 Pro mini, 2026-05), leaving an unbootable half-encrypted volume. Root-cause is the initramfs environment (likely a kernel-crypto-module gap and/or a systemd timeout cancellation that wasn't loud about it) — fixes have landed (pipefail in the hook, signal traps, heartbeat persist_log, explicit instmods for the arm64 AES accelerators) but need a fresh hardware re-validation before this path is recommended. Until then, prefer the from-Mac flow for the actually-validated release path, or the manual prepare→encrypt→finalize flow if you want the from-Asahi experience without the auto-orchestration.

If you'd rather not babysit the pre-mount shell, autoencrypt collapses the manual flow into a single command plus reboots. It stages an auto-encrypt dracut hook + a finalize unit, and the machine encrypts itself across reboots:

# Back up first. Plug in the charger. Then:
sudo ./asahi-luks-setup autoencrypt
#   -> asks for the passphrase once, arms the hook + finalize unit, rebuilds the
#      initramfs. Then just reboot and walk away:
#        reboot -> encrypt (~15-30 min, "DO NOT POWER OFF") -> reboot
#        -> SELinux relabel -> reboot -> auto-finalize -> encrypted desktop.
reboot

Tradeoffs (why the manual flow stays the default): autoencrypt skips the gotcha-#4 keyboard-check (there's no interactive pre-mount shell to run it in, so a flaky early-boot console isn't caught before committing), and it stages the passphrase at /etc/asahi-luks-setup/passphrase (mode 0600, root-only) until the encrypt runs, then shreds it. If either matters to you, use the manual flow above. To un-arm before the first reboot: sudo ./asahi-luks-setup --revert-autoencrypt.

Diagnostic guarantees the v0.1.1 patches add, for when this path bites again: the hook now persists a forensic log to /var/log/asahi-luks-autoencrypt.log inside the encrypted root via a 30-second heartbeat (so even a hard kill leaves trail through the last checkpoint), uses set -o pipefail so encrypt-script failures don't get swallowed by tee, traps fatal signals to log them before exit, and writes a diagnostic preamble (cryptsetup version, loaded crypto modules, kernel cmdline) so future failure modes are debuggable from the log alone instead of needing a recovery VM. Recover the log via the asahi-luks-mac recover subcommand.

Reuses the same engine + dracut machinery as the installer "Full Path" — see ROADMAP.md for how the standalone and installer directions share one core.

Backing out

Before you have encrypted, if you want to bail and return to a normal boot:

sudo ./asahi-luks-setup --revert-arming

---

Running it from macOS (offline, via a Linux VM)

This is the from-macOS flow from Two flows at a glance. If your Asahi install shares an Apple Silicon Mac with macOS (the usual dual-boot), you can encrypt it offline from the macOS side without ever dropping to the pre-mount console. Apple Silicon forbids booting the bare metal from USB — but a hosted Linux VM under macOS gives back the classic "boot a live Linux and encrypt the disk" method: pass the Asahi btrfs-root partition through to the VM as a raw disk and run asahi-luks-setup --offline against it.

This is the power-user path. The safe default is still the in-Asahi flow above. The offline path does raw read/write to a partition on your internal boot disk from a VM — a wrong target can damage macOS or destroy data. Have a working backup, be on AC power, and run preflight first.

asahi-luks-mac (in this repo) is the macOS launcher. It identifies the target (largest "Linux Filesystem" partition), confirms it really is btrfs via the on-disk superblock magic, and assembles the QEMU command.

# 0. Back up. Plug in. Then look — read-only, no root:
./asahi-luks-mac preflight

# 1. One-time host tooling:
brew install qemu                       # qemu-system-aarch64 + edk2 firmware
#   plus an aarch64 Linux helper image with cryptsetup (>=2.4) + btrfs-progs
#   (e.g. a Fedora aarch64 cloud image). dracut/grubby are NOT needed in the
#   helper — they run inside the chroot from your Asahi root during wire-up.

# 2. Run the offline encrypt (needs sudo for raw disk access; irreversible):
sudo ./asahi-luks-mac encrypt --helper-image ~/fedora-aarch64.qcow2
#   -> launches QEMU with the Asahi partition as the 2nd virtio disk, then
#      inside the guest runs:
#         asahi-luks-setup --offline --device /dev/vdb encrypt
#      (shrink -> reencrypt [set passphrase] -> mount -> chroot wire-up ->
#       crypttab/fstab/grub/dracut/.autorelabel). --offline also strips
#       rhgb/quiet since no 'prepare' ran.

# 3. Reboot into Asahi (hold power -> startup options -> Fedora), enter the
#    passphrase, let it relabel, then:  sudo asahi-luks-setup finalize

Validated in a VM (against a throwaway image file — see tests/vm/): the offline path is proven end-to-end — macOS→QEMU passthrough, a real cryptsetup reencrypt, and the full asahi-luks-setup --offline wire-up (crypttab, fstab→/dev/mapper/luks-root, rd.luks.name+enforcing=0, .autorelabel) all pass, and the result re-opens with the passphrase. Only grubby/dracut were stubbed (they need a real Fedora root).

Confirmed on real hardware. The earlier worry — whether macOS would grant a userspace VM read/write to a partition on the live boot disk — is resolved: on an M-series MacBook, with sudo, QEMU opened the passthrough partition read-write, the full offline encrypt completed, and the disk then rebooted into Asahi and unlocked with the passphrase. (Raw access is root-only — disk0sN is root:operator, mode 0640 — which is why the real run needs sudo.) preflight still checks read access up front; if a future macOS tightens this, fall back to the in-Asahi flow.

---

Recovery

First encrypted boot can't find the LUKS device / drops to an emergency shell. Two common causes:

1. A UUID mismatch between the kernel cmdline and /etc/crypttab.
2. (from-macOS path) the mapper coming up as luks-<uuid> instead of luks-root, so /home (which fstab points at /dev/mapper/luks-root) fails to mount. The offline initramfs is generic (built in a VM that can't see the real hardware, so it carries no baked crypttab); the cmdline therefore names the mapper explicitly with rd.luks.name=<uuid>=luks-root — and the proper long-term fix is to rebuild the initramfs natively (see finalize).

From the emergency/dracut shell:

blkid -t TYPE=crypto_LUKS                 # find the LUKS partition + its UUID
cryptsetup luksUUID /dev/nvme0n1pX        # the canonical LUKS UUID
cat /etc/crypttab                         # should read: luks-root UUID=<that> none luks
cat /proc/cmdline                         # should contain rd.luks.name=<that>=luks-root

The UUIDs must match. To just get booted now: at the GRUB editor (press e) add rd.luks.name=<that>=luks-root to the linux line and boot (Ctrl-X). If /etc/crypttab is wrong, unlock manually, mount root, and fix it:

cryptsetup open /dev/nvme0n1pX luks-root
mount -o subvol=root /dev/mapper/luks-root /sysroot
# edit /sysroot/etc/crypttab so the UUID matches luksUUID above, then:
# (chroot and rerun grub2-mkconfig + dracut -f --regenerate-all if needed)

Interrupted reencryption. Just re-run encrypt. It inspects the partition's state and resumes automatically — a half-finished online reencryption is detected and continued with cryptsetup reencrypt --resume-only (re-enter the same passphrase you started with, since the keyslot is already bound to it). Re-running is always safe (see Idempotence below). If you'd rather resume by hand:

cryptsetup reencrypt --resume-only /dev/nvme0n1pX

Landed in the locked-root emergency screen ("the root account is locked") instead of an interactive shell. That is gotcha #1/#2: rhgb/quiet were not stripped. Boot the GRUB menu, press e, remove rhgb and quiet from the linux line, ensure rd.break=pre-mount is present, and boot (Ctrl-X).

Want to abandon before encrypting. sudo ./asahi-luks-setup --revert-arming restores a clean boot.

fstab safety. encrypt backs up /etc/fstab to /etc/fstab.asahi-luks.bak before repointing the root/home entries at /dev/mapper/luks-root, and aborts before reboot if the rewrite produced no mapper entry.

Half-encrypted unbootable mini (autoencrypt failure mode)

This is the failure we hit on a real Mac mini on 2026-05-23 and what motivated the v0.1.1 hardening + the from-Mac flow becoming the recommended path. Symptoms:

• You ran sudo ./asahi-luks-setup autoencrypt, rebooted, the long encrypt appeared to grind for a while, then the system rebooted itself, AND THEN dropped to a dracut emergency shell saying:

  Warning: /dev/disk/by-uuid/<your btrfs UUID> does not exist
  

• Holding the power button to get back to Asahi just lands at the same screen.
• The encrypted partition shows up as LUKS2 with a working passphrase if you unlock it from anywhere else, but its inner /etc/crypttab doesn't exist, /etc/fstab still has bare UUID=... entries (not /dev/mapper/luks-root), and the BLS entries on /boot carry no rd.luks.name= argument.

What happened, in plain English: the in-Asahi autoencrypt dracut pre-mount hook ran cryptsetup reencrypt on your live root partition, but the encrypt did not finish in the bare initramfs (cause varies: a kernel-side crypto module wasn't loaded, a systemd timeout fired on an unrelated unit, OOM, etc). Before v0.1.1 the hook's pipeline-through-tee swallowed the real exit code, so the hook reported "success" and rebooted — into an unbootable half-state.

Don't reinstall yet. Your data is intact inside the LUKS partition; the encrypt is restartable from its last checkpoint. The recovery is:

1. Boot the dual-boot Mac back into macOS (hold the power button → Loading startup options → pick Macintosh HD → Continue).
2. Copy/install asahi-luks-mac + its setup (this repo + QEMU + an aarch64 Alpine cloud image; see Running it from macOS).
3. Inside tmux, launch the recovery VM with the encrypted partition and its /boot (ext4) + /boot/efi (vfat) passed through:

   tmux new-session -s als
   sudo ./asahi-luks-mac \
     --helper-image ~/alts-vmtest/alpine-aarch64.qcow2 \
     --boot-device /dev/disk0sN \
     recover

   (Yes, tmux. The encrypt resume runs 15–30 min and an SSH drop / Mac sleep / Terminal crash will kill QEMU otherwise — see the next subsection.)
4. At the Alpine login (root/asahi), run the encrypt path. The script detects the partition state as INPROGRESS or LUKS2-but-not-wired and does the right thing — resume the data shuffle if needed, then run the full crypttab/fstab/grub/initramfs wire-up inside a proper chroot:

   bash /mnt/alts/asahi-luks-setup --offline --device /dev/vdb encrypt
   poweroff

5. Reboot the mini back into Asahi. LUKS prompt → SELinux relabel → desktop.

If cryptsetup refuses the resume with Device requires reencryption recovery. Run repair first., do exactly that first, then re-run the encrypt path:

cryptsetup repair /dev/vdb         # validates header, clears the recovery flag
bash /mnt/alts/asahi-luks-setup --offline --device /dev/vdb encrypt

Surviving an interruption during the from-Mac encrypt

The asahi-luks-mac encrypt (or recover → in-guest encrypt) path is a 15–30 minute QEMU + cryptsetup reencrypt. Any of these will kill QEMU and interrupt the encrypt:

• The Mac going to sleep (System Settings → Battery/Energy: set "turn display off" to Never, prevent automatic sleeping while encrypting)
• SSH session disconnecting if you're driving the Mac remotely
• The macOS Terminal app restarting (you'll see [Restored <timestamp>] appear at the top of the window — that means the previous session's processes are dead even though the window content was restored)
• /tmp getting cleaned (macOS periodically purges files there) — keep the Alpine helper image in ~/alts-vmtest/, not /tmp/alts-vmtest/

Always run the encrypt inside tmux on the Mac:

tmux new-session -s als
sudo ./asahi-luks-mac \
  --helper-image ~/alts-vmtest/alpine-aarch64.qcow2 \
  encrypt
# if your SSH dies / Mac restarts the Terminal, reconnect and:
tmux attach -t als

The reencrypt is fully resumable — LUKS2 writes checkpoints to its header continuously. Re-running encrypt after an interruption picks up at the last checkpoint:

# back in the same VM (or a fresh recover one):
bash /mnt/alts/asahi-luks-setup --offline --device /dev/vdb encrypt
# enter passphrase, type YES; resumes from the percentage shown

If the resume errors with Run repair first. (often happens after two back-to-back interruptions), run cryptsetup repair /dev/vdb once and retry.

Recovering the persist-log after an autoencrypt failure

The autoencrypt dracut hook persists a forensic log to /var/log/asahi-luks-autoencrypt.log inside the encrypted root via a 30- second heartbeat. If a future autoencrypt run leaves you with an unbootable mini again, don't reinstall first — recover the log so we can fix the underlying cause:

# from the dual-boot Mac's macOS side:
cd /path/to/asahi-luks-setup
sudo ./asahi-luks-mac recover \
  --helper-image /tmp/alts-vmtest/alpine-aarch64.qcow2

# inside the recovery VM (root/asahi), follow the printed recipe:
cryptsetup luksOpen /dev/vdb luks-root
mkdir -p /mnt/r && mount -o subvol=root /dev/mapper/luks-root /mnt/r
cat /mnt/r/var/log/asahi-luks-autoencrypt.log    # <-- the smoking gun

The log captures the diagnostic preamble (cryptsetup version, loaded crypto modules, kernel cmdline), every [asahi-luks-autoencrypt] step, the encrypt script's output, and — if the hook caught a signal before death — which signal killed it. File an issue with the log attached.

---

Idempotence & safety guards

• Re-running encrypt is always safe. It classifies the target at entry and picks the right resume point, so interrupting (even quitting mid-flight) and restarting is always a no-op, a resume, or a fresh run — never a wedged or double-applied state:
  • raw btrfs → full shrink + reencrypt (the shrink is a relative -32M, guarded by a precheck that skips it when the filesystem is already at least one header smaller than the partition, so it never double-shrinks on a re-run — and unlike an absolute target it leaves the slack cryptsetup's --encrypt data-shift needs);
  • LUKS2 with reencryption in progress → resume (--resume-only);
  • complete LUKS2 → skip straight to unlock + re-apply the wire-up idempotently;
  • anything else (LUKS1, a foreign filesystem) → bail loudly rather than guess.
• Ambiguous target? Detection refuses to guess; pass --device if you are sure.
• Any cryptsetup step errors? The script aborts before writing crypttab/fstab/grub, so it never points the bootloader at a half-encrypted device.
• Post-wire-up sanity check. After writing them, encrypt re-reads /etc/crypttab, /etc/fstab, and the grub cmdline and aborts if they don't all name the same mapper + LUKS UUID — catching a silent mismatch before the reboot instead of as an unbootable machine.
• Keyboard check fails? Hard stop. No irreversible step runs.

---

What this does not do

• It does not encrypt /boot or EFI (impossible/unsupported on this boot model) — only the btrfs root.
• It does not add a TPM/keyfile/escrow unlock (no secure hardware path on Apple Silicon yet) — passphrase only.
• It assumes the standard Fedora btrfs layout (/ on subvol=root, /home on subvol=home).

---

Contributing / relation to the installer

This exists to make in-place encryption reproducible today, and to give the Asahi installer a concrete, tested reference for a future built-in option (asahi-installer#137). Issues and PRs welcome — especially results from real M1/M2 hardware and other partition layouts.

License

MIT — see LICENSE.