[OE-core] [PATCH 1/2] kernel-initramfs.bbclass: Separate initramfs setup

[Andrea Adami]

</cut>

> > > Hello,
> > >
> > > so I applied both patches and had to comment out (as expected) the
> > > INITRAMFS_TASK.
> > > I have added INITRAMFS_IMAGE_BUNDLE in my 2nd kernel recipe but last
> > > night build did fail: the initramfs.cpio.xz was not found.
> > >
> > > I did only scrub the last lines... will debug later.
> > >
> >
> > Ok, so the problem is copy_initramfs() is done too late and do_compile fails
> >
> > |   /tmp/build/tmp-musl/work-shared/spitz/kernel-source/scripts/gen_initramfs_list.sh:
> > Cannot open 'initramfs.cpio.xz'
> > | /tmp/build/tmp-musl/work-shared/spitz/kernel-source/usr/Makefile:73:
> > recipe for target 'usr/initramfs_data.cpio.xz' failed
> >
> >
> > do_compile log before
> >
> > 1 DEBUG: Executing shell function do_compile
> > 2 Copying initramfs into ./usr ...
> > 3 gzip decompressing image
> > 4 Finished copy of initramfs into ./usr
> > 5 NOTE: make -j ...
> >
> > do_compile with patch applied (build fails):
> >
> > 1 DEBUG: Executing shell function do_compile
> > 2 NOTE: make -j ...
> >
> > Please check again the task order. Thanks.
>
> So the task order is copied from the previous bundle setup (and needs
> to work that way in order to prevent recursive dependency between
> kernel do_install -> image -> initramfs_copy). When I mentioned that
> this should behave similar to your existing setup I did mean there
> were some differences. Specifically you would no longer need to
> CONFIG_INITRAMFS_SOURCE in your kernel config. But in order to get the
> initramfs kernel you would need to get the image generated from the
> bundle. This is deployed separately to the base image type binary
> (<imagetype> vs <imagetype>-initramfs-<machine>.bin). I suspect this
> might be problematic for you to change to? And as such would make it a
> pain to switch away from INITRAMFS_TASK.
>
> Just looking at the task setup again, it might be relatively straight
> forward to keep the INITRAMFS_TASK setup. Where the initramfs_copy
> task is simply set as a dep for the do_compile in only that case (but
> would break the use of BUNDLE in the same kernel). Would you prefer to
> try and keep the INITRAMFS_TASK behaviour working?
>
> Thanks,
> Nathan

Nathan,

if possible I would prefer to adapt our legacy implementation but I
think the whole bundling as intended cannot be done for the 2nd
kernel.
What we want to keep is the possibility to build a 2nd
initramfs-filled kernel living in its recipe without touching
local.conf.

Thus I'd say for the moment please keep the old INITRAMFS_TASK hook.
Thanks

Andrea

<cut>