On Tue, May 14, 2024, at 7:27 PM, richard emberson wrote: > Poking about I see that the default workstation disk layout: > https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41:
Now Fedora 42. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/EIKMTS3SYSKH7R2VIJ37NMSYDCIUK466/ > So, are you saying that with Fedora 41, it will be the default for the > /boot partition to use btrfs? There are some unresolved issues before we do this. I think top on the list is fscrypt support for Btrfs (it's in final code review prior to being merged so hopefully this year). That way we can have a non-encrypted /boot on Btrfs subvolume for GRUB2, and not have to do the dirty work of configuring GRUB for LUKS. But then we can have per directory encryption. Like we could eventually have / encrypted with a key sealed in the TPM so it just automatically gets unlocked during startup, but it's protected from tampering when at rest (off). And then use a different key based on user login passphrase or a hardware key like a FIDO device, e.g. systemd-homed, per user home. A lot of this is being worked on already but I can't tell you when it'll land in a future Fedora version until it's farther along. GRUB hidden boot menu feature depends on a really curious file called grubenv in order to know if the boot has failed, and if it's failed, to show the otherwise hidden boot menu (kernel list). The grubenv file was conceived in ancient times when it was acceptable for GRUB to find the file (via file system read only drivers), and overwrite the contents of its blocks, modifying typically just one byte, in order to reset the boot counter. Then later if the boot succeeds, the grubenv is modified in (linux) user space. But when this file is on Btrfs, modifying the contents of a file outside the kernel code (by GRUB just changing bytes on disk in a single sector) is indistinguishable by Btrfs from corruption, because GRUB does not have a btrfs write driver - it's read only, so it doesn't recompute checksums, and rewrite all the leaf and node blocks to correctly update the file system for this change. Therefore the file will fail checksum verification by Btrfs, so it can't be read, and thus the file would need to be replaced in user space every time... we don't really need the data in it, probably? I have to think about it some more. Or alternatively we rethink the hidden grub menu feature. There's been a bunch of ideas where the grubenv data should go instead because really none of the file system developers like the current approach of code that isn't upstream (kernel) based writing inside the file system area. It's now frowned on. Another consideration is that /boot on Btrfs means it's harder to support other bootloaders like sd-boot, which don't contain file system drivers like GRUB's read-only drivers. There's a couple of different projects to create an EFI FS driver for Btrfs so that the UEFI pre-boot environment can read Btrfs natively - therefore any bootloader would be able to read it. The drawback with this is, it needs to be UEFI Secure Boot signed, and we need some plan and policy how that would work - per distribution btrfs drivers? Or is there a way to make it generically supportable across distributions with a single signature? That's off the top of my head there might be some other things. -- Chris Murphy -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
