Shinyspace

Arch boot on encrypted root

2026-02-09

Summary for booting Arch via Unified Kernel Image on an encrypted (LUKS) partition. For unattended booting we can plug in a usb stick with a keyfile. Reasoning at the end.

• Setup a proper EFI partiton according to archwiki, and a LUKS encrypted root partition
• Kernel command line pointing to LUKS partition and how to unlock it
• (specify in /etc/kernel/cmdline, mkinitcpio SHOULD automatically use that) rd.luks.name=UUID-of-LUKS-part=cryptroot rd.luks.key=UUID-of-LUKS-part=/keyfile:UUID=UUID-of-USB-stick-part root=/dev/mapper/cryptroot rw
• mkinitcpio preset: uncomment linux_uki parameters, comment unneded ones
• mkinitcpio preset: set linux_uki path to default: /efi/EFI/BOOT/BOOTx64.EFI
• (this is where the actual UKI image ends up and where UEFI mainboards look for it)
• mkinitcpio preset: add kernel cmdline options - supposed to automatic but doesnt
• default_options="--cmdline /etc/kernel/cmdline"
• mkinitcpio.conf: adjust hooks to use systemd and sd-encrypt, in my case: HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
• ensure /efi is the ESP (mount it) and the above path exists
• note: actual ESP mount point can be elsewhere. important is the path inside it for UEFI. i like it not being /boot because /boot gets kinda "cluttered" with stuff we don't actually need once the UKI works.
• mkinitcpio -p linux
• ensure your BOOTx64.EFI (the UKI we just build) exists at the correct location
• Your bios should now automatically boot from that!
• make sure your ESP is correctly mounted during updates (add the correct entry to fstab)

bonus point:

• on certain funny HP mainboards, you need to explicitly add a boot entry as such
• efibootmgr --create --disk /dev/nvme0n1 --part 1 --loader /EFI/BOOT/BOOTx64.EFI

quick summary of how to initialize the LUKS encryption:

cryptsetup luksFormat --type luks2 /dev/your-root-partition
<set passphrase>
cryptsetup --allow-discards --persistent open /dev/your-root-partition root
<enter passhrase>
mkfs.ext4 /dev/mapper/root
(root is just a name in the last 2 commands, can be anything)

random notes from archwiki: If you give the FAT file system a volume name (i.e. file system label), be sure to name it something other than EFI. That can trigger a bug in some firmwares (due to the volume name matching the EFI directory name) that will cause the firmware to act like the EFI directory does not exist.

random mistakes i made: after moving my ESP mount point from /boot to /efi, linux was gone (the file called vmlinuz-linux). it was in the ESP partition which changed place, and mkinitcpio was looking for it in /boot. I could have adjusted the path in mkinitcpio profile, but i actually like having the kernel on the encrypted drive, so i just ran pacman -S linux amd-ucode (ucode is in the same place).

i first tried to specify the LUKS partition's UUID in /etc/crypttab.initramfs because mkinitcpio (actually it's sd-crypt hook) will load that into the UKI automatically. But the syntax is different, and you do end up needing the "root=somepath" parameter in /etc/kernel/cmdline ANYWAY, so it was easier to just keep it all in one file, especially since if you change the name (above example "cryptroot") you need to change it in both places.

Reasoning: Skipping seperate bootloader install: Grub or other Bootloaders add an extra layer that can break, has to be maintained etc. They offer nice features (for example allowing you to select a previous system snapshot to boot) but I'd argue many people don't need them.

UEFI can boot Linux directly if things are set up properly, either via EFISTUB or via UKI (UKI just contains some extra resources in addition to the efistub).

In this tutorial i'll go for UKI because we can save another layer - the boot entries of your BIOS, since some mainboards can be weird about them. A unified kernel image in the correct path should be able to boot correctly with no boot entries.

Encryption + unattended boot: It's hard to securely erase SSDs due to block wear leveling and some firmware differences. If we encrypt every bit of data from the start, and store the key somewhere else (usb-stick, network service, or even in our head/password manager but that requires us to enter it each boot) we can later throw away the drive without worrying about someone recovering it.

My use case for this tutorial is a server (a mini-pc that runs 24/7 in my homelab) so it needs to be able to reboot even if i'm not physically next to it.