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

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

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

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

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

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.

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?




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