Partitioning for Tumbleweed FDE on two disks?

[Parnikkapore]

I’m thinking of installing Tumbleweed on my laptop; it has 2 SSDs, and I want to form a full-disk-encrypted btrfs pool out of them.

In order of importance:

• Boot-to-snapshot should not be broken
• I should only have to enter my password once from cold boot to desktop
• I should not have to, say, pre-plan how much space to allocate for / vs /home, etc
• There should be no partition unlockable with the TPM alone
• The setup should be well-supported by OpenSUSE’s tooling in general

What partition setup should I use?

[Parnikkapore]

Easiest is probably to put 'em both in a VG and have a single LUKS+btrfs LV, but I’d prefer the information that there are two drives to propagate to the FS level.

[Parnikkapore]

No replies

Anw! It turns out that searching for “encrypted btrfs root add disk” yielded a bunch more results. This person got through all the bits I’m worried about, but had to enter their password twice:

Add encrypted device to encrypted BTRFS filesystem

What makes you think so? Help? To offer any help you need to at least show something from your system that demonstrates the problem - logs, screenshot, photo - and provide details at which point it happens. We do not even know whether you are talking about root filesystem or not. If it is root, you would need to recreate initrd at the very least to make it aware of new encrypted partition.

• Two apparent successes that I can’t grasp enough to confidently apply:

Add additional disks to encrypted btrfs root on Silverblue

Installing Ubuntu (22.04) on a mirrored (RAID-1) and encrypted btrfs root...

Obv this is far, far easier with separate /boot, but I remember that doing that on Tumbleweed means no boot-to-snapshot. Hrm.

[Parnikkapore]

Update on possible methods to achieve my goals:

• Do not use GRUB if your rootfs is split across 2+ disks and those aren’t on a single VG. It will fail to boot. systemd-boot works fine.
• On that note: since sdbootutil shifts the kernel + initramfs into /boot/efi, LUKS unlocking would be done in userspace and thus have password reuse - hallelujah!
• (untested) To autounlock KWallet, follow Unlocking session keyring with LUKS password prompted at boot - #13 by elyvi

So, two ways to set up an FDE system the way I like it (if you don’t need designer-approved password prompts):

1. password LUKS + GRUB + autologin + kwallet password passthrough
2. password LUKS + systemd-boot + autologin + kwallet password passthrough (highly recommended if you have 2+ disks)

Of course, you could also consider:

3. tpm2 LUKS + systemd-boot + no autologin

A sufficiently good PCR setup protects against plug-in-a-flash-drive (and edit-the-cmdline) exploits.

[elyvi]

Hey there ! So, I’ve read your topic (after receiving a notification for the link) and I can give you a bit more information:

I wanted to avoid using the TPM altogether because it’s not something I want to trust (even with the rights PCR): that’s a personal opinion, but I do feel that using a prompter password at boot to unlock the disk is safer.

My setup is this one on your list:

password LUKS + systemd-boot + autologin + kwallet password passthrough (highly recommended if you have 2+ disks)

I do use systemd, I have the prompt that is asked by plymouth (it is acceptable in terms of design) and I have SDDM with autologin enabled. I only type my password once at boot, the session wallet is opened automatically.