On Thu, Oct 9, 2025, at 2:36 AM, Lennart Poettering wrote: > On Do, 09.10.25 01:24, Chris Murphy ([email protected]) wrote: > >> >> Note that Neal also has ideas to move XBOOTLDR into a btrfs subvolume >> >> which for >> >> many of the default editions and spins would remove the problem entirely. >> > >> > That is against the XBOOTLDR spec, which says it should be a file >> > system readable by firmware, i.e. VFAT. >> >> XBOOTLDR is being formatted either ext4 or XFS for a while now in >> Fedora. > > Oh man. You know, i wrote the spec for this. And the spec is quite > clear how it is intended to be used I'd claim. It's so painful how > Fedora regularly takes these specs and turns them into something they > are clearly not supposed to be. If they intend to bend the specs into > something so different, why do they bother to reuse the same partition > type UUIDs even? Anyone can generate their own partition type UUID, > and if they want different semantics they can just do that, write > their own fedora specific spec, but why squat the xbootldr one and > then organize it differently? I consider this a pretty hostile act to > be frank. either support the spec or don't, but squatting xbootldr > partitiont type uuids with different semantics than the spec suggests > is pretty bad.
Boot Loader Spec [1] says, verbatim "ESP must — and the MBR boot and GPT XBOOTLDR partition should — be a file system readable by the firmware" XBOOTLDR is permitted by the spec to be any file system. ESP and BOOTLDR are not required to be writeable by the firmware. I can't tell you when the installer started to use XBOOTLDR , GNU parted learned about bls_boot i.e. XBOOTLDR in 2019. But I don't see where anaconda or blivet ask parted to use bls_boot. Also, Fedora doesn't really own its own bootchain. You know that, right? I argued in favor of full compliance of the Boot Loader Spec, and Red Hat boot loader team was not at all interested in it. Explicitly. The BLS feature/change borrowed the BLS drop-in snippet concept and format only, and discarded the rest. That was their choice. We had to accept or reject a piecemeal approach. And Fedora compromised because it was thought BLS support would help make a future transition to systemd-boot easier, keeping out options open. >> UEFI spec supports file system drivers. The BL spec doesn't say the >> file system support should be built-in to the firmware. > > Umpf. I really don't grok this. Using something that is not VFAT for > this is *so* pointless. You cannot avoid VFAT, because the ESP has to > be VFAT. By using something else for XBOOTLDR you are not just breaking > compat pointlessly, you are duplicating the number of file systems you > need to support, and you extend the attack surface for the OS a lot > (because XBOOTLDR cannot sensibly protected against offline > modifications). For a properly secured system you need to be frugal > with the choice of data structures you read of disks that you cannot > authenticate cryptographically. And ext4 and xfs are ridiculously > complex file systems, these are the worst choices possible. That a lot of words. This could have been short cut by the spec only allowing FAT. Or only allowing firmware native support for file systems. Now we're all spending cycles on what you really meant to say in the spec, but what we're left is is what it actually does say. [1] https://uapi-group.org/specifications/specs/boot_loader_specification/ -- Chris Murphy -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
