Installing Guix (Full LUKS + LVM)

Since I still needed a working machine in the meantime, I purchased a second drive. This way, if the installation fails for any reason— it did— I can switch back to a working "machine". But to be sure the new drive is in good working order, I tested it with badblocks:

badblocks -wsv -t 0xEF ${device}
badblocks -wsv -t 0XFE ${device}

This does two read-write, read DESTRUCTIVE, passes on the new device, checking for any errors.

Now for some, this is "enough" random scrubbing of the disk in preparation for an encrypted volume. However, I disagree. If the entire disk is a giant pattern of "0xFE" values, your actual data shines like a bright hot star for statistical analysis of the data.

The fastest (not to be confused with "best") way I have seen to randomly write garbage to a drive is to use a plain dm-crypt device with a random passphrase and write zeros to the resulting container.

cryptsetup open --type plain --key-file=/dev/urandom ${device} wipe-me
dd if=/dev/zero of=/dev/mapper/wipe-me bs=4096 status=progress
cryptsetup close

Also, critical for the throughput of the above command, setting the "blocksize" via bs=4096 dramatically improves the write speed.

Since the system uses a single device and we have a "fully encrypted" setup, we only need two partitions: first for the EFI System Partition (ESP) and second for the LUKS container.

I created this using the interactive prompts within gptdisk. Creating the first partition to be 128M at the default starting sector (2048), and the second taking the rest of the sectors. I denoted their partition types using the codes EF00, and 8308, respectively. Finally, I renamed them to something more meaningful to me: "boot" and "guix", respectively.

With a fully encrypted system, including /boot, there are some important limitations to keep in mind. As of this writing, GRUB does not support LUKS2 containers nor does it support the Argon2 key derivation function. Both of which are the default for recent versions of cryptsetup.

This is tricky because GRUB does claims to support LUKS2, however, I was unable to get this to work.

cryptsetup --type luks1 \
           --cipher aes-xts-plain64 \
           --key-size 512 \
           --hash sha512 \
           --iter-time 7680 \
           --use-random \
           --pbkdf=pbkdf2 \
           --verify-passphrase \
           luksFormat \
           ${device_part}

There are a few important notes here: first, the container type, as mentioned, should be LUKS1 type container; second, the PBKDF needs to be PBKDF2, otherwise GRUB does not know how to unlock it; third, make sure you replace ${device_part} with the appropriate partition. While the initial unlocking is quite slow because GRUB does not have full access to the machine, lowering the iteration count is not advisable for a "secure" machine.

Ensure it all works by opening the container:

cryptsetup open ${device_part} cryptroot

A new device should be available under the /dev/mapper tree.

Now, we can create the LVM containers for our partitions.

pvcreate /dev/mapper/cryptroot
vgcreate vg0 /dev/mapper/cryptroot
lvcreate -L 1G vg0 -n root
lvcreate -L 100G vg0 -n guix
lvcreate -L 100G vg0 -n nix
lvcreate -L 32G vg0 -n var
lvcreate -L 32G vg0 -n opt
lvcreate -L 32G vg0 -n tmp
lvcreate -L 64G vg0 -n swap
lvcreate -L 1T vg0 -n home

Since everything lives under /gnu/, the root partition really doesn't need to be even this large (I'm currently only using 18M on the root partition). However, Guix currently warns about this during the initialization phase. We can safely ignore this warning since we know the store writes go to a different partition. As I recall, this was not a warning before, requiring the root partition to be quite large for the initial installation.

Now that we have all the partitions and logical volumes created, we need to create actual "filesystems" for each. I have been using a combination of ext4 and xfs for a while, and it seems to work well. While you may be able to get away creating the ESP as an ext2 partition, it is probably easier and more widely supported to format it using Fat32.

Since version 5.15, xfs partitions default to including bigtime, avoiding the 2038 problem. Check back in 2486…

mkfs.vfat -F 32 -n boot ${ESP}
mkfs.ext4 -L root /dev/mapper/vg0-root
mkfs.ext4 -L var /dev/mapper/vg0-var
mkfs.ext4 -L opt /dev/mapper/vg0-opt
mkfs.ext4 -L tmp /dev/mapper/vg0-tmp
mkfs.xfs -L guix /dev/mapper/vg0-guix
mkfs.xfs -L nix /dev/mapper/vg0-nix
mkfs.xfs -L home /dev/mapper/vg0-home

Do not forget to format the swap volume:

mkswap /dev/mapper/vg0-swap

The penultimate step before turning over to the initialization step is to mount each of the partitions:

mount /dev/mapper/vg0-root /mnt
mkdir -p /mnt/{boot/efi,gnu,nix,opt,var,tmp,home}
mount ${ESP} /mnt/boot/efi/
mount /dev/mapper/vg0-guix /mnt/gnu
mount /dev/mapper/vg0-nix /mnt/nix
mount /dev/mapper/vg0-var /mnt/var
mount /dev/mapper/vg0-opt /mnt/opt
mount /dev/mapper/vg0-tmp /mnt/tmp
mount /dev/mapper/vg0-home /mnt/home

You can optionally enable the swap partition for the current live installation:

swapon /dev/mapper/vg0-swap