Decrypt Luks Partition with key on USB during boot

EDIT: Added garuda inxi:

Summary
╭─mario@mario in ~ took 0s
╰─λ sudo cat /usr/bin/garuda-inxi
[sudo] password for mario:
#!/bin/bash

if [ -t 1 ] ; then
c_134=$'\033[1;34m'
c_131=$'\033[1;31m'
c_off=$'\033[0m'
else
c0="c0"
fi

detect_dual_boot() {
if [[ $EUID -eq 0 ]] && [[ -x /usr/bin/os-prober ]]; then
local OSPROBER_OUT="$(os-prober)" || { DUALBOOT="Os-prober error"; exit; }
echo $OSPROBER_OUT | grep -q "Windows Boot Manager" &> /dev/null && DUALBOOT="Yes" || DUALBOOT="No/Undetected"
elif [[ -x /usr/bin/efibootmgr ]] && [ -d /boot/efi ]; then
local EFIBOOTMGR_OUT="$(efibootmgr)" || { DUALBOOT="Efibootmgr error"; exit; }
echo $EFIBOOTMGR_OUT | grep -q "Windows Boot Manager" &> /dev/null && DUALBOOT="Probably (Run as root to verify)" || DUALBOOT="No/Undetected"
elif [[ -x /usr/bin/os-prober ]]; then
DUALBOOT="<superuser required>"
else
DUALBOOT="No detection tool installed"
fi
}

detect_snapshots() {
if [ -d /.snapshots ] || pacman -Qq snapper-support &> /dev/null; then
printf "snapper "
elif [ -d /run/timeshift ] || pacman -Qq timeshift-support &> /dev/null; then
printf "timeshift "
elif pacman -Qq snapper &> /dev/null; then
printf "snapper(custom) "
elif pacman -Qq timeshift &> /dev/null; then
printf "timeshift(custom) "
fi
}

generate_relevant_software() {
local RELEVANT=()
local packages
packages="$(pacman -Qq garuda-dracut-support mkinitcpio dracut nvidia-dkms grub-customizer 2> /dev/null | xargs || true)"

systemctl is-enabled tlp &> /dev/null && RELEVANT+=("tlp")
systemctl is-active NetworkManager &> /dev/null && RELEVANT+=("NetworkManager")
systemctl is-active connman &> /dev/null && RELEVANT+=("connman")

if [[ "$packages" =~ (^| )garuda-dracut-support($| ) ]]; then
RELEVANT+=("dracut")
elif [[ "$packages" =~ (^| )dracut($| ) ]]; then
RELEVANT+=("dracut(custom)")
fi
[[ "$packages" =~ (^| )mkinitcpio($| ) ]] && RELEVANT+=("mkinitcpio")
[[ "$packages" =~ (^| )nvidia-dkms($| ) ]] && RELEVANT+=("nvidia-dkms")
[[ "$packages" =~ (^| )grub-customizer($| ) ]] && RELEVANT+=("grub-customizer")

detect_snapshots

local RELEVANT_SOFTWARE="${RELEVANT[*]}"
[ -z "$RELEVANT_SOFTWARE" ] && RELEVANT_SOFTWARE="None"
echo "$RELEVANT_SOFTWARE"
}

generate_system_update() {
local last_update
last_update="$(date -r /var/lib/garuda/last_update +%s 2> /dev/null)" || { echo "Unknown/Never"; return; }
local reboot=""
if [ "$last_update" -gt "$(date -r /proc +%s)" ]; then
reboot=" ${c_131}↻${c_off}"
fi
echo -e "$(date -d"@$last_update" +%F)${reboot}"
}

inxi -Faz${c0} --zv

