Created attachment 3912 [details] devtool output Running 'devtool modify linux-yocto' in esdk genenrates taskhash errors for all tasks after fetch. Steps to re-create ================== First build esdk installer $ cd /home/hbruce/poky $ git clone -b pyro git://git.yoctoproject.org/poky $ source poky/oe-init-build-env $ bitbake core-image-minimal -c populate_sdk_ext Then in a new shell, install esdk and prepare to modify linux-yocto $ /tmp/deploy/sdkpoky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.3.1.sh -d /home/hbruce/esdk $ cd /home/hbruce/esdk $ source environment-setup-i586-poky-linux $ devtool modify linux-yocto Parsing recipes: 100% |##########################################| Time: 0:00:05 Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 48 skipped, 0 masked, 0 errors. Loading cache: 100% |############################################| Time: 0:00:00 Loaded 1299 entries from dependency cache. NOTE: Executing RunQueue Tasks NOTE: Executing do_fetch... NOTE: Executing do_unpack... ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus 997de1272b220be7444b29274fe9a887 for /home/hbruce/Tools/yocto/qemu/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack devtool will continue with similar task taskhash errors for all subsequent tasks, see log in attachment. Workaround ========== Ignore errors. devtool build seems to work OK.
Same behavior is seen with MACHINE = "genericx86-64". And if meta-intel layer is used, MACHINE = "intel-corei7-64".
For the documentation component of this bug what are we going to do? Do we want to document the task hash errors as part of the devtool modify command and say they are not really errors? Scott
I flagged this issue in https://wiki.yoctoproject.org/wiki/TipsAndTricks/KernelDevelopmentWithEsdk
I'm seeing the same thing, but in my case the ESDK is not working OK: [clsulliv@clsulliv poky_sdk2]$ devtool modify linux-yocto NOTE: Starting bitbake server... NOTE: Starting bitbake server... NOTE: Starting bitbake server... Loading cache: 100% |###################################################################################| Time: 0:00:00 Loaded 1266 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Initialising tasks: 100% |##############################################################################| Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 18 tasks of which 18 didn't need to be rerun and all succeeded. NOTE: Executing do_fetch... ERROR: Taskhash mismatch aa1ac05b17760a623ee5b30846db3fd6 versus 16dcd4dd44f4f578a5d178c32a3509d8 for /home/clsulliv/poky_sdk2/layers/build/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_fetch ERROR: Taskhash mismatch aa1ac05b17760a623ee5b30846db3fd6 versus 16dcd4dd44f4f578a5d178c32a3509d8 for /home/clsulliv/poky_sdk2/layers/build/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_fetch NOTE: Executing do_unpack... ERROR: Taskhash mismatch 50dc674cab290d62fad2b82cdca71db3 versus f4e360d6315510bea8319759d0cabb77 for /home/clsulliv/poky_sdk2/layers/build/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_unpack ERROR: Taskhash mismatch 50dc674cab290d62fad2b82cdca71db3 versus f4e360d6315510bea8319759d0cabb77 for /home/clsulliv/poky_sdk2/layers/build/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_unpack ERROR: An error occurred during do_unpack, exiting [clsulliv@clsulliv poky_sdk2]$ ls workspace/sources/ Its not linux-yocto specific, as the same errors occur with other recipes, and I still don't get anything in my sources directory. E.g., busybox. This occurred with the following 2.4m3 ESDK: https://autobuilder.yocto.io/pub/releases/yocto-2.4_M3.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.sh
Hi, I am experiencing the same issues today while trying to run devtool modify virtual/kernel. It craps out on an error. scottrif@scottrif-ThinkPad-T460:~/snap_poky_sdk$ devtool modify virtual/kernel NOTE: Starting bitbake server... NOTE: Starting bitbake server... Loading cache: 100% |#############################################################################################| Time: 0:00:00 Loaded 1267 entries from dependency cache. WARNING: No bb files matched BBFILE_PATTERN_my-kernel '^/home/scottrif/snap_poky_sdk/layers/meta-my-kernel/' Summary: There was 1 WARNING message shown. NOTE: Mapping virtual/kernel to linux-yocto WARNING: No bb files matched BBFILE_PATTERN_my-kernel '^/home/scottrif/snap_poky_sdk/layers/meta-my-kernel/' NOTE: Resolving any missing task queue dependencies Initialising tasks: 100% |########################################################################################| Time: 0:00:00 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 18 tasks of which 18 didn't need to be rerun and all succeeded. NOTE: Executing do_fetch... ERROR: Taskhash mismatch 2138a94fc4b4965538453d26eff9074a versus 16dcd4dd44f4f578a5d178c32a3509d8 for /home/scottrif/snap_poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_fetch ERROR: Taskhash mismatch 2138a94fc4b4965538453d26eff9074a versus 16dcd4dd44f4f578a5d178c32a3509d8 for /home/scottrif/snap_poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_fetch NOTE: Executing do_unpack... ERROR: Taskhash mismatch 50dc674cab290d62fad2b82cdca71db3 versus f4e360d6315510bea8319759d0cabb77 for /home/scottrif/snap_poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_unpack ERROR: Taskhash mismatch 50dc674cab290d62fad2b82cdca71db3 versus f4e360d6315510bea8319759d0cabb77 for /home/scottrif/snap_poky_sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb.do_unpack ERROR: An error occurred during do_unpack, exiting
Fixes merged to master that have now resolved this: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=10af6d86b3effc523cfa0ec49741c5b02ee2cf86 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3fde63363ab90672d6baf204c2b2dca98320fe7d Note that the underlying cause is separate and covered by bug 12066, however we want the signatures properly unlocked in this case anyway.
Ok - I don't think there is a documentation component to this issue. I am setting the doc flag to "No." Thanks, Scott