DEV Community: Zoe

Installing Arch Linux on BTRFS with LUKS and automatic TPM2 unlocking

Zoe — Sat, 27 Dec 2025 04:21:16 +0000

I recently got a new laptop, and figured I'd install Arch on it, just to have a functional system asap. Now that I have more time to tinker however, I have decided to re-install to get full disk encryption¹. That's what this blog post is!

[NOTE]
This isn't a guide per say. This is simply my own experience with the setup, and it's the first time I've ever done this so there are likely to be issues. Regardless: Maybe you'll learn something!

Usually I wouldn't go for full encryption, however I chose encryption here for a few reasons:

As a challenge to myself, and to learn new technologies
The changing political climates and my status as a minority in more ways than one unfortunately result in me being more likely to be targeted by various actors, state or otherwise, and I figure I need to protect my privacy better.

BTRFS configuration

Before setting up the system I'll pre-plan the BTRFS subvolumes I'll be using and the options I'll be applying to each of these, to simplify later setup. This is taken a lot from Jordan Williams' post on Btrfs subvolumes, so I recommend going there if you want to replicate this yourself.

All volumes are mounted with the options defaults,noatime,autodefrag,ssd,compress=lzo,commit=30 unless otherwise specified.

Subvol name	Mount path	Flags	Rationale
`root`	`/`
`snapshots`	`/.snapshots`		Having snapshots separated is highly recommended to avoid a snapshot-within-snapshot situation
`home`	`/home`		Some people also recommend having a separate subvol for each user, however for my laptop there's only one user: me. So I stick to only having `/home` be its own subvolume.
`opt`	`/opt`		A lot of third-party apps are installed here, and we don't want those to be uninstalled in case of a rootfs rollback
`srv`	`/srv`		Similar reason to `opt`, as well as this being a mountpoint for other drives. Don't wanna take snapshots of everything here
`swap`	`/swap`	Remove `compress` option	Swapfile
`usr_local`	`/usr/local`		Similar reason to `opt`
`podman`	`/var/lib/containers`	`nodatacow`	Podman images are stored here
`docker`	`/var/lib/docker`	`nodatacow`	Docker images are stored here
`libvirt`	`/var/lib/libvirt/images`	`nodatacow`	Libvirt (qemu, virt-manager) stores data here

Using lzo encryption won't save me a lot of storage space, however it does have the highest transfer speeds out of the three available (ZLIB, LZO, ZSTD) according to a test by TheLinuxCode. With me having a 2TB drive, sacrificing some compression in favor of speed is therefore acceptable.

Secure boot keys

As I already had a configured system with UKI and secure boot-signed images, I made sure to make a copy of the existing secureboot private key and certificates from /etc/kernel/secure-boot-private-key.pem and secure-boot-certificate.pem. These were previously generated with ukify genkey following the guide for secure boot with systemd on the Arch Wiki. Later on, when setting up image signing, these will need to be put back in place.

Installation

Before starting the install itself, I boot into my regular arch install to shrink the existing BTRFS partition down to roughly 500G, giving me ~1.5T to install the encrypted OS on: btrfs filesystem resize 500G /

Following that, installation starts off as usual. I download the latest Arch ISO, boot it, configure the keyboard, network, etc. All the usual stuff, including opening a tmux session (because not having scrollback is annoying).

Partitions

First things first, I opened /dev/nvme0n1 with fdisk. Since the BTRFS data has been shrunk to 500G already, I can shrink the partition to match and create a new partition following it for the new installation. Once this has been configured as a linux root partition, I write and close fdisk.

After setting up the partition, I configure it with crypttab. I pre-generated a passphrase to use through Bitwarden's passphrase generator, and input that when prompted:

cryptsetup luksFormat \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --hash sha256 \
  --iter-time 2000 \
  --key-size 256 \
  --pbkdf argon2id \
  --use-urandom \
  --verify-passphrase \
  /dev/nvme0n1p3

Running this sets up encryption on the partition, requiring it to be opened with cryptsetup before any further configuration can be made. This will also require the password generated earlier:

cryptsetup open /dev/nvme0n1p3 root

