6043 2014-03-25 16:35:43 +0000 Deploy images collide across kernel recipes 2021-04-08 15:19:48 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 1.6 x86 Multiple RESOLVED FIXED Medium enhancement Future 1 dvhart unassigned bruce.ashfield jacob.kroon randy.macleod tim.orling tom.zanussi --- --- Yes (doc changes required) oldest_to_newest 41712 0 dvhart 2014-03-25 16:35:43 +0000 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 41932 1 jacob.kroon 2014-03-31 07:08:00 +0000 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. 41983 2 dvhart 2014-03-31 19:33:33 +0000 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) 41984 3 jacob.kroon 2014-03-31 20:02:47 +0000 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 ? 41985 4 dvhart 2014-03-31 20:17:07 +0000 Your bug is more generic than you might think. Consider Bug 4102. 89906 5 randy.macleod 2021-04-08 15:19:48 +0000 Automatic invaldid sstate remove means this no longer happens.