On Mi, 15.10.25 12:53, Chris Murphy ([email protected]) wrote: > On Wed, Oct 15, 2025, at 3:30 AM, Lennart Poettering wrote: > > On Di, 14.10.25 22:43, Chris Murphy ([email protected]) wrote: > > > >> Last time this came up (5ish years ago) they said no because it's > >> too simple, doesn't support enough of RHEL's use cases. And that > >> they had insufficient bandwidth for more work. > >> > >> And it's the same in Fedora. Fedora Server can't use systemd-boot or > >> plain FAT only $BOOT, because they require support for /boot on > >> mdadm raid1. Same with CentOS and RHEL. > > > > Sorry, but using mdadm raid1 in the boot loader is a really bad idea, > > you have to replicate the whole raid stack, because as mentioned many > > times, *write* support actually matters for boot count/RNG support. > > That's not why it's a bad idea. Upstream mdadm devs don't like it, > don't support it, and have asked folks to stop doing it. But they're > ignored because people want this functionality, and as a bad hack > it's maybe safe, until it isn't. And then oh well! > > I'm glad you brought up write support for boot counting and RNG > support. How is this supposed to be implemented on non-UEFI systems? > As far as I'm aware no bootloaders have drivers that support writing > to FAT.
It's not the most complex thing in the world to implement a FAT driver. Its fundamental data structures are essentially a design from 1977, which by today's standards is almost trivial to implement. For both RNG seed updating and boot counting in-sector updates suffice btw, as long as you have a non-journalling fs, such as VFAT. This means drivers can be really simple, and updates can be very robust and efficient. > Is every non-UEFI bootloader expected to re-implement a FAT driver > from e.g. tianocore? Like is that even legal? I thought the patent > exception on the FAT driver applies to UEFI implementations only? IANAL, but the patents in question where about long filename conversion, and if you do the in-sector updates for the boot counts/RNG then you don't need to bother with that. In-sector updates is for example what this project is pursuing: https://github.com/nkraetzschmar/bootloader/tree/main https://media.ccc.de/v/all-systems-go-2025-328-one-boot-config-to-rule-them-all-bringing-uapi-boot-specification-to-legacy-bios https://github.com/uapi-group/specifications/pull/168 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
