In the following sequence: bitbake virtual/kernel bitbake virtual/kernel -c clean bitbake virtual/kernel bitbake virtual/kernel -c menuconfig bitbake virtual/kernel The user would expect their newly configured kernel to be built. In reality, the last step just installs from sstate and therefore does nothing with the new configuration. Somehow, we need to prevent sstate from taking effect in the last step.
So many other steps seem to invalidate the later steps so bitbake knows to rerun them. Is this just a matter of killing the stamp files for the do_compile during the do_menuconfig task?
Sadly not. The issue is that bitbake has no knowledge that -c menuconfig invalidates the configuration. It sees the same sstate hash for populate_sysroot so "accelerates" the build. I suspect we're going to have to set some kind of new "no sstate" flag against the recipe so it doesn't touch sstate even if the checksum would apparently match. Of course the next issue is you could "corrupt" a sstate cache this way if generated sstate code was then shared. I guess the above "no sstate" flag would need to disable sstate generation too.
RP, I'm not sure I fully follow what you're suggesting. You aren't suggesting we disable all sstate usage by linux kernel recipes are you?
(In reply to comment #3) > RP, I'm not sure I fully follow what you're suggesting. You aren't suggesting > we disable all sstate usage by linux kernel recipes are you? Once menuconfig was used.
Release Note: If you change the config during a build, bitbake may not detect the change and will not rebuild the kernel. After changing the config, be sure to force a kernel recompile: $ bitbake virtual/kernel -c menuconfig $ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel
*** Bug 2350 has been marked as a duplicate of this bug. ***
Note that the workaround in Comment 5 is insufficient and should read: Due to an issue with sstate and the menuconfig task for recipes such as Linux kernels and busybox, it is necessary to clean sstate prior to re-configuring and rebuilding the recipe. For example: $ bitbake virtual/kernel -c cleansstate $ bitbake virtual/kernel -c menuconfig $ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel
Unfortunately this does not only apply to menuconfig. The following scenario also does not work bitbake virtual/kernel modify a kernel source file bitbake -ccompile -f virtual/kernel bitbake virtual/kernel The latter does not run do_install This is on ppc I tried the cleansstate solution, as suggested by Darren in comment 7 but unfortunately cleansstate implies clean so it removes the whole tree (including the modified file).
I've sent out some patches to fix this - one as part of a series to bitbake-devel and another to the oe-core list.
While running the examples in the YP Development Manual I hit this bug against the YP 1.1.2 version. This is surprising as it was not there for 1.1.1 and had originally surfaced during YP 1.2.
Fix merged to master in revisions 5bd11a9bf329217f312076f347b045b5c09f19b2 and 66123b92557a7c1d63c29e90d9a8ba4ef146fc8a. Note that to work this does require that you use fully signature based stamps (i.e. BB_SIGNATURE_HANDLER = "OEBasicHash"), which is the default in poky.
Verified that the sequence in the bug description is working as expected Commit: 3309cf42d314f0a26079a11836c6b9b9bb5f253e
Hi, Unless I am doing something wrong, this bug is still present in Yocto 1.7. The described sequence in the bug report still produces a kernel with the old configuration and the workarround in comment 5 doesn't work. A workarround that seems to work is the following: bitbake -c menuconfig linux-yocto bitbake -C compile linux-yocto (notice the upper case C option) Feel free to ask me if you need more informations. Regards