Re: trying to understand how the /boot/loader symlink is supposed to work.

[Chris Murphy <lists colorremedies com>]

On Fri, Feb 2, 2018 at 7:32 AM, Daniel Drake <drake endlessm com> wrote:
> On Fri, Feb 2, 2018 at 10:13 AM, Colin Walters <walters verbum org> wrote:
> > What at least for Fedora Atomic we settled on is a model where
> > the bootloader and its data are installed *once*, and never updated again.
>
> I'm curious why you went with this model. Is it just because it's an
> unsolved problem? What if the bootloader has a bug that needs to be
> fixed, or a security issue?
>
> > Anyways it's a big messy topic, and gets into again how the distribution
> > is built.  I'm just describing what we sort of settled on, but it's
> > by no means the *only* way one could do things.  If someone has better
> > ideas, I'd love to discuss.  Particularly if someone has a design for how
> > updates to the bootloader itself should work.  (Is anyone using e.g. UEFI+ostree
> > actually updating the copy of grub.x64 or whatever on the ESP?)
>
> We are just starting a project to update the bootloader files on the ESP.
> https://github.com/endlessm/eos-boot-helper/pull/178

Two ideas for this project that make it even more helpful is: a.) if
it can take complete mount / umount ownership of the ESP so that it
doesn't have to be an /etc/fstab entry, and is no longer persistently
rw mounted when it doesn't need to be; and b.) if it can, by default,
own all ESP's on every device, and make sure the contents are sync'd
across them for the currently running OS. c.) take ownership of NVRAM
entries.

The b.) usecase I'm thinking of mostly is raid1 installations, so that
the system is still bootable if one of the drives dies. For that to
work you need the ESP on each device updated. There's a really nasty
hack floating around that uses mdadm version 0.9 metadata to raid1 the
ESP, where the UEFI firmware ignores the mdadm metadata found at the
end of the partition, but should either ESP be changed outside of the
assembled volume by mdadm, now the two are out of sync and mdadm can't
resolve the difference between them, and corruption is pretty much
assured. Bad hack.

If there's some unrelated 3rd device plugged in, and it has an ESP,
doesn't matter, update it anyway. It's not worth the logic to find
which devices are part of the /boot or rootfs raid. Just update all
ESPs. And then make sure NVRAM boot entries exist for each of those
ESP's (and path to bootloader). As long as these ESPs are among the
first entries, it'll work, i.e. three devices, three ESPs updated, and
the boot order should point to those three ESPs 1st, 2nd, and 3rd.

The multiboot case might take a bit more thought but mostly if you're
not stepping on other OS directories on the ESP or their NVRAM
entries, it'll be OK.

-- 
Chris Murphy