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

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

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.

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

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.

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