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/

Reply via email to