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

[Colin Walters <walters verbum org>]

On Thu, Feb 1, 2018, at 5:21 PM, Leon Woestenberg wrote:
> Has the posters question been answered in this regard. I also am
> wondering what the purpose of .0 and .1 is?

That's how libostree does an atomic swap of the bootloader configuration.

On modern Linux we could use `renameat2(..., RENAME_EXCHANGE)` but
eh...not worth hard requiring that yet.

> > > ( FYI, we've enabled u-boot fit and so the kernel, devicetree and initrd
> > > are contained in the boot.itb blob)
> >
> > libostree is currently unaware of this.  We just merged devicetree support:
> > https://github.com/ostreedev/ostree/pull/1411
> >
> > I think .itb support would need to touch all of those code paths.  Mind
> > filing an issue?  Do you have the ability+time to implement it?  If not,
> > is it viable to drop down to split kernel/initramfs/dt?
> Why would libostree need to support .ITB/FIT? I think libostree should
> be pretty agnostic over the files required for boot, and treat them as
> any other file. I have seen (u-)boot boot image implementation change
> often enough ever since existance, let alone the myriad of other
> bootloaders.

This is a complex topic.  Basically, there's (IMO) two kinds of data
in /boot - things we want to update (kernel/initramfs/dtb), and files
that the *bootloader* might read.  For example, GRUB2 splash screens.
https://github.com/ostreedev/ostree/pull/1079
is related here.

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.
It's only the kernel/initramfs (and now dtb) that we change.  I actually
still have a longstanding TODO to entirely drop grub2.rpm from our
OS.

Contrast with how a traditional yum-based Fedora works; the grub2
RPM directly updates files in /boot.  But we don't have a way to do
that transactionally - it's not part of the deployment.
See: https://github.com/projectatomic/rpm-ostree/pull/969

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

> I would rather *not* see libostree assume anything there. It should
> leave the filesystem in a state where some bootloader or initramfs can
> atomically select the deployment to switch to.
>
> A choice can be made by the designer whether a boot file is inside or
> outside the updated deployment.

Basically that choice today is expressed by having "boot data files to
be installed" in /usr/lib/ostree-boot.  Then nowadays the preferred location
for kernel+initramfs (+dtb) is /usr/lib/modules/$kver.

But again, this has all evolved somewhat organically, so I'm happy
to improve it if someone has better ideas.  The way Endless just renamed
their .ITB file as vmlinuz seems somewhat practical to me, even if it's a bit
of a hack.