Contents

Encrypted LVM

This is a new section added ~March 2013 to try and consolidate all the various info about creating an LUKS+LVM install, and also to clear up a lot of the confusion based around old and out of date wiki articles.
(WORK IN PROGRESS for the next few hours)

Keep in mind that this is DESTRUCTIVE and encrypting a drive will make any previous data unreadable! The following must be done on a fresh drive, or one where you don't mind losing the data (because backups!).

The following section will refer to your target hard drive as /dev/sdx. Be sure to change "sdx" to a proper target like /dev/sda. I will also assume this is a NEW Arch installation (complete with GPT and GRUB2).

I highly recommend reading through the LVM Wiki if you haven't already, and perhaps even playing inside a Virtual Machine before you start playing with your real data.

Please read through this whole document before you start running luksFormat!

Single-Disk

Encrypted LVM can be set up in 2 ways: LVM on LUKS, or LUKS on LVM. In a single-disk system, either is acceptable. However, IF YOU WISH to span your LVM across multiple drives in the future, you must use LUKS on LVM. (Explanation is below in the "Spanned" section).

In all cases, we must first clean the target drive and fill it with random data. This is to make our new encrypted partition blend in with the 'noise', and make it impossible to tell where the random data ends and where the LUKS container begins. The small frandom module is very quick at spitting out randomized data; much faster than /dev/urandom, which is helpful when we are dealing with 1TB+ size disks! We'll also use dcfldd, a small program that works exactly like dd, but is more verbose. Both these packages are from the AUR.

# yaourt -S frandom
# yaourt -S dcfldd

You can also use /dev/urandom if you would rather not install frandom.

# dcfldd if=/dev/frandom of=/dev/sdx

Wait for this to finish -- it might take a while depending on how large your disk is.

In this first case a LUKS encrypted blob is created directly at the partition level, and then an LVM system is placed inside of the blob. This config hides all information about the underlying partitions -- while the LUKS container is encrypted, the disk simply looks full of random data. Only when the container is decrypted can you see that there is in fact an LVM system inside. To set up this config:

NOTE: cryptsetup has a TON of options (which you can find in its man page). The defaults now are quite secure (aes-xts-plain64 with 256bit key), but you may change whatever settings you like here. Enter your password twice.

# cryptsetup luksOpen /dev/sdx3 lvm

Now we open our container. Your decrypted disk is now available at /dev/mapper/lvm

This is the opposite of above: your disk is partitioned openly, and each LVM section is visible. However, the contents of the LVMs are safely encrypted until unlocked. THIS IS THE REQUIRED CONFIGURATION IF YOU WISH TO ADD/SPAN MORE PHYSICAL DRIVES IN THE FUTURE.

Now continue through the Arch setup. (Pacstrap, arch-chroot /mnt, and so on. This HOWTO will assume you're also installing grub-bios to GPT as per the install guide.)
Be precise with the following edits!
IT IS CRITICAL, before exiting the install, that you modify GRUB2 and initcpio so that it will unlock your LUKS container on boot!

Edit /etc/mkinitcpio.conf, and change HOOKS=" " to include (order is important here):

A note about LUKS encryption keys: below we will be editing /etc/crypttab. This is necessary to unlock each non-root LUKS container (like /home, /media, etc) -- these logical volumes are just as important as /root, and if they are not visible the entire system will fail to boot! LVM must have all volumes present and accounted for.
Now, in order to avoid typing in multiple passwords (1 per container) every boot, we may generate some strong encryption keys and save them in /etc.
These keys are perfectly safe: they are being saved inside the root LVM container, which must be unlocked by you at boot with a password. As well, having different passwords for each disk makes breaking the encryption even more difficult -- even if one password is compromised, the LVM WILL NOT activate without the other partitions.