Setting up the Thinkpad W541 with Arch Linux and full-disk encryption was a bit daunting. So I wrote down some notes during the process. Here they are.
This post might be useful to you if you have a W541 as well. And it will probably be useful to me when I need a new Thinkpad and want to install Arch Linux on it.
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 is 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.
So I thought, “hmm, I might need that to protect my keys too!”.
A feature that seems particularly interesting to me is encrypting the disk that is currently being used to run my oprating system. That means I wouldn’t have to reinstall my entire system. I like that because I am a lazy programmer.
But, unfortunately, it seems Veracrypt requires 1.5x the used disk space for the encryption to work. Probably because it copies files in the encrypted format before moving them. I don’t have enough free disk space for that though.
So, OK, I’ll just reinstall. And while I am at it, I’ll try setting up encryption with Arch Linux. I have used it before and have wanted to try using it again for some time.
dm-crypt and LUKS
Veracrypt is available on Linux, so I could encrypt files using that. However, the Arch Linux wiki often gives good tips on how to do things “the Arch way”, so let’s have a look at that first.
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 and I might want to use later.
So OK then, I’ll go with
On YouTube, there is a straightforward tutorial that helps with installing Arch Linux with
I have to say, I don’t understand everything the author is doing. So let’s dig in!
First thing I ignore is
btrfs which the author chooses as his filesystem. Looks like this filesystem has forward error correction of corrupted files. Wow! I need that too!
Second thing I ignore is the role of the “hardware clock” that is configured with the
hwclock command. A quick 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. Sweet!
Even better, the
hwclock man page tells me that the hardware clock is sometimes called CMOS clock. Wait, “CMOS”? That’s the BIOS’s battery’s name. If that’s the case, then we can rely on it: apparently, it can keep working for 6 years or more. Nice!
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 tweek 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, but there is no private data in there, so I don’t mind this getting stolen).
There are still a few errors that show up on boot, but I’ll fix those later. They don’t seem critical and I’d like to try a few other things first.
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.
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 is similar to
syslinux, but it comes pre-installed with
systemd, which is the service manager in Arch Linux. This means that whether or not I use
systemd-boot, it will be on my system. 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
After finishing up the UEFI &
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 fellow Redditor suggests simply 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’ll try applying this piece of advice. If the errors vanish, it’ll mean that the bleeding edge kernel was the cause.
Let’s install the LTS kernel:
pacman -S linux-lts
And regenerate the ramdisk used during boot:
mkinitcpio -p linux-lts
Finally, I’ll 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 can reboot.
Wow, the errors are gone. Awesome!
There is another error that shows during boot:
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.
I now have a good idea of what is possible in terms of disk encryption on Linux, both with Veracrypt and
dm-crypt. I’ve installed Arch Linux with a legacy BIOS and a UEFI bios. I’ve setup the system with 2 boot loaders,
systemd-boot. I was also able to correct some errors that appeared on boot. For some other errors, I had to revert to deactivating the kernel modules that were causing them. And finally, I now know what the
btrfs filesystem is good for and how the hardware clock works.
One thing I’d like to do in the future is make use of the TPM to further prevent malicious people from messing with my laptop. That’s a story for another day.