Re: F29 System Wide Change: Make BootLoaderSpec the default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux