</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> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core