[OE-core] Solving a circular dependency issue between the main image and initramfs

[Bartosz Golaszewski]

wt., 17 mar 2020 o 14:45 Quentin Schulz
<quentin.schulz at streamunlimited.com> napisał(a):
>
> Hi Bartosz,
>
> On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote:
> > pon., 16 mar 2020 o 12:01 Richard Purdie
> > <richard.purdie at linuxfoundation.org> napisał(a):
> > >
> > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote:
> > > > There has been no relevant feedback, but I've been experimenting with
> > > > various things. I think that the best approach would be to make image
> > > > artifacts installable into dependant recipes' sysroots (in
> > > > /usr/share/images/). This way the initramfs recipe could calculate
> > > > the
> > > > dm-verity hashes from the resulting ext4 image before it gets
> > > > deployed. We could also modify the kernel recipe to not fetch the
> > > > initramfs image from the shared directory but instead have it
> > > > installed in its sysroot.
> > > >
> > > > For this I tried to re-enable the do_install task in image.bbclass.
> > > > Unfortunately either I'm doing something wrong or standard tasks are
> > > > subject to different rules when it comes to dependencies. I've been
> > > > so
> > > > far unable to make do_install depend on any image tasks (i.e. make
> > > > do_install depend on do_image_ext4/wic etc.) no matter if I use
> > > > do_install[depends] or addtask or appropriate helpers from python.
> > > > Unfortunately I've been unable to find any information on that in the
> > > > manual.
> > > >
> > > > Is there some trick to changing the dependencies of standard tasks?
> > >
> > > I don't know how exactly you're configuring the system but it should be
> > > possible to have the main rootfs built first, adding in the signing,
> > > then have the initramfs depend on that.
> > >
> >
> > I too thought this should be possible with current implementation and
> > yet I've spent so many hours on this to no avail it's not funny. :(
> >
>
> I haven't read carefully your thread but ran into what seems to be a
> similar situation two years ago:
>
> https://youtu.be/jtLQ8SzfrDU?t=2336
>
> So, TL;DR, couldn't create a fitimage with kernel-fitimage because of
> circular dependencies and we had to create a new fitimage bbclass which
> wasn't inherited in the kernel but by the image recipe IIRC.
>
> I didn't think at that time kernel-fitimage made sense because you can
> technically put whatever you want in a fitimage. I can technically not
> have a kernel in it. I thought a fitimage bbclass inherited by an image
> recipe made much more sense. It was two years ago, didn't share anything
> with the YP folks back then, so my bad. I haven't had this issue since
> then (no product requiring this) so didn't think much more about it :/
>
> I promised once we had something good enough we would give back to the
> community. Now that I've left that company and forgot to do it, you can
> throw rocks at me.
>
> Good luck and keep us posted please.
> Quentin

Thanks Quentin,

this is pretty much what Ernst suggested earlier in this thread too.
I'm not a fan of this solution.

Richard et al: do you think making the fitimage class something an
image recipe could inherit is a good idea?

So far I think there are three solutions to the problem:

1. Make wic image a separate recipe that could run after everything
else is done and deployed.
2. Make image.bbclass install its artifacts into whatever recipe DEPENDS on it.
3. Make fitimage a bbclass that could be added to IMAGE_CLASSES.

Bartosz