Re: F29 System Wide Change: Make BootLoaderSpec the default

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

 



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/




[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