Add additional disks to encrypted btrfs root on Silverblue

OS: Fedora Silverblue 39

I’m trying to add additional disks to my luks2 encrypted btrfs root partition, which brings me here along with these questions:

  1. What should the root= kernel parameter be? Will Linux mount additional volumes automatically, or should I add multiple root= parameters, or something else?

  2. How to set up decryption? Do I add entries to /etc/crypttab, and let dracut handle the rest?

  3. How to decrypt all partitions at once with a single password during boot?

Hello @lunar-rover ,
I don’t use LUKS currently, but I have added more disk space to my btrfs /var while reducing the size of my / and due to butterFS being a volume manager too, this was fairly straight forward. It may be the same for you after decryption, but I am not sure how LUKS will behave. Is it easy to turn off LUKS? If so I would do that first, adjust/add to the filesystem, then re-enable/redo the encryption.
The tools I used in the process were the Gnome Disks app for partition manipulation, and the btrfs utilities (but I think BTRTFS Assistant would do for the btrfs tools if you prefer a GUI). The UUID of my /var did not change in this process, so my /etc/fstab remained correct.

1 Like

LUKS is an additional layer on partition itself, like LVM. There’s no easy way(if any at all, all data are encrypted) to remove and re-add it AFAIK.

The storage structure I’m trying to set up is to have two LUKS partitions on two physical disks, and two parts of a btrfs raid on each of them.

I’m primarily confused on where to put startup decryption configs since ostree doesn’t update grub(is bootupd in f40?), and how the kernel handles btrfs raid root.

Creating the partitions are simple and straightforward.

Update:
I added an extra rd.luks kernel parameter via rpm-ostree karts --append, and now it can unlock the luks volumes on boot correctly.

I then added the extra volumes with btrfs device add, and ran btrfs balance.

Note: my filesystem is now corrupted and I’m currently working on salvaging remaining data and reinstalling fedora. Will I continue to use btrfs? Probably yes.

1 Like

After a balance you maybe want to do a scrub too.

1 Like

The metadata corrupted and the filesystem was read only almost immediately after.

BTRFS info (device dm-0:state A): space_info METADATA has -371965952 free, is full

I’m currently en route to an F40 RC brand new installation.

It’s not necessary. A balance reads every block, computes a checksum, compares to the stored checksum for that block which is the same as scrubbing, then writes the block into a new location.

BTRFS info (device dm-0:state A): space_info METADATA has -371965952 free, is full

I don’t think this is on-disk file system corruption. It could be a bug, and recoverable by umount and remount (or rebooting). But what kernel version did this happen with? And was there a call trace in dmesg? This sort of call trace and the complete details of the file system and circumstances leading up to it should be reported either Fedora’s bugzilla or the linux-btrfs@ mailing list.

1 Like