I’m setting up my Thinkpad with Arch Linux and full-disk encryption.
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.
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
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
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.
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.
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.
Now comes to the time to fix the pesky errors that show up during boot. They are still there.
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.
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
blacklist mmc_core blacklist sdhci_pci blacklist sdhci
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.