On Do, 09.10.25 14:51, Chris Murphy ([email protected]) wrote: > > 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.
Well, sure, we allowed some flexibility there, but made the intention clear, no? Of course, I regret having granted the flexibility, that was a mistake. > 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. This is a really sad situation. > > 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. Well, it's not that unclear. We say it *should* be vfat. I regret I didn't say "*must*"... Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