This will create a device mapper on /dev/mapper/root, allowing the decrypted partition to be interacted with like any other. This gets followed up with creating a fresh BTRFS filesystem, which I mount at /mnt:

mkfs.btrfs /dev/mapper/root
mount /dev/mapper/root /mnt

I can then create the subvolumes defined earlier, by running the following command with each of the volumes:

btrfs subvolume create /mnt/@$NAME

Then the root-volume gets unmounted, and I mount each of the subvolumes to their correct locations, putting in or removing the appropriate options as required:

umount /mnt
mount --mkdir /dev/mapper/root /mnt/$MOUNTPOINT -o defaults,noatime,autodefrag,ssd,compress=lzo,commit=30,subvol=@$NAME

Meaning of each option

defaults: Default mount options from the mount.btrfs command? Honestly a bit unsure

noatime: Disables access time recording, see writeups on reddit and LWM (lwm)

autodefrag: Small writes (64kb) are automatically queued for defrag? Again, not completely sure about the full effect from this, it is used in Jordan William's post linked to earlier

ssd: Enables some smaller optimizations (StackExchange)

compress = Sets compression algorithm to use

commit = Sets how often periodic flushing to permanent storage should be performed

subvol: Tells btrfs what subvol to mount

This is followed up with creating and mounting a swapfile using BTRFS' filesystem mkswapfile command:

btrfs filesystem mkswapfile /mnt/swap/swapfile --size 40G --uuid clear
swapon /mnt/swap/swapfile

And mounting the EFI partition of course:

mount /dev/nvme0n1p1 /mnt/boot --mkdir

Base setup

After setting up all the partitions, I simply set up the system like any other:

# Generate new mirrorlist
reflector --save /etc/pacman.d/mirrorlist --protocol http,https --country Norway,Sweden,France,Germany,Finland,Iceland,US --latest 250 --sort score --ipv4 --threads 4 --fastest 50 --age 6


# Install base packages
# Further hyprland addons (like hyprshot, hyprpicker, various xdg-desktop-portals, etc are installed in the post-install section)
pacstrap -K /mnt base linux linux-firmware-amdgpu linux-firmware-mediatek systemd-ukify uwsm tmux kate zsh git sudo vim amd-ucode networkmanager btrfs-progs hyprland rofi dolphin man-db greetd-tuigreet fprintd efibootmgr alacritty base-devel

# Generate an initial fstab
genfstab -U /mnt >> /mnt/etc/fstab

After installing the base packages I chrooted into the system with arch-chroot /mnt. Any commands after here are in the chroot unless otherwise specified.

In the chroot, I do some other post-config:

Setup locales: vim /etc/locale.gen + locale-gen + /etc/locale.conf + localectl set-locale
Setup keymap: /etc/vconsole.conf + localectl set-keymap
Setup hostname: /etc/hostname + hostnamectl hostname
Setup hosts file: /etc/hosts

Mkinitcpio

Arch uses mkinitcpio to generate the kernel and initramfs images by default, so I'll just keep using it for simplicity's sake. I could've used an alternative like dracut, but meh. Mkinitcpio works.

There are a few options I need to configure for mkinitcpio to

Have the required modules to boot the encrypted-signed image
Generate a UKI
Sign the generated image for secure boot

First task is configuring mkinitcpio to have the required modules for my desired setup. Editing the configuration file, I make it look something like this:

MODULES=(btrfs tpm_crb)
BINARIES=(/usr/bin/btrfs)
FILES=()
HOOKS=(systemd autodetect microcode modconf kms keyboard sd-vconsole sd-encrypt block filesystems)
COMPRESSION="lz4"
COMPRESSION_OPTIONS=(-9)

