Bug 5320

Summary:	Kernel patches not always applied
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Peter Kjellerstedt <peter.kjellerstedt>
Component:	kernel	Assignee:	Nitin Kamble <nitin.a.kamble>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Medium	CC:	bruce.ashfield, sgw, tom.zanussi
Version:	1.5
Target Milestone:	1.5.1
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Peter Kjellerstedt 2013-10-04 16:57:09 UTC

We have been experiencing a problem randomly where it seems a kernel patch we have is not applied and the build consequently fails. Today I finally managed to trigger it with BB_VERBOSE_LOGS enabled so that I could see what was happening while the kernel was being built. After a lot of debugging I think I finally understand what is going on and have managed to come up with a way to repeatedly recreate the problem.

Some preconditions:
* we use a custom kernel retrieved from our own Git server
* we have one patch specified in the SRC_URI
* KMETA is not set
* SRCREV_machine is set to a SHA-1 that matches the HEAD of origin/master of the kernel

If I first do a full "bitbake core-image-minimal" without any sstate cache, everything works as expected. In the kernel work directory I get a linux/.meta directory and the patch is applied as expected on the local master branch.

Then, to trigger the problem, all I need to do is:
* bitbake -f -c kernel_checkout <our linux recipe>
* bitbake -f -c patch <our linux recipe>

Doing this also triggers the validate_branches task before the patch task, which effectively reverts the local master back to the SHA-1 specified in SRCREV_machine, undoing what the previous patch task had done when originally building the kernel. However, the subsequent patch task does not recognize this and proceeds without doing anything as it thinks the patch is already applied...

I hope this is enough information for you to be able to recreate the problem, but I will be happy to provide any more information that you need.

Comment 1 Bruce Ashfield 2013-10-04 17:03:35 UTC

I have some recent experience with a similar issue. There's a fix I can propose, and a full
one in the 1.6 timeframe.

Can you temporarily set your SRCREV to AUTOREV and retry ?

Comment 2 Bruce Ashfield 2013-10-08 17:48:31 UTC

setting to need info to get that test run. I haven't reproduced this locally, but still
trying to move this along.

Comment 3 Peter Kjellerstedt 2014-04-10 11:28:08 UTC

We no longer need to patch the version of our kernel that we use, so I do not have a test case any more. However, I believe the problem is still there so I am reluctant to close the ticket...

Comment 4 Bruce Ashfield 2014-04-10 12:33:53 UTC

I'm fine with leaving it open. We'll see if it pops up again.

(In reply to comment #3)
> We no longer need to patch the version of our kernel that we use, so I do
> not have a test case any more. However, I believe the problem is still there
> so I am reluctant to close the ticket...

Comment 5 Stephen K Jolley 2014-05-29 15:19:05 UTC

Agreed to try to find a test case.

Comment 6 Nitin Kamble 2014-05-29 15:31:28 UTC

(In reply to comment #3)
> We no longer need to patch the version of our kernel that we use, so I do
> not have a test case any more. However, I believe the problem is still there
> so I am reluctant to close the ticket...

Hi Peter, 
  This bug needs a test case to make any progress. Is it possible for you to create a testcase for this bug?

Thanks,
Nitin

Comment 7 Nitin Kamble 2014-06-18 01:53:43 UTC

Can not reproduce it here. If someone can provide a testcase then reopen this bug.