Arch Linux, Luks and the Thinkpad W541

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:

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

In addition, 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 dm-crypt.

On YouTube, there is a straightforward tutorial that helps with installing Arch Linux with dm-crypt:

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 syslinux.

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:

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.

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 & 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 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!

MMC error

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 /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.


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, syslinux and 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.

Thanks to Unsplash for providing quality images.