On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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". Lennart, I sympathize, but face it. There is a single implementation of kernels and initramfs on the ESP and that's systemd-boot. Everyone else wants to get as far away from vfat as fast as possible. For a long time one of the first things a bootloader does is learn how to read a modern file system, including \EFI\Microsoft\Boot\bootmgfw.efi I totally get the arguments that GRUB is too big, too complicated, does too many things, each distro effectively live forks it into something often incompatible everywhere else. But systemd-boot really does go in the opposite extreme. I think it's too simple. But whatever. The spec's requirement that $BOOT be vfat was simply not going to go anywhere beyond systemd-boot and not even beyond UEFI. >From that perspective, BootLoaderSpec as currently written is too UEFI centric and thus itself is not even trying to reach a consensus which is why it hasn't reached consensus. And systemd-boot could leverage other projects that wrap any of GRUB's existing file system modules as EFI programs to teach the firmware pre-boot environment how to read any file system you want, without having to write in separate support for file systems in systemd-boot. > Which file system do you have in mind even for this? Unspecified for now. i.e. no change. It would remain ext4 by default I expect, but ultimately whatever anaconda allows. > 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. This problem has many little saboteurs acting together to betray the user. It isn't really any one single thing, they all have to happen to capsize the ship. Nevertheless I pretty much find your original criticism that XFS sync() behavior is wrong, the most convincing. I'm happy to give all file systems a pass on fsync() dumping changes only to the log in such a way that only kernel log replay will catch things up properly. But in my sabotage testing, only XFS sync() behavior seems to end up with a file system that is unreliably readable by a bootloader. And I'm not a fan of non-atomic FIFREEZE/FITHAW as the work around, not least of which is I've found a way to sabotage it and break an updating system (with no estimate of how likely this is in the real world). > 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? Wouldn't it be a pity if we didn't teach UEFI to read every goddamn file system ever invented just because we can?! http://efi.akeo.ie/downloads/efifs-latest/x64/ https://github.com/pbatard/efifs I mean honestly, we can teach EFI whatever the hell we want. File system support does not need to be baked into the bootloader on UEFI. Drop these guys onto your ESP and now the firmware with any bootloader can read any of those file systems directly. Pick one. I have to defer to others on the value of symlinks for atomic configuration swapout, but if you want the most widely supported file system that also has symlink support, it's UDF. For the time being though, the concept of a widely sharable $BOOT really doesn't have enough momentum or backing. I still think the change pushing us closer to BootLoaderSpec. But I also think it puts appropriate pressure on BootLoaderSpec to remain relevant. It's going to have to stop being so UEFI centric. That isn't good enough to get it adopted. -- Chris Murphy _______________________________________________ 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/JXYWQZ6ATVZ2D4SIP5VXIKHTXXCJBWL6/
