2256 2012-04-06 17:40:08 +0000 kernel menuconfig confusion with sstate 2015-03-26 12:36:43 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple VERIFIED FIXED (P1) (fixed) - 25 June 2012 Medium normal 1.3 M2 1 richard.purdie bluelightning bluelightning bruce.ashfield dvhart fransmeulenbroeks jason.wessel jessica.zhang laurentiu.serban poky.bs.watcher poky.watcher sgw song.liu srifenbark tom.zanussi ysoubeyrand --- --- No (bug/feature does not impact docs) oldest_to_newest 20016 0 richard.purdie 2012-04-06 17:40:08 +0000 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. 20020 1 dvhart 2012-04-06 18:40:57 +0000 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? 20030 2 richard.purdie 2012-04-07 20:26:22 +0000 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. 20071 3 dvhart 2012-04-09 16:20:19 +0000 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? 20148 4 richard.purdie 2012-04-10 19:59:45 +0000 (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. 20743 5 dvhart 2012-04-19 23:23:49 +0000 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 20801 6 richard.purdie 2012-04-22 14:36:01 +0000 *** Bug 2350 has been marked as a duplicate of this bug. *** 21107 7 dvhart 2012-05-04 15:22:01 +0000 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 21310 8 fransmeulenbroeks 2012-05-11 13:07:47 +0000 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). 21311 9 fransmeulenbroeks 2012-05-11 13:08:41 +0000 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). 22288 10 bluelightning 2012-06-18 16:34:09 +0000 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. 22428 11 srifenbark 2012-06-20 16:07:37 +0000 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. 22544 12 bluelightning 2012-06-25 16:29:40 +0000 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. 23663 13 laurentiu.serban 2012-07-31 15:30:36 +0000 Verified that the sequence in the bug description is working as expected Commit: 3309cf42d314f0a26079a11836c6b9b9bb5f253e 49802 14 ysoubeyrand 2015-03-26 12:36:43 +0000 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