Bug 6043

Summary:	Deploy images collide across kernel recipes
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Darren Hart <dvhart>
Component:	kernel	Assignee:	Unassigned <unassigned>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	bruce.ashfield, jacob.kroon, randy.macleod, tim.orling, tom.zanussi
Version:	1.6
Target Milestone:	Future
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description Darren Hart 2014-03-25 16:35:43 UTC

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

Comment 1 Jacob Kroon 2014-03-31 07:08:00 UTC

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.

Comment 2 Darren Hart 2014-03-31 19:33:33 UTC

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)

Comment 3 Jacob Kroon 2014-03-31 20:02:47 UTC

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 ?

Comment 4 Darren Hart 2014-03-31 20:17:07 UTC

Your bug is more generic than you might think. Consider Bug 4102.

Comment 5 Randy MacLeod 2021-04-08 15:19:48 UTC

Automatic invaldid sstate remove means this no longer happens.