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

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:

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

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.

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.

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.

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