On Mi, 21.12.22 10:03, Gerd Hoffmann (kraxel@xxxxxxxxxx) wrote: > For the general case we need some other option. Could be just stick to > grub2 for those cases (we'll continue to need grub2 anyway for bios boot > and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers, > for example this one: > https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg I am pretty strongly against the idea of ext4 for /boot/. First of all, the firmware can't read it natively, but what's worse, uefi cannot even make sense of any of the features it provides above vfat. i.e. file ownership, access modes, ACLs, selinux labels, xattrs, symlinks, … are all complete nonsense to the UEFI fs layer (and to boot loaders that natively implement the fs drivers, the same). The UEFI fs API has no concepts for *any* of these features. Hence, if this is supposed to carry data intended for consumption by the boot loader, why the f**k would you use a file system it cannot even remotely take benefit of? Also, I am pretty sure boot loaders should have the ability to make changes to the file systems they read UKIs from, to implement boot counting and random seed management. grub fs drivers and the stuff derived thereof (i.e. efifs stuff) typically is read-only though. At least for the systemd stuff, we carefully made sure that our access patterns to the ESP both from sd-boot/sd-stub and from userspace are by default as minimal and robust as we can make them, to minimize chance of corruption, given that vfat is not particularly good with that. (i.e. we sync a lot, and the whole ESP mount is by default an autofs instance with an extremely short idle timeout so that it basically remains unmounted — and thus — clean during almost all times). Anyway, if you want to know more about choice of the fs for /boot/, see my ideas here: https://0pointer.net/blog/linux-boot-partitions.html Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
