On 06/25/2018 06:40 AM, Lennart Poettering wrote: > On Fr, 22.06.18 14:17, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > >> 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 > 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? I think it is better (especially for recovery scenarios) if bootloaders operate read-only. I think things like boot counting should be disregarded simply to preserve read-only access. > 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... /boot is already ext on Fedora. Why does anyone *need* to implement XFS for GRUB? >>> 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 > _______________________________________________ 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/WHVLGHHNVL5CQ6EPNIUIV7UKAQC3C3RY/
