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

[Colin Walters <walters verbum org>]

On Fri, Feb 2, 2018, at 9:32 AM, Daniel Drake 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?

We just haven't crossed the issue yet honestly.  A number of the server
cases involve re-provisioning periodically anyways; in talking with
some big server deployments, even though ostree is very "image-like",
they still prefer full re-provisions say once a month to entirely flush out
even corner-case state like the filesystem feature set.
(This last one actually did bite us with XFS + ftype=1 requirement for
 overlayfs)

> > 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

Interesting.  Maybe this is something that could be shared with
other libostree users somehow?  One thing that made me pause around
this is just ensuring power-loss safety.  Which gets messy with FAT.
Maybe the easiest thing is to have a "do not power off your device"
screen and require the system be plugged in like you see on other OSes,
but so far libostree has had no such requirement and I really like that
for obvious reasons ;)

It's actually related to the grub.cfg (or equivalent) file on FAT; and actually
XFS; see https://github.com/ostreedev/ostree/pull/1049
And specifically https://marc.info/?l=linux-fsdevel&m=150179189820971&w=2

I could imagine doing something like this with a "pre-grubx64.efi" binary
or the like whose sole purpose was to iterate over an available set of
grubx64-1.efi, grubx64-2.efi etc. which had .checksum files available too,
and if the checksum didn't match it was skipped or so.