These instructions are adapted from Pavel Kogan’s blog post for an encrypted hard drive. The main difference between that post
and this one is the different options. I will be setting this on a system with 32GB RAM, and I prefer a GPT partition table. Everything else should be the same. The usual Arch installation guide should be followed.
Don’t forget to do the initial steps before partitioning disks! Things like connecting to the network, and updating the system clock.
# BIOS partition, since all of the systems I'll be installing this in the immediate future are all BIOS, not EFI/UEFI
parted -s /dev/sda mklabel gpt mkpart bios 2048s 4096s
parted -s /dev/sda set 1 bios_grub on
parted -s /dev/sda mkpart lvm # Fill the rest of the disk
cryptsetup luksFormat /dev/sda2
cryptsetup luksOpen /dev/sda2 lvm
pvcreate /dev/mapper/lvm
vgcreate vg /dev/mapper/lvm
lvcreate -L 16G vg -n swap
lvcreate -L 50G vg -n root
lvcreate -l +100%FREE vg -n home
mkswap -L swap /dev/mapper/vg-swap
mkfs.ext4 /dev/mapper/vg-root
mkfs.ext4 /dev/mapper/vg-home
mount /dev/mapper/vg-root /mnt
mkdir /mnt/home
mount /dev/mapper/vg-home /mnt/home
mkswap /dev/mapper/vg-swap
swapon /dev/mapper/vg-swap
…then continue with the usual Arch installation. Don’t forget to add the “lvm2” and “encrypt” hooks to /etc/mkinitcpio.conf when you get to that part! And definitely don’t forget to add the following lines to /etc/default/grub:
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:lvm"
Then, run:
grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sda
I’ll post again once I’ve gone through this process, which I won’t be able to do for about a week. I will be going through it, modified, three times over the coming weeks, so I’ll really be able to stress it out and update any deficiencies.
Thoughts on this method
It works like a charm! The only hiccup is when booting GRUB prompts for the encrypted disk password, then the kernel asks for the same password when booting. The trouble with GRUB asking for it, if I mistype the password GRUB doesn’t prompt me a second time, and I’m dropped into the GRUB rescue shell (which isn’t self documenting). I will try this reddit thread which may be useful. The only other option is to reboot, and try again.
I guess the other problem is my BIOS is so slow! The RAID BIOS takes several seconds to boot. Also, decrypting GRUB and the disk takes a little longer than I’d like. Neither of these are problems with the method. None of these problems are showstoppers, since the only way to correct this is to replace the whole system. In any case, once the kernel begins to boot it takes less than two seconds before I’m at the GDM prompt! The power of dual-Xeon (8 cores), 32GB RAM, and an SSD (probably the biggest speed gain of all)!
I can already envision system replacing my NAS. I can attach up to 5 HDDs to the Marvell RAID controller, then leave them as discrete disks (JBOD) for use with Btrfs. Hopefully that filesystem will have matured enough to make it feasible (and reliable).
Further thoughts on this method
After a few weeks of using this, I ran into a major drawback to this scenario: if I am away from my house for an extended period, and my computer shuts down, I have to wait until I go back home before I can rectify it. As it stands, my power went out when I was away for the holidays, and it was nearly a week before I could go back and boot it up. It is unclear whether my Debian-based router would have booted back up fully, but that’s something entirely different. Thus, on my primary, fixed workstation, I have removed the encryption since I have at least one scenario where it would need to boot unattended.
I’ve kept this encryption method on my personal laptop, since that one always travels with me and is much easier to lose.
