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. 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? -- 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
