[OE-core] Solving a circular dependency issue between the main image and initramfs
Bartosz Golaszewski
brgl at bgdev.pl
Tue Mar 17 13:26:37 UTC 2020
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 can understand some circular dependencies could creep in as many
> configurations have the initramfs as part of the main image but if you
> don't configure that, you shouldn't see those dependencies.
>
I think there are more problems with this and the main reason is the
fact that wic is just a regular image type. I'd argue it should be its
own recipe since it can fetch deployed files from multiple recipes
(including different images - for instance if we wanted to build a
special recovery image that would need to include the main image +
minimal rootfs).
First: the initramfs recipe needs to access an artifact generated by
do_image_ext4 from the main image. If we're not running do_install
from image.bbclass (which we currently don't), this can only happen
after do_image_complete which does the sstate deployment. So
initramfs.do_image_ext4 depends on rootfs.do_image_complete. Next the
kernel bbclass needs the initramfs image to assemble the fitimage - so
kernel.do_assemble_fitimage_initramfs depends on
initramfs.do_image_complete. Next we have the inter-dependencies
between the kernel and u-boot because we need to sign the fitImage for
dm-verity to make sense. Currently u-boot.do_build depends on
kernel.do_deploy. And then the culprit: rootfs.do_image_wic needs to
fetch the boot files so it depends on u-boot.do_deploy but
rootfs.do_image_complete runs after rootfs.do_image_wic. I guess if we
made wic a separate recipe - not just an image type, it could help
here.
> I do fear your "re-enable" do_install route isn't going to get you
> where you want to be.
>
Why not? This is what currently happens with the dependencies between
fitimage <-> u-boot when UBOOT_SIGN_ENABLE is set to "1". U-boot
installs the DTB image - that would normally be deployed - into the
/usr/share directory of kernel's sysroot.
> Can you give a simple example of how you reproduce the circular
> dependencies with standard poky or oe-core? That might let others give
> comment more easily.
>
It's very simple: add an initramfs to the recipe (INITRAMFS_IMAGE =
"some-image") and add the following to some-image.bb recipe:
do_rootfs[depends] += "core-image-minimal:do_image_complete" with the
assumption that you're building core-image-minimal. You also need
"wic" in IMAGE_FSTYPES.
Best regards,
Bartosz Golaszewski
More information about the Openembedded-core
mailing list