echo -e "${c_134}Garuda ($(pacman -Q garuda-common-settings | awk '{print $2}')):${c_off}"
install_date="$(head -n1 /var/log/pacman.log | cut -d " " -f1 | cut -c 2-11)"
echo -e "${c_134}  System install date:${c_off}     ${install_date}"
echo -e "${c_134}  Last full system update:${c_off} $(generate_system_update)"
echo -e "${c_134}  Is partially upgraded:  ${c_off} $([ -e /var/lib/garuda/partial_upgrade ] && echo Yes || echo No)"
echo -e "${c_134}  Relevant software:      ${c_off} $(generate_relevant_software)"
detect_dual_boot &> /dev/null
echo -e "${c_134}  Windows dual boot:      ${c_off} ${DUALBOOT}"
echo -e "${c_134}  Failed units:           ${c_off} $(systemctl list-units --failed --full --all --plain --no-legend | awk '{printf("%s ",$1)}')"
if [ "$1" == "funstuff" ]; then
update_count="$(paclog --grep="starting full system upgrade" | wc -l)"
echo -e "${c_134}  Total system updates:   ${c_off} ${update_count}"
echo -e "${c_134}  --> Updates per week:   ${c_off} $(( ${update_count}/(($(date +%s) - $(date --date="$install_date" +%s) )/(60*60*24*7)) ))"
fi
```-

As the title says i want to unlock my luks partition at boot using a keyfile stored on an USB drive. Yes i know i should use a Yubikey (and i will in the future) but i want to learn and understand how it would work.

After countless hours reading threads and manpages im not sure I learned anything other than that i tried various approaches and that they did not work. But I hope that its a Layer 8 problem.

Also this is only a testclient. I dont care if there is dataloss in the process! I just want to figure it out!

The Setup i currently have:

Drive Partitions:
NAME                                          FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1                                        vfat        FAT32       961B-6B91                             298,6M     0% /boot/efi
├─sda2                                        crypto_LUKS 1           a94fa0a8-dcaa-4051-b3bb-1718cc6eba85
│ └─luks-a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 btrfs                   dfcfa048-d201-46ee-ab20-eec66e74c2d2  448,9G     4% /var/tmp
│                                                                                                                         /var/cache
│                                                                                                                         /var/log
│                                                                                                                         /root
│                                                                                                                         /home
│                                                                                                                         /srv
│                                                                                                                         /
└─sda3                                        crypto_LUKS 1           faa0557d-f79c-49dd-8904-d11a7c3e1da8
└─luks-faa0557d-f79c-49dd-8904-d11a7c3e1da8 swap        1     swap  5cd4a803-586d-416e-b8eb-7dddf26c90e9                [SWAP]
sdb
└─sdb1 THE USB I WANT TO USE!
zram0                                         swap        1     zram0 93ebc1a7-83c1-4de9-ac65-f83b7878bcbe                [SWAP]

My USB:

ls /run/media/mario/luksgood/
drwxr-xr-x    - mario 18 Jun 12:32  .Trash-1000
drwxr-xr-x    - mario 23 Jun 16:54  .Trash-1924804655
.rw-r--r-- 2,0k mario 29 Jun 21:14  key

I modified /etc/default/grub manually, from what i thought i learned from different threads. Most Likely here lies one of the mistakes.

# GRUB boot loader configuration

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR='Garuda'
#GRUB_CMDLINE_LINUX_DEFAULT='quiet rd.luks.uuid=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 rd.luks.uuid=faa0557d-f79c-49dd-8904-d11a7c3e1da8 resume=/dev/mapper/luks-faa0557d-f79c-49dd-8904-d11a7c3e1da8 loglevel=3'
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash rd.luks.name=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85=luksroot rd.luks.key=/dev/disk/by-uuid/0845-C218:key rd.luks.timeout=15"

GRUB_CMDLINE_LINUX=""
...

One of the Threads i read was saying i need to use dracut to make the initramfs aware of the USB. But for the love of god i cannot get it to work.

I created “/etc/dracut.conf.d/10-usb-luks.conf”

╰─λ sudo cat /etc/dracut.conf.d/10-usb-luks.conf
[sudo] password for mario:
hostonly="no"
add_device+=" /dev/disk/by-uuid/0845-C218 "
add_drivers+=" usb_storage usbhid xhci_hcd ehci_pci ehci_hcd uhci_hcd sd_mod "
filesystems+=" vfat "

I also did a rebuild of initramfs using “sudo dracut --force /boot/initramfs-linux-zen.img 6.15.4-zen2-1-zen” but i cant find a mention of “vfat” or the device uuid in the logs:

LOG:
dracut[I]: Executing: /usr/bin/dracut --force /boot/initramfs-linux-zen.img 6.15.4-zen2-1-zen
dracut[I]: *** Including module: bash ***
dracut[I]: *** Including module: systemd ***
dracut[I]: *** Including module: systemd-ask-password ***
dracut[I]: *** Including module: systemd-battery-check ***
dracut[I]: *** Including module: systemd-cryptsetup ***
dracut[I]: *** Including module: systemd-initrd ***
dracut[I]: *** Including module: systemd-journald ***
dracut[I]: *** Including module: systemd-modules-load ***
dracut[I]: *** Including module: systemd-pcrphase ***
dracut[I]: *** Including module: systemd-sysctl ***
dracut[I]: *** Including module: systemd-tmpfiles ***
dracut[I]: *** Including module: systemd-udevd ***
dracut[I]: *** Including module: modsign ***
dracut[I]: *** Including module: dbus-broker ***
dracut[I]: *** Including module: dbus ***
dracut[I]: *** Including module: i18n ***
dracut[I]: *** Including module: network-manager ***
dracut[I]: *** Including module: network ***
dracut[I]: *** Including module: net-lib ***
dracut[I]: *** Including module: btrfs ***
dracut[I]: *** Including module: crypt ***
dracut[I]: *** Including module: dm ***
dracut[I]: *** Including module: kernel-modules ***
dracut[I]: *** Including module: kernel-modules-extra ***
dracut[I]: *** Including module: kernel-network-modules ***
dracut[I]: *** Including module: lvm ***
dracut[I]: *** Including module: mdraid ***
dracut[I]: *** Including module: nvdimm ***
dracut[I]: *** Including module: qemu ***
dracut[I]: *** Including module: qemu-net ***
dracut[I]: *** Including module: btrfs-snapshot-overlay ***
dracut[I]: *** Including module: fido2 ***
dracut[I]: *** Including module: pkcs11 ***
dracut[I]: *** Including module: cifs ***
dracut[I]: *** Including module: hwdb ***
dracut[I]: *** Including module: lunmask ***
dracut[I]: *** Including module: nfs ***
dracut[I]: *** Including module: resume ***
dracut[I]: *** Including module: rootfs-block ***
dracut[I]: *** Including module: terminfo ***
dracut[I]: *** Including module: udev-rules ***
dracut[I]: *** Including module: virtiofs ***
dracut[I]: *** Including module: dracut-systemd ***
dracut[I]: *** Including module: usrmount ***
dracut[I]: *** Including module: base ***
dracut[I]: *** Including module: fs-lib ***
dracut[I]: *** Including module: shell-interpreter ***
dracut[I]: *** Including module: shutdown ***
dracut[I]: *** Including module: systemd-sysusers ***
dracut[I]: *** Including modules done ***
dracut[I]: *** Installing kernel module dependencies ***
dracut[I]: *** Installing kernel module dependencies done ***
dracut[I]: *** Resolving executable dependencies ***
dracut[I]: *** Resolving executable dependencies done ***
dracut[I]: *** Hardlinking files ***
dracut[I]: *** Hardlinking files done ***
dracut[I]: *** Generating early-microcode cpio image ***
dracut[I]: *** Constructing GenuineIntel.bin ***
dracut[I]: *** Store current command line parameters ***
dracut[I]: *** Stripping files ***
dracut[I]: *** Stripping files done ***
dracut[I]: *** Creating image file '/boot/initramfs-linux-zen.img.tmp' ***
dracut[I]: *** Creating initramfs image file '/boot/initramfs-linux-zen.img.tmp' done ***
dracut[I]: *** Moving image file '/boot/initramfs-linux-zen.img.tmp' to '/boot/initramfs-linux-zen.img' ***
dracut[I]: *** Moving image file '/boot/initramfs-linux-zen.img.tmp' to '/boot/initramfs-linux-zen.img' done ***

After Reboot i just get prompted for my password as usual.

I apologise if this is really dumb and also for my bad english. If someone could point me in the right direction i would be grateful!

Best Regards
Tastelessbrain

Hey @tastelessbrain,

I’ve done something similar before and ran into a lot of the same issues. Here’s a simpler way to approach it:


1. Add the key to your LUKS setup

First, make sure your keyfile works with your encrypted partition:

bash

CopyEdit

sudo cryptsetup luksAddKey /dev/sdX /run/media/mario/luksgood/key

Replace /dev/sdX with your LUKS device (like /dev/nvme0n1p2 or similar). If this doesn’t work, nothing else will.


2. Edit /etc/crypttab

This file tells your system where to find the key during boot. Add this line:

pgsql

CopyEdit

luksroot UUID=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 /dev/disk/by-uuid/0845-C218:key luks

Make sure the UUID for the USB is correct.


3. Dracut config

Your config looks mostly okay. You can simplify it to:

bash

CopyEdit

# /etc/dracut.conf.d/10-usb-luks.conf
hostonly="yes"
add_drivers+=" usb_storage xhci_hcd ehci_pci uhci_hcd "
filesystems+=" vfat "

Then rebuild initramfs:

bash

CopyEdit

sudo dracut --force --kver $(uname -r)

4. GRUB

Since /etc/crypttab is doing the job, your GRUB line can be simpler:

bash

CopyEdit

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash rd. Luks.uuid=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85"

Then run:

bash

CopyEdit

sudo grub-mkconfig--o/boot/grub/grub.cfg

5. Keyfile permissions

Make sure the key on the USB is only readable by root:

bash

CopyEdit

sudo chown root: root /run/media/mario/luksgood/key
sudo chmod 400 /run/media/mario/luksgood/key

Now reboot with the USB plugged in. If everything is right, it should unlock without asking for a password. If the USB isn’t there, it should ask you like normal.

Hope that helps! Let me know if you get stuck anywhere.

Hey @magnux
thank you for your help.

A few questions:

  1. Do you think it matters if the pw prompt appears before or after the grub menu where i select which os to boot?
    1.1 currently it appears before anything else at boot.
    1.2 i can change it to another setup where /boot/efi & /boot are unencrypted if it helps.
    1.2.1 this would have the effect that the pw prompt appears later, when loading the initramfs

  2. When i tried to rebuild initramfs with “sudo dracut --force --kver $(uname -r)” i get:

Summary
╭─mario@mario in ~
╰─λ sudo dracut --force --kver $(uname -r)
[sudo] password for mario:
dracut[I]: Executing: /usr/bin/dracut --force --kver 6.15.4-zen2-1-zen
dracut[F]: Can't write to /boot/efi/859395ee4bcd45f6ada54fcd71f07338/6.15.4-zen2-1-zen: Directory /boot/efi/859395ee4bcd45f6ada54fcd71f07338/6.15.4-zen2-1-zen does not exist oris not accessible.```

