5320 2013-10-04 16:57:09 +0000 Kernel patches not always applied 2014-07-21 16:34:17 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 1.5 x86 Multiple RESOLVED WONTFIX Medium normal 1.5.1 1 peter.kjellerstedt nitin.a.kamble bruce.ashfield sgw tom.zanussi --- --- Don't know oldest_to_newest 37646 0 peter.kjellerstedt 2013-10-04 16:57:09 +0000 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. 37647 1 bruce.ashfield 2013-10-04 17:03:35 +0000 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 ? 37752 2 bruce.ashfield 2013-10-08 17:48:31 +0000 setting to need info to get that test run. I haven't reproduced this locally, but still trying to move this along. 42512 3 peter.kjellerstedt 2014-04-10 11:28:08 +0000 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... 42520 4 bruce.ashfield 2014-04-10 12:33:53 +0000 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... 43663 5 sjolley.yp.pm 2014-05-29 15:19:05 +0000 Agreed to try to find a test case. 43668 6 nitin.a.kamble 2014-05-29 15:31:28 +0000 (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 44048 7 nitin.a.kamble 2014-06-18 01:53:43 +0000 Can not reproduce it here. If someone can provide a testcase then reopen this bug.