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.
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 ?
setting to need info to get that test run. I haven't reproduced this locally, but still trying to move this along.
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...
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...
Agreed to try to find a test case.
(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
Can not reproduce it here. If someone can provide a testcase then reopen this bug.