This enables btrfs on root, sets up unlocking encryption through systemd, and increases compression ratio to around 2.5 while preserving the fastest decryption speeds (Mkinitcpio#COMPRESSION on the Arch Wiki).

Second is the UKI. For this, I installed systemd-ukify during pacstrap, which includes the ukify binary used by mkinitcpio. In the /etc/mkinitcpio.d/linux.preset file, I uncomment the default_uki, default_options, fallback_uki, and fallback_options lines, and comment out the default_image and fallback_image options. I then put in the correct paths in the default_uki and fallback_uki lines (in my case /boot/EFI/Linux/arch-linux.efi and arch-linux-fallback.efi).

Uncommenting these options tells mkinitcpio to generate a unified image instead of a separate kernel and initramfs. It can also be configured to automatically sign the generated image for secure boot, leading me into the final task of actually signing the images.

As mentioned in Secure boot keys, I took a copy of the secure boot keys. I'll copy these over into the new system, making sure to set up /etc/kernel/uki.conf in the process. I'll need to set the SecureBootSigningTool to systemd-sbsign, and SecureBootPrivateKey + SecureBootCertificate to their appropriate files. SignKernel must also be set to true. Once this is done, ukify signs its generated images.

cmdline

Finally, I need to set up the cmdline. When using signed UKIs, the system cannot load boot options through the regular /boot/loader/entries files, as these can be tampered with. Instead the options are built in to the image itself, ensuring they are secure from tampering.

For my cmdline files I had a few requirements:

The LUKS partition must be set as the root partition, and discovered for decryption
The decrypted root partition must be properly mounted as BTRFS partitions from /etc/fstab
Minor tuning must be done

For the first and second ones, the Arch wiki is a good resource. By following Dm-crypt/System configuration, I set up:

rd.luks.name=UUID=root
# For later TPM2 unlocking
rd.luks.options=UUID=tpm2-device=auto

root=/dev/mapper/root
rootfstype=btrfs
rootflags=subvol=@
rw

The tuning I've gone into in another post, so I'll avoid putting it here :3

Signing the bootloader

So far I've only set up signing of the images themselves (which can technically be booted directly), however if I want to ever use a bootloader for multiple OSes or kernels I'll have to sign it too (less I disable secure boot every time, which isn't particularly favorable).

For pacman, this is luckily decently simple. I'll need to install two hooks to /etc/pacman.d/hooks/:

80-sign-systemd-boot.hook - As the name implies, this hook signs the systemd-boot efi binary.
95-update-systemd-boot.hook - This restarts the systemd-boot updater, ensuring the new version of the binary is put into place immediately

For simplicity's sake I've just uploaded the full files for download instead of putting them into the post itself.

I'll also make sure to reinstall systemd to make both hooks run once, so the binary gets signed and put into place: sudo pacman -S systemd

Misc last touches

Before having a usable system, I'll need to configure a few smaller things:

Greeter

Enable and create cache dir for remembering the last used session

systemctl enable greetd
mkdir /var/cache/tuigreet
chown greeter:greeter /var/cache/tuigreet
chmod 0755 /var/cache/tuigreet

Select the greeter to use by editing /etc/greetd/config.toml:

command = "tuigreet --time --remember --remember-user-session --user-menu --user-menu-min-uid 1000 --asterisks --cmd 'uwsm start hyprland-uwsm.desktop'"

Once this is all completed: Reboot time!

Post-install configuration

Now, this is where the actual TPM2 unlocking part comes into place. I'll skip all the boring "copy old home dir and struggle for 2 hours to configure dotfiles and install programs" stuff, and only focus on LUKS and TPM2 here.

Keys

Once booted into the system I changed the boot order using efibootmgr to ensure sd-boot was first. Then I went into /boot/loader/loader.conf, and set secure-boot-enroll force. This makes sd-boot enroll the keys I copied over earlier, which I in all honesty don't know how got there (see /boot/loader/keys/auto). They kinda just appeared and I rolled with it.

Then I reboot and ensure:

The old keys are removed, leaving no secure boot keys at all
Secure boot enforcement is disabled

When sd-boot then loads it gives a message about keys being enrolled, which I don't interrupt. The system then reboots again, and I can re-activate secure boot. With the signed kernel I should then be put to the password prompt correctly.

TPM2

First things first: Creating a recovery key using systemd-cryptenroll. This is essentially a long, easy to type, securely generated password. The command outputs a long string which should be written down someplace safe in case everything else fails:

systemd-cryptenroll /dev/nvme0n1p3 --recovery-key

Next, I enrolled the TPM2 itself in the LUKS volume, again with systemd-cryptenroll:

systemd-cryptenroll /dev/nvme0n1p3 --tpm2-device=auto --tpm2-pcrs=7+15:sha256=<64-zeroes>

Why 64 zeroes? Can't explain it myself, the Arch Wiki does a much better job. TLDR: Something about ensuring a TPM measurement is empty.

Acknowledgements

While setting up my own system I leaned heavily on a few other blogs, namely:

There is also an almost 100% chance that this won't work properly. I have gone back and forth a bunch to set up my own laptop, a lot of which I unfortunately managed to forget to write down. Hopefully it helps somewhat at least!

Technically I'm not using full encryption here, as I am only encrypting the main data partition of the device and not the boot partition, however because I am signing the kernel and creating a unified image I deemed this an acceptable risk. ↩

My experience installing Nix OS

Zoe — Sat, 27 Dec 2025 04:18:32 +0000

After some friends of mine started using and recommending NixOS to me I eventually got tempted enough by the sweet, sweet reproducibility and git-managed system that I decided to give it a try.

At first, I wasn't a massive fan. Configurations were archaic, the nix configuration language had some... quirks (?) that I weren't a big fan of (more on that at #Nix language quirks, and configuring flakes for git-managed configurations wasn't exactly intuitive.

Later though, I did start getting a bit used to the system. A lot of that was thanks to my friend Soni who helped me for hours on end with setting up the system, and answered every question I annoyed him with in our DMs. Thanks a lot :3

To put the TLDR at the start: I am likely not gonna be switching to Nix full time. It's good, just not quite for me. More on that at the end.

Installation process

First of all, there's the installation process. Now, this was likely mostly an issue with my machine, but for some unknown reason WiFi was absolutely refusing to connect, whether I was using the Minimal or Graphical installer, and regardless of environment in the Graphical installer. This caused me about an hour of pain with trying, restarting, retrying, and repeat. In the end I just plugged the machine in with a cable, and that solved my issues, but not a "good" first experience at least.

Next, the installer itself was being kinda annoying. There was no ability to shrink my existing LUKS partition to make space for installing Nix itself, so I had to use GParted for this. That itself is fine, as shrinking a LUKS partition is decently niche. But when I then did shrink the partition to make space, the installer never refreshed the partition selection, forcing me to restart the installer completely. Again: Niche is, but a small annoyance either way.

Finally, and I noticed this only after the installation itself, it overwrote my systemd-boot config completely and changed the EFI parameters to ensure Nix was booted first instead of using the existing sd-boot entry and config. As I had customized my loader.conf a decent amount, this was kinda annoying. Nothing I couldn't fix, but another small annoyance. As I was quick to notice, there were a lot of those.

Nix language quirks

The Nix language itself is very good, I like it quite a lot. However, some small things kinda got to me.

First: The fact that there is a semicolon between with pkgs and an array. To me, coming from other languages (and even from the nix language itself), this seems incorrect. To me, a semicolon indicates "end of this statement", so in Nix' case "end of this variable or definition". It was not logical to me that in this case only, the statement continued after the semicolon. Once I got used to this it was no issue at all.

# How it is:
packages = with pkgs; [
  ...
];

# How it makes intuitive sense for me:
packages = with pkgs [
  ...
];

Second, and this is more a nitpick than anything: Indents and bracketing. Why does nixfmt insist on this pattern (pseudocode):

services.openssh =
  {
    enabled = true;
  };

instead of

services.openssh = {
  enabled = true;
};

Again: Preference, doesn't at all matter for the operation of the system, but just tiny nitpicks. I don't have to use nixfmt at all.

The good

Now for a change of pace: Some good things and things I liked with Nix!

First: I absolutely LOVE the declarative configuration. I am absolutely a fan of being able to define "I want foo, bar, and baz" and have only that be installed, and if I remove anything from that list, it gets removed automatically. I am ABSOLUTELY a fan of that, not a question about it.

Further: I love the ability to, with a tiny bit of config, have different setups for different machines while being able to share base configurations. Being able to add nixosConfigurations and run nixos-rebuild switch --flake .#hostname to have my desired configuration for my exact system: Absolutely love it. That is exactly what other dotfile managers and config managers should strive to be.

The bad

Now: Back to some more complaining (unfortunately). NixOS' lack of following the FHS absolutely made the transition to Nix more difficult for me. Trying to find config files for programs and services (or really any files at all) was made incredibly difficult. I essentially needed to throw away everything I knew and start completely anew (which I guess is kinda the whole point of immutable systems?)

This leads me into my second main problem: The documentation is... something. Configuration documentation is seemingly spread across 10 different websites, all of which having something the others don't have. The nix wiki is a good starting point and a good resource for basic configuration, but the second I needed anything else I found myself digging down GitHub issues, Nix search sites, and my friends' DMs.

Finally, and again, Nitpick (I do that a lot, huh): Running VSCode through the Remote - SSH extension was... not easy. Turns out the node binary that ships with that extension and the remote server is dynamically linked, which NixOS doesn't support without additional configuration. That in and of itself isn't necessarily bad, as there are workarounds.

The issue I encountered after that though, that was a bit annoying. Turns out if I choose the patched binary workaround, the remote server gets ran in bubblewrap, making sudo unavailable, meaning I had to have an open terminal on the laptop itself for rebuilding the system. Now I admit, my use case is... different than a lot of others'. But: Slight annoyance.

The confusing

Then come the parts that are just kinda... confusing? They're not inherently bad, just not intuitive for a new user.

First: The (at least) 5 different way to install packages:

systemPackages
packages
programs
home-manager packages
wayland.windowManager

After using and working with Nix a bit more I do understand why it is this way. All of them serve a different purpose, and configure a slightly different part of the system. But knowing which to use when was maybe one of the most confusing things for me as a new user.

Next: User services. Ohhh did I ever struggle with user services. I was thinking I was gonna install and use SwayNotificationCenter for my notifications in Hyprland. So first I need to figure out what package to use. I try what seems like the most logical option, the pkgs.swaynotificationcenter package. That one did work if launched manually or through the hypr exec-once config, but as I was using uwsm, I was thinking I could enable the user service. Only issue: There was none!

So I started digging. Was it in /etc...? No, right, Nix doesn't use FHS. /usr/lib/systemd..? Nope, nothing there either. I dug for about half an hour until I realized: The package itself doesn't include a service! So I started researching other methods, and saw that home-manager includes a services key. However it clearly (very sarcastic) uses a different format to regular flakes and nix config, and keys used in nix aren't available in home-manager despite using the same file format.

So, after another half hour of debugging, I did figure out how to get it running:

services.swaync.enable = true;

Easy enough, I guess, just not intuitive at all. I also have no idea where this has installed the binaries or programs themselves /shrug.

Finally, what seems like a packaging bug to me? The krunner package just... didn't install krunner? In fact, it doesn't install anything! I believe this is probably just a bug, but an annoying one nonetheless. Only way to get krunner was by installing the kdePackages.plasma-workspace package, but this also installed a lot of junk I didn't want at all. I dug into only including the bin/krunner part of the package, but that got me into derivations which I was not nearly ready for.

Overall

So far it might've seemed like I've mostly complained, however: I do like Nix. It's confusing for sure, and not necessarily very intuitive even for seasoned Linux users like myself, but the ideas and concepts it brings to the table are ones I very much enjoy. I won't be switching to Nix full-time, but perhaps I'll be more open to dabbling around in it in the future? For now though, I'll be sticking to Arch, btw :3

[Minipost] Fixing krunner not showing applications in Hyprland

Zoe — Sat, 27 Dec 2025 04:17:18 +0000

Quick one: If on hyprland (or likely any non-plasma WM/DE), krunner is likely to not be showing installed desktop applications. This is caused by a missing symlink in the /etc/xdg/menus directory.

Easy copy-paste fix:

sudo ln -s /etc/xdg/menus/plasma-applications.menu /etc/xdg/menus/applications.menu
sudo update-desktop-database -v

This rebuilds the cache and allows krunner to see the missing applications :3

Automatic LetsEncrypt certificates with Tailscale and Traefik in Docker

Zoe — Sat, 27 Dec 2025 03:11:45 +0000

Just want it to work? See #The Solution. Want to know why it works, along with some backstory? Read on :)

Recently (not really, 2022), Traefik released support for obtaining LetsEncrypt certs for Tailscale hosts. With this, Traefik gained the ability to automatically (if configured correctly) communicate with a locally running Tailscale daemon to request a certificate through the Tailscale certificate cervices for the locally running machine.

Doing some research, this seemed to perfectly align with my goals, so I gave it a try. Reading up on documentation a bit, I figured it would be enough to just configure Traefik to be on the same network as Tailscale, so I tried the following:

services:
  tailscale:
    # redacated for example
  traefik:
    network: service:tailscale

However, when trying this out I kept getting a strange error... Traefik was unable to communicate with the Tailscale daemon even though it was running on the same network!

Looking into the logs and source, I discovered that Traefik is trying to access Tailscale through the local socket on /var/run/tailscale/tailscaled.sock. This obviously isn't passed through through the above network: option, so I add some more:

services:
  tailscale:
    volumes: [var_run_tailscale:/var/run/tailscale]
  traefik:
    volumes: [var_run_tailscale:/var/run/tailscale]

volumes:
  var_run_tailscale:

But, this also didn't work! At this point I got stumped for a solid while. It should've worked, no? Traefik has access to the Tailscale socket? But no! Digging into the containers themselves and checking the status of the socket, I see this:

❯ docker compose exec traefik sh
/ # stat /var/run/tailscale/tailscaled.sock
  File: '/var/run/tailscale/tailscaled.sock' -> '/tmp/tailscaled.sock'
#...

Aha! The socket, for whatever reason, is actually a symlink to /tmp?? This really confused me, as on my non-docker install of tailscale the socket is simply a regular socket.

Talking with a friend, I was told that sockets are usually put in /tmp on rootless containers, however Tailscale seems to run as rootfull? Running ps aux in the container reveals tailscaled running as root, so I don't think that's the explanation in this case.

So, more source code digging is required. Looking into the container, I see it starts a binary called containerboot. I checked the tailscale repo, and found the matching file: cmd/containerboot/tailscaled.go Nestled in there, on lines 78-82, there is the following:

case cfg.StateDir != "":
  args = append(args, "--statedir="+cfg.StateDir)
default:
  args = append(args, "--state=mem:", "--statedir=/tmp")
}

And where does cfg.StateDir come from? Well, cfg is initialized in cmd/containerboot/main.go by calling configFromEnv(), and that is defined in cmd/containerboot/settings.go like this:

func configFromEnv() (*settings, error) {
  cfg := &settings{
    // ...
    Socket: defaultEnv("TS_SOCKET", "/tmp/tailscaled.sock"),
    // ...
  }
}

Aha! It defaults to putting the socket in /tmp (for whatever reason)! Why this was introduced I have NO idea, I tried to dig around a bit and got nowhere¹, however this does tell me what to change to get it to work properly.

The solution

So with these in mind, there are a few required properties for the compose file:

Traefik has to use Tailscale's networking to allow using the tailnet
Traefik needs R/W access to tailscale.sock to be able to request a certificate
Tailscale needs to put the socket in the correct location

This gives me the following file in the end (only including keys required for this specific config):

services:
  traefik:
    network: service:tailscale
    command:
      - --certificatesResolvers.tailscale.tailscale=true
      - --entrypoints.websecure.address=:443
      - --entrypoints.websecure.http.tls.certResolver=tailscale
    volumes:
      - var_run_tailscale:/var/run/tailscale:rw,Z
    depends_on:
      tailscale:
        required: true
        condition: service_healthy

  tailscale:
    volumes:
      - var_run_tailscale:/var/run/tailscale:rw,Z
    environment:
      TS_SOCKET: /var/run/tailscale/tailscale.sock
      TS_USERSPACE: false # Traffic goes through traefik, not directly through tailscale itself
      TS_HOSTNAME: your-app.tailscale-domain.ts.net

Those options will expose Traefik to the tailnet, and allow it to get certificates for itself. Note that Traefik can only ever get a single cert, namely whatever matches the TS_HOSTNAME env var. This is a limitation of Tailscale, and while there is an open issue to get this changed (#7081), it has not seen activity in almost two years as of this writing, so I am not hopeful for it being implemented anytime soon.

Well actually that's not completely true. I did find a few issues on it, most notably #6849 - Change default socket path in containers as well as the commit where this was introduced (2c403cb), however neither of these explain why it was done the way it was. ↩