2.1 So i did “sudo dracut --force /boot/initramfs-linux-zen.img 6.15.4-zen2-1-zen”

  1. when changing the owner i get operation not permitted.
Summary
╭─mario@mario in ~ as 🧙 took 3s
[🔴] × sudo chown root:root /run/media/mario/luksgood/key
sudo chmod 400 /run/media/mario/luksgood/key
[sudo] password for mario:
chown: changing ownership of '/run/media/mario/luksgood/key': Operation not permitted```

My Crypttb looks like this currently:

Summary
# <name>               <device>                         <password> <options>
luks-a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 UUID=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85     /crypto_keyfile.bin luks
luks-faa0557d-f79c-49dd-8904-d11a7c3e1da8 UUID=faa0557d-f79c-49dd-8904-d11a7c3e1da8     /crypto_keyfile.bin luks
luksroot UUID=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 /dev/disk/by-uuid/0845-C218:key luks

Im using your dracut.conf file, and restored the original Grub cmdline:

GRUB_CMDLINE_LINUX_DEFAULT='quiet rd.luks.uuid=a94fa0a8-dcaa-4051-b3bb-1718cc6eba85 rd.l
uks.uuid=faa0557d-f79c-49dd-8904-d11a7c3e1da8 resume=/dev/mapper/luks-faa0557d-f79c-49dd
-8904-d11a7c3e1da8 loglevel=3'

Any further suggestions? I have not rebooted yet since im not sure about my initramfs.

@magnux please do not copy/paste responses from an AI chat bot like this. The response you posted has bad information in it. In many ways, no response at all is better than one of these hallucinated responses, where the tone sounds convincingly knowledgeable but the information is partly or mostly false.

First of all, you do not need sudo to cat this file because it is world-readable.

❯ ls -l /usr/bin/garuda-inxi
.rwxr-xr-x 3.6k root 28 Jun 11:06 /usr/bin/garuda-inxi

See this article if you want to learn more about that: File permissions and attributes - ArchWiki

Secondly, when you cat the file it just shows us the contents of the script. You are supposed to run the script, like this:

garuda-inxi

The output contains informative diagnostic information that forum helpers can use to learn more about the system you are running.

Yes, there is a crucial difference here. When the password prompt comes before the GRUB menu, then you are using GRUB’s special LUKS unlock mechanism. This mechanism runs before the kernel or initramfs are loaded, and in fact before even GRUB itself is fully loaded–only a small piece of code that handles this unlock function is running during this unlock process.

There are some advantages and some drawbacks. An advantage is it allows for an encrypted /boot (see https://wiki.archlinux.org/title/GRUB#Encrypted_/boot). A disadvantage is this mechanism is very simple, and most of the features available to systemd for unlocking a LUKS device are not supported here (don’t forget, systemd hasn’t actually started yet at this point in the boot routine).

You can patch GRUB to use a keyfile instead of a passphrase, as described here:

dm-crypt/Encrypting an entire system - ArchWiki

Using a USB drive to unlock /boot

To avoid having to memorise a complicated password, or using a simple one which may be guessed, a keyfile stored on an external USB drive can be used to unlock the LUKS volume. For this to be secure, this USB drive must be stored securely away from the computer when not in use.

First, generate a keyfile in the same way as in #Avoiding having to enter the passphrase twice. Do not use the same keyfile as if the USB drive is lost or compromised you will need to replace the keyfile embedded in initramfs.

Copy this keyfile to your USB drive and create a new GRUB configuration file:

/boot/grub/grub-pre.cfg
set crypto_uuid=UUID-of-the-luks-volume
set key_disk=UUID-of-the-volume-with-the-key
cryptomount -u $crypto_uuid -k ($key_disk)/the-location-of-the-key-on-your-usb
set root=UUID-of-the-unlocked-volume-as-in-grub.cfg
set prefix=($root)/boot/grub
insmod normal
normal

Create a GRUB image and install it (not all of these modules will be needed depending on your file system):

# grub-mkimage -p /boot/grub -O x86_64-efi -c /boot/grub/grub-pre.cfg -o /tmp/grubx64.efi  part_gpt  part_msdos cryptodisk  luks  gcry_rijndael gcry_sha512 lvm ext2 ntfs fat exfat
# install -v /tmp/grubx64.efi /efi/EFI/GRUB/grubx64.efi

This should be given careful consideration because you will now be unlocking the LUKS device with a keyfile instead of a passphrase. That means if the keyfile is lost, GRUB cannot unlock the disk. You would have to boot to a live environment, unlock the disk with a passphrase or keyfile stored in one of the other keyslots, and then add a new GRUB-compatible keyslot and rebuild the GRUB image again before you would be able to boot into your installation normally.

All of the other stuff you have been messing with (dracut configuration, /etc/crypttab, even the GRUB configuration) has no effect whatsoever on this GRUB routine because none of that stuff has even started yet. Dracut changes how the initramfs gets generated, but the initramfs hasn’t been loaded yet at this stage. /etc/crypttab is in the root partition, which hasn’t even been unlocked yet and won’t be read until much later in the boot routine. And even the GRUB configuration isn’t read until after this special LUKS unlock phase is complete.

By the way, speaking of dracut:

You should not be running dracut like this. That image is never going to get used because it doesn’t match the name of the kernel as it appears in /boot. You should use the dracut-rebuild script instead:

sudo dracut-rebuild

There is a wiki document which has been hyperlinked quite a few times in this thread which has more information about the Garuda Linux implementation of dracut: Dracut | Garuda Linux wiki

If you use an unencrypted /boot, or store the kernels and initrds on the unencrypted EFI partition, then systemd will unlock the LUKS device instead of GRUB. This has the drawback of not having these things encrypted, but systemd’s implementation of this process is much more robust and featureful than GRUB’s.

For example, in addition to being able to unlock the LUKS device with a passphrase or keyfile, you can also enroll hardware tokens like smartcards, FIDO2 tokens, or even the computer’s TPM chip. See this article if you want to learn more enrolling hardware tokens: systemd-cryptenroll - ArchWiki

Systemd also handles unlocking more gracefully. You get more than one chance to unlock before dropping to a recovery shell for example, and you can unlock with any keyslot you want (so if you don’t have your USB key or hardware token or whatever, you can use a passphrase). There is also support for cryptographically superior PBKDFs like Argon2id (which is the cryptsetup default) and Argon2i, where GRUB only supports PBKDF2. And of course, whatever modules you are adding to the initramfs should be available at this stage.

I hope that helps, welcome to the community @tastelessbrain. :wave:

3 Likes

Hey @BluishHumility ,
thanks a lot, seems like i have a lot to read but the picture is already a bit clearer now.
I will read all the linked articles tomorrow, but after skimming your answer I will most likely opt for the option with unencrypted /boot using systemd.

If you happen to have the nerve and time for another beginner question:
What is the difference between /boot & /boot/efi? Or as far as I can see I only have /boot/efi in the current setup which is unencrypted. How does that differ from manually creating /boot & /boot/efi at install?

I will also deliver the inxi information as soon as i have hands on my laptop again.

Thank you very much for your help and the warm welcome!

When using the GRUB bootloader, /boot is the directory where your kernels and initrds are typically stored and /boot/efi is the mountpoint for the EFI partition.

/boot/efi is not a typical mountpoint for any other bootloader. I don’t know why GRUB does it this way…maybe no one does. With other bootloaders it is more common for the EFI partition to be mounted at /efi because it is simpler and makes a lot more sense.

Some bootloaders do not use the /boot directory either, despite its name. For example, systemd-boot and Limine store the kernels and initramfs images right on the ESP.

Be aware that this complicates the typical Garuda Linux installation a bit because /boot will need to be moved to a separate partition. This has some undesireable consequences, for example you will not be able to boot to Btrfs snapshots from GRUB after any kernel upgrade (because the snapshot’s kernel is no longer part of the snapshot).

Technically you would still be able to restore system snapshots, but you would need to set up an additional Snapper config for the boot partition (it won’t be captured in the regular system snapshots anymore because it’s a separate filesystem). When restoring snapshots, you would need to restore both the root partition snapshot and the corresponding boot partition snapshot as well if you are rolling back to a previous kernel version.

Switching to another bootloader may be less complicated, but you will still lose the ability to boot to Btrfs snapshots unless you switch to Limine and set up limine-snapper-sync (which would maybe not be less complicated after all).

Any way you approach it, if you decide to use FDE with an unencrypted /boot you will inevitably stray significantly from a stock Garuda Linux installation.

2 Likes

Okay I tried a few things:
I tried the part with dm-crypt to make grub use the key file. Did it 2 times to make sure i didnt ■■■■ up to follow the instructions. (So obviously the UUIDS have changed because of a reinstall.)

But when i try it I get thrown into grub rescue shell.

Summary
error: disk `A9E3-C33B' not found.
error: disk `398a07a2-e558-401c-8e67-bd949ae82b58' not found.
Unknown command 'normal'.
error: disk `398a07a2-e558-401c-Be67-bd949ae82b58' not found.
Entering rescue mode...

