On Fr, 22.06.18 19:01, Javier Martinez Canillas (javier@xxxxxxxxxxxx) wrote: > > Whereas constantly changing the ESP, means we need some way to > > establish a master and rsync to the extras. > > So the consensus seems to be to have the BLS fragments in > $BOOT/loader/entries even on EFI, where $BOOT is the boot partition > mounted on /boot. That will give us the following advantages as > mentioned in this thread: Uh, as one of the authors of the spec, I am not convinced using arbitrary non-FAT file systems for $BOOT. In fact the spec currently says it has to be VFAT. I wouldn't call that "consensus". Which file system do you have in mind even for this? As far as I know it's very clear now that boot loaders have a hard time implementing any of the current file systems properly. AFAIK the XFS folks as one case were pretty clear that any implementation of XFS which is not the in-kernel one is not supportable, but I am pretty sure for the other more modern file systems things aren't too different either. The fact that grub doesn't properly implement XFS is a real issue, as I am sure you know, since it won't replay the journal, and hence doesn't see changes made on previous boots when the file system wasn't unmounted (which is a regularly seen issue, as ply keeps XFS busy during shutdown), resulting in unbootable systems. Why not just stick to VFAT? As mentioned, it's really the only thing generally understood by everything that has a stake in boot loading. Grub speaks it. The EFI firmware speaks it (and that also means the EFI shell, which is immensly useful). Linux speaks it in the initrd and after boot. Windows speaks it. MacOS speaks it. It's the lowest common denominator and should be entirely sufficient to store a few kernels and their initrds. I mean, we build our kernels as EFI binaries on Fedora, IIRC. Wouldn't it be a pity if EFI can't actually access them, because they are stored on an fs only Linux speaks? Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/C4EEYIG6HER4QTSPMLCMLESZYDGSHQLI/
