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

[Leon Woestenberg <leon sidebranch com>]

Hello Colin, all,

first of all, I would like to express that I really like the ideas
behind libostree, and we're actively working on getting something
going with Yocto on real-life products. The questions are meant to be
constructive.

On Fri, Feb 2, 2018 at 3:13 PM, Colin Walters <walters verbum org> wrote:
> On Thu, Feb 1, 2018, at 5:21 PM, Leon Woestenberg wrote:
> > 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.
My background is from embedded systems, where there is a wide field of
solutions and requirements. For upgrading, full atomicity is often
important, redundancy comes into play, rollback may be interesting,
and the overall model of rolling (delta-) updates is compelling, and
thus libostree is compelling to solve parts of this. However, for
succesfull integration of libostree, the integration should be
minimally dependent or convoluted with the actual implementation of
the boot mechanism in place.

(I am considering only the non package approach of libostree, so not
rpm-ostree.)

I would consider the kernel, initramfs, dtb and splash screens (and
bootloader scripts, such as boot.scr for u-boot) all the same; as
"potentially updateable files under libostree deployment".
They would live in the same context space as /usr for that matter.
Also, the bootloader would potentially live in the same context, i.e.
it's just an updateable blob.

> 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
OK, why is /boot not part of the deployment? I would expect it to be.
What is the underlying reason for it not being part of the deployment?

> 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 consider the updates of the bootloader to be a problem outside
of ostree.

1. libostree sets up a new deployment.
2) system potentially updates the bootloader.
3) system restarts with the new deployment.

ad 2. this can be highly system dependent. For example: write the new
bootloader to redundant secondary block in QSPI flash.


My point is, updates to the bootloader are very system specific. I
wouldn't say it's libostree's task at all.


> > 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.
The point again is, why would libostree care how the kernel is named?
It's just a file and shouldn't need special treatment, or does it?

Thanks,

Regards,

Leon.