Building multiple kernel recipes has a number of issues related to overwriting existing files. The deploy targets are one such example. Each kernel.bbclass recipe wants to deploy to bzimage and bzimage-machinename. While these are symlinks, their targets also only include version information, which could potentially be the same across recipes as well. I propose we include the PN in the deploy target: bzImage_linux-yocto bzImage_linux-yocto-rt
Maybe this bug is related to what I'm seeing. I'm jumping between building two kernels, "linux-imx" and "linux-imx-rt". I have two kernel ipks under deploy/ipk/: [jkroon@localhost oe-devel]$ ls build/tmp-eglibc/deploy/ipk/wandboard_dual/kernel-3* build/tmp-eglibc/deploy/ipk/wandboard_dual/kernel-3.10.17-monkey+gec1af9f_3.10.17-r0_wandboard_dual.ipk build/tmp-eglibc/deploy/ipk/wandboard_dual/kernel-3.10.17-rt12-monkey+gec1af9f_3.10.17-r0_wandboard_dual.ipk Even when I have PREFERRED_PROVIDER_virtual/kernel = "linux-imx-rt" I get: [jkroon@localhost oe-devel]$ cat build/buildhistory/images/wandboard_dual/eglibc/core-image-monkey/installed-packages.txt | grep kernel-3 kernel-3.10.17-monkey+gec1af9f_3.10.17-r0_wandboard_dual.ipk , it picks the non-rt kernel for the rootfs.
That is more of a packaging issue, and there are many more issues within the system with respect to working with multiple kernels in the same build tree. If you clean the kernel, then change the provider, and build - do you still see this issue? (But this is a separate issue from the one described in this bug)
Yes, cleaning sstate for the old kernel, and then building the image with the new kernel as preferred provider works as expected. I was just suprised when it happened, and searching for "multiple kernel" in bugzilla, this bug looked like the best match. But maybe I should file a new bug then ?
Your bug is more generic than you might think. Consider Bug 4102.
Automatic invaldid sstate remove means this no longer happens.