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

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:

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

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.



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