Removing Disk Encryption from EndeavourOS

Disk encryption wasn't worth the hassle of entering a password every boot, so I went about disabling it. Here's how.

State of the system

I'm using EndeavourOS, with systemd-boot as my bootloader rather than GRUB. I've not tested this setup under GRUB, and the configuration might be different there.

1. Decrypt the drive

I encrypted my drive by ticking the "Encrypt system" and entering a password during system installation. Unfortunately, this barely gave me any info on what actually happened to my system. It appears I got set up with a basic LUKS on a partition schema, using dm-crypt and LUKS1.

I booted into a recovery EndeavourOS USB, and the actual process of decryption was easy enough, after verifying it was using LUKS1 via cryptsetup luksDump /dev/sdXX. On a 512GB partition on an SSD it took a little less than an hour. However, the tricker part was knowing the correct next steps to follow.

2. Edit fstab

I landed on a plain, decrypted ext4 file system. I mounted it (and my EFI partition under it) before arch-chroot-ing into it. Taking a look at /etc/fstab:

# <device> <dir> <type> <options> <dump> <fsck>
[...]
/dev/mapper/luks-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4 defaults 0 1

Since the /dev/mapper/luks-XXX... no longer exists, this must now reference the unencrypted filesystem. Easy fix.

/dev/sdXX / ext4 defaults 0 1

Or alternatively, you can use the filesystem UUID from blkid (which is what I went with):

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4 defaults 0 1

Note that that UUID will NOT be the same as your luks-XXX... mapped filesystem.

3. Edit the kernel parameters

This is what got me the first couple of times. systemd-boot uses entries in /efi/loader/entries/ to know what to boot. I thought all I needed to do was to edit these entries and remove the references in the kernel parameters to the nonexistant LUKS filesystem. However, manually editing these entries is a bad idea, though, because if you ever update your kernel (and you will, on an Arch-based system), these entries get overwritten and your system will fail to boot, spinning endlessly for a LUKS filesystem that will never appear.

After a lot of running around and thinking that somehow my initramfs was misconfigured, I eventually stumbled upon the answer: Turns out, systemd-boot pulls kernel parameters from /etc/kernel/cmdline. That's what you actually need to edit. Pop open /etc/kernel/cmdline:

nvme_load=YES nowatchdog rw rd.luks.uuid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX root=/dev/mapper/luks-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Drop the rd.luks.uuid key entirely, and replace root= with a reference to your unencrypted filesystem:

nvme_load=YES nowatchdog rw root=/dev/sdXX

Likewise, you can also use a UUID here, but only if you have an initramfs that can parse them (EndeavourOS uses dracut by default, so this works):

nvme_load=YES nowatchdog rw root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

To apply changes, run reinstall-kernels while the EFI partition is mounted inside the chroot. Check that the boot entries in /efi/loader/entries/*.conf don't contain any references to your LUKS filesystem.

4. Edit crypttab

You're technically done, but you will get an annoying 90 second time out each boot as your initramfs (dracut under EndeavourOS, or mkinitcpio for vanilla Arch) tries to mount the encrypted filesystem(s) listed in /etc/crypttab. Open that up and comment out the relevant line with a #:

# <name> <device> <password> <options>
#luks-XXXXXXXX-[...]-XXXXXXXXXXXX UUID=XXXXXXXX-[...]-XXXXXXXXXXXX /crypto_keyfile.bin luks

Apply these changes with reinstall-kernels again, and after a reboot, you should have a clean, unencrypted system.