Arch Linux LUKS setup on the Lenovo ThinkPad W541

I’m setting up my Thinkpad with Arch Linux and full-disk encryption.

Veracrypt

The first encryption method I look at is Veracrypt. During a job interview, a company asked me questions about Veracrypt. I didn’t know what it was. The interviewer told me it had this feature called “encrypted containers” that allowed to encrypt a specific set of files on a computer to keep them safe: ssh keys, password files, etc.

It also seems like with Veracrypt, as long as I have 1.5 times the used disk space, I can encrypt my entire disk without having to reinstall everything. That would save a lot of time. Unfortunately, I don’t have enough free disk space for that though.

So, I need to reinstall my system.

dm-crypt and LUKS

The Arch Linux wiki often gives good tips on how to do things “the Arch way”. What it recommends is not Veracrypt. Instead, searching “arch full disk encryption” yields this documentation about dm-crypt. The section named “Simple partition layout with LUKS” seems to be exactly what I need, no more, no less:

• data is protected in case of physical theft of the computer;
• easy to install;
• single pre-allocated disk partition.

Things that are possible with other dm-crypt setups but that I don’t need:

• possibility to change partition layouts;
• plausible deniability in case the computer is seized by the courts.

In addition, dm-crypt seems to be somewhat compatible with TPMs, which is a security feature my computer has. Maybe I can use that later if I choose dm-crypt now. So dm-crypt it is.

On YouTube, I find this tutorial that explains how to install Arch Linux with dm-crypt: https://www.youtube.com/watch?v=AQxk1uUQ-pQ.

Some things in this video are unknown to me.

First, the author talks about the filesystem btrfs. It looks like this filesystem has forward error correction of corrupted files.

Second, the author speaks about the role of the “hardware clock” that is configured with the hwclock command. A Google search tells me that this clock, contrary to the one Linux runs, keeps on going after I turn off the computer, so that when I boot it up again the next day, Linux can know what time it is without asking the internet. The hwclock man page tells me that the hardware clock is sometimes called CMOS clock. From what I remember, CMOS is the BIOS battery’s name. If that’s the case, then we can rely on it as it can apparently keep working for 6 years or more.

One more thing I learn in this video is the existence of the syslinux bootloader. Most tutorials on the internet talk about grub. It seems like the default bootloader when you want something that works fast without having to tweak a lot of settings. syslinux looks more lightweight and thus a little less powerful. But I don’t need all of grub’s features (custom filesystems, encrypted /boot partition, etc). So I do as the video author suggests and setup syslinux.

In the end, I do end up with a working system and full disk encryption, except for the boot partition. There are still a few errors that show up on boot. They don’t seem critical but should be looked at.

UEFI

One thing I notice with the previous install is that I used the legacy BIOS instead of the more modern UEFI. This works just fine in 99% cases because UEFI’s advantages seem aimed at enterprise uses, not so much PC use. But I like bleeding edge stuff so I decide to look for a way to reinstall in UEFI mode. As a side note, I later learn that UEFI is not only aimed at enterprise use cases but it the new de-facto standard for modern computers, so I’m glad to be using this now.

Once again, there is a good YouTube tutorial on installing Arch Linux with UEFI: https://www.youtube.com/watch?v=MMkST5IjSjY

In this tutorial, I discover yet another bootloader, systemd-boot. It looks similar to syslinux, but it comes pre-installed with systemd, which is the service manager in Arch Linux. This means that it will be on my system in all cases. I might as well just use it.

In deciding which bootloader to settle for, I found this schematic about boot loaders — released under the terms of the GNU FDL license — from the Arch wiki to be very helpful:

It would be interesting to use btrfs for the /boot partition to prevent file corruption. But I’d have to use syslinux for that, which means installing another software package. I’ll stick with systemd-boot and a vfat filesystem for the /boot partition. After finishing up the UEFI and systemd-boot installation, I reboot my computer.

PCCT error

Now comes to the time to fix the pesky errors that show up during boot. They are still there.

Looking for Error parsing PCC subspaces from PCCT on Google, I can see that I’m not alone in this. A Redditor suggests downgrading from the bleeding edge Linux kernel to the LTS (“Long Term Support”) version:

Have you tried rolling back the kernel or installing and running linux-lts? — monotykamary

The LTS kernel should be more stable so I try applying this piece of advice.

pacman -S linux-lts

And regenerate the ramdisk used during boot:

mkinitcpio -p linux-lts

Finally, I update the boot configuration in /boot/loader/entries/arch.conf so it looks like this:

title Arch Linux
linux /vmlinuz-linux-lts
initrd /intel-ucode.img
initrd /initramfs-linux-lts.img
options cryptdevice=/dev/sda2:root root=/dev/mapper/root rw

Now I reboot. And the errors are gone.

MMC error

There is another error that shows during boot, something like mmc0: Unknown controller version (3). You may experience problems. This is apparently a warning. That means there is no need to necessarily fix this now. But I don’t like seeing warnings every single time I boot my laptop.

A bug report on the Linux bug tracker suggests setting the debug_quirks option of the sdhci kernel module to 0x4. I try doing that by creating a file at /etc/modprobe.d/mmc.conf with the following content:

options sdhci debug_quirks2="0x4"

After regenerating the initramfs and rebooting, the error still shows up though.

Since I very rarely use the SD card slot, which is what mmc is here for, I decide to simply deactivate kernel modules related to memory cards in /etc/modprobe.d/mmc.conf:

blacklist mmc_core
blacklist sdhci_pci
blacklist sdhci

After calling mkinitcpio -p linux-lts and rebooting, all errors are gone. If I ever need the memory card slot, I’ll have to remember reactivating the kernel modules first.