On Jun 18, 2018, at 3:54 PM, Chris Murphy
<lists(a)colorremedies.com> wrote:
On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas
<javier(a)dowhile0.org> wrote:
>> Yes for EFI systems but no otherwise. On EFI the BLS snippets are in
>> /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in
>> /boot/loader/entries.
>>
>
> I think this is the wrong approach. I see no valid reason that the
> paths should be different on EFI.
I don't like it either but I'm trying to keep an open mind. What I
recall from the conversations years ago with the mgj59 variant, it's a
lot easier to poke holes in any attempt to standardize bootloading,
than to standardize bootloading. But if no one is willing to give any
ground anywhere, it's way too easy to stop progress.
The proposed change doesn't really fix any of the user facing
problems, it just gets us away from depending on grubby and
grub-mkconfig (we never really depended on grub-mkconfig, the
installer uses it as a one shot). So in the most narrow sense, the
change succeeds at doing the only thing it's intending to do. But
yeah, I lament that we're not being more aggressive while we have the
chance to fix past oversights.
And that's fine, as long as it's not done in a way that makes it
harder to improve in the future.
>>
>>> If there's no room on the EFI System partition for all of this, will
>>> we following bullets 2 and 5 of the BLS spec under "The installer
>>
>> No, $BOOT is always the ESP where GRUB 2 is installed.
>
> I’m going to go out on a limb and make a stronger objection than
> Chris’: I think that $BOOT SHOULD NOT be the ESP. The ESP is
> problematic for any number of reasons. It’s usually vfat, so it’s
> fragile. It does not support RAID safely. And it’s often small.
Well as it turns out all the file systems are fragile as far as the
bootloader is concerned :-P We've got bugs where the bootloader can't
read needed files, because part of the commit is still in the journal
rather than fully flushed out to file system metadata. So no matter
what you can break a set up...
...
Getting journal support in the bootloader isn't going to happen. I've
already talked to the various fs upstreams about it.
Why are you talking to the fs upstreams? The problem is a bug in
GRUB, full stop. All this freeze crap that Fedora does is just
papering over the bug. IMO the right thing to do is to get *GRUB*
upstream to have a fully functional implementation of *one*
widely-supported fs. Hmm, GRUB supports F2FS, and F2FS is
log-structured, right? So I don't see how GRUB could fail to read a
dirty filesystem correctly even if it wanted to.
Or someone could design a very simple, highly reliable, filesystem
designed to make it easy to do atomic-enough updates and to read
reliably. Think VFAT-like but with a full atomic swap of all FS
metadata. Or a dead-simple log-structured FS. /me ducks.
Seriously, though, F2FS might be a fantastic choice for this purpose.
> As an extra plus, upgrading a kernel doesn’t require mounting the ESP,
> which means that the bootloader installation can sync the ESP across
> multiple disks and it will remain synced.
Yeah. But *le sigh* we have fwupd which wants /boot/efi mounted
I use 'umask=0077,shortname=winnt,nofail,noauto,x-systemd.automount'
in fstab for /boot/efi and yet every boot:
Jun 17 14:07:06 f28h.local systemd[1]: boot-efi.automount: Got
automount request for /boot/efi, triggered by 2268 (fwupd)
So add that to the list of packages that need an ESP syncing daemon if
they don't want to be responsible for dynamically mounting and
umounting the ESP.
I disagree. fwupd doesn't need any ESP syncing. In the very worst
case, fwupd sticks a capsule in the ESP from which we booted, then
that disk dies, and we don't apply the capsule. No harm done.
I really think the correct approach here is to have an ESP on each
potentially bootable disk. Each ESP will independently contain the
code to handle BootLoaderSpec entries on a *different* partition. The
only time we need to modify all the ESP copies is when we upgrade GRUB
or upgrade GRUB's configuration. We do *not* need to propagate
capsules or any other similar objects. And we should not even try to
impose a requirement that the filesystems be bitwise identical.
They're *copies*, not RAID.
> All that being said, $BOOT should not use security context xattrs —
> getting that to work right across distros is probably impossible.
It's a good point. I'm not really sure how to prevent conflicts if
there is to be a truly shared $BOOT unless it is a file system that
will reject xattrs.
Mount with noxattr?
--Andy