On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote: > On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering > <mzerq...@0pointer.de> wrote: > > On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) 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
I am not sure why you are making this about systemd-boot. Let's just focus on why (or why not) vfat is the best option for $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. So think about this one bit ahead. Right now it's clear that even with Grub's relatively large contributor base it'shard to impossible to support modern Linux file systems properly — even just for read-only. See the the XFS debacle as one example, and that the kernel folks made clear they only consider their own in-kernel implementation to be supportable. Now, I'd assume that sooner or later features such as boot counting are something we want for Fedora too (i.e. that we can update the kernel, try to boot the new one a couple of times, and when it fails all the time revert back to an older version, fully automatically; in fact the fedora desktop have very recently started work on that, though they have a weaker model of simply showing the boot menu after failed boots, instead of reverting back). Now, in that model you need to count the attempted boots somewhere. Thus you need write access somewhere (and no, EFI variables don't work for this, they are not suitable for stuff changed on every boot, as their memory is generally not ready to be written too that often). Which hence means you need write access to some file system in some form from the boot loader. And how do you think that's going to work out if already read access to modern file systems is, well, a desaster? Again, FAT is the one thing everyone can agree on. Boot loaders can read it *and write it*, UEFI and raspberry pi firmwares have support for it, and all OSes and their initrds generally too. From the Linux side we can provide relatively safe read and write suppport for FAT. For example, if Fedora would use the systemd automount logic for mounting $BOOT then the file system will generally be unmounted, except in a small time window around actual accesses. This means the chance that the file system remains in a clean state is maxmized. $BOOT is a place to place very few files, with very simple access patterns. Basically, during update cycles we just add a few files there and remove some others, and they are written in one linear write operation. For doing that we need no fancy file system features. The simplest, most common file system storing files ist good enough for that. > 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. So what are you proposing? Are you going to work on the XFS driver in grub to make it match the kernel's current version? And for ext4 too? I mean, good luck with that... > > 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 Oh, right. this approach already failed with Grub, with it's relatively large commercial support, and now you want pile on? > 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. UDF? When's the last time you actually used that? I mean, I don't even have a DVD drive anymore, where I could find an UDF file system on... Also, it's read-only afair, hence stuff like boot counting is not going to work, it's a dead end. Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/ICTD3IZNMW4MMUGQ4DCXA6JVI66KU3IQ/
