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

Quentin Schulz quentin.schulz at streamunlimited.com
Tue Mar 17 13:45:36 UTC 2020


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


More information about the Openembedded-core mailing list