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

[Leon Woestenberg <leon sidebranch com>]

Hi Colin, all,

On Tue, Jan 30, 2018 at 8:41 PM, Colin Walters <walters verbum org> wrote:
> On Tue, Jan 30, 2018, at 10:05 AM, Davis Roman wrote:

> > On our target, there doesn't appear to be anything in the 'loader.0' and
> > 'loader.1' directories ( despite the documentation stating that there
> > should be files in these folders), instead the boot.itb file simply resides
> > in /boot
Has the posters question been answered in this regard. I also am
wondering what the purpose of .0 and .1 is?

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

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.

Regards,

Leon.