wt., 17 mar 2020 o 14:45 Quentin Schulz <[email protected]> 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 > > <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
