Created attachment 4364 [details] Proposed fix for kernel.bbclass not asserting that bundled initramfs image exists The code in kernel.bbclass does a few things wrong: 1) If ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio does not exist, nor any of the compressed variants, nothing is copied to kernel build's ./usr directory. The code does not fail, but silently proceeds without a bundled initramfs. (Or, an older initramfs that was copied in ./usr earlier.) The expected outcome is that the build stops ("die") because the user explicitly set both INITRAMFS_IMAGE="some-name" and INITRAMFS_IMAGE_BUNDLE = "1" Typical use-case is when the user has set INITRAMFS_IMAGE but not has set INITRAMFS_IMAGE_NAME. (The kernel class will create INITRAMFS_IMAGE_NAME from INITRAMFS_IMAGE appending "-${MACHINE}" by default, which might not be what the user did.) 2) If an initramfs is found, contrary to the comments, it does not stop at the first uncompressed/compressed cpio image found. Instead it keeps processing all. (This is a much less critical bug.)
I have given this more thoughts and tests. I think we should also delete the existing ./usr/${INITRAMFS_IMAGE_NAME}.cpio in the build, before we are copying the to-be-bundled initramfs image. This way, we can be certain that the final check [ -f ./usr/${INITRAMFS_IMAGE_NAME}.cpio ] checks for a *copied* initramfs, rather then possibly a left-over. (This can happen when the user is explicitly running separate tasks.) We want to bundle task to be stand-alone-correct.
(In reply to comment #1) > I have given this more thoughts and tests. I think we should also delete the > existing ./usr/${INITRAMFS_IMAGE_NAME}.cpio in the build, before we are > copying the to-be-bundled initramfs image. > Foget this remark, as this actually already happens. It's the check whether a new initramfs image was copied that is missing and that is important to have.
Created attachment 4365 [details] Updated fix with more clear user message, telling what might be wrong.
Please send the patch to openembedded-core@lists.openembedded.org as we don't accept patches via bugzilla.
Leon, can you post this to the list please?
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a5b7c86f23110cad2aa1d4ee378058ca1eb5f1c1
back ported to stable/thud-next http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=stable/thud-next&id=ec52ff0ddc11bbfe226da528dfdc8bb75615530f
do we need for sumo?