grub rescue>

I noticed that grub output inidcates that the USB and therefore also the decrypted root is not found.
I put some screenshots of the configs together after boot into a live usb.

=================
On another note:

Do I understand you correctly that i will not be able to use a yubikey 5 for decryption while using grub/dm-crypt and therefore have to choose between yubikey decrypt and simple usage of btrfs snapshots?

Thanks
Mario

Yes.

Or, I guess a more technically correct answer would be that GRUB does not support it by default. It may be possible to patch support into a custom GRUB image, I have no idea.

I think I know what you mean, but the way this is phrased is somewhat overgeneralized. To be clear, the usage of Btrfs snapshots in general will not be affected in any way by the bootloader you use, how many partitions you have, what disks are encrypted or not encrypted, how you unlock your LUKS partitions, etc.

The ability to boot into Btrfs snapshots from GRUB with grub-btrfs will be affected if you do not store your kernel on the root partition. If the snapshot references a kernel which is not found in /boot (for example, after a kernel update) then the boot will fail.

Another thing that will be affected is the ability to restore full system snapshots, for example using Btrfs Assistant. If you have a separate boot partition and it is Btrfs, you can still do it but you would need to set up snapshots separately for the boot partition (each separate partition is a separate filesystem), then for a full system rollback you would need to restore a snapshot for the root partition, and also the corresponding snapshot for the boot partition as well.

Just as an anecdotal comment, I have configured LUKS unlock with a YubiKey but ended up scrapping it and going back to a passphrase because I decided to use the YubiKey for other PAM-related stuff instead. You can use it for logging in to your display manager for example, or unlocking the lock screen, or in place of your sudo password. I have even seen examples of people setting up a udev rule where the computer is unlocked as long as the YubiKey is plugged in, but once they unplug it the computer automatically locks.

Obviously you don’t want to have everything bound to the same YubiKey (LUKS unlock + login + sudo password), or if the key were stolen someone could boot the device, log in, and elevate to root with basically no effort at all. If you are going to use it, you should probably just use it for one thing. But if you want to get a little more use out of your YubiKey, you can use it for something that sees a little more action than one simple unlock task at the beginning of the boot routine.

4 Likes