Created attachment 3566 [details] esdk_log An error in the execution of eSDK instal script appeared while running eclipse testcases for 2.3 M1. Steps: 1. Downloaded 2.3 M1 rc1 install script from: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh 2. Changed permissions to allow execution 3. Ran poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh script with all the default options. Expected Results: The SDK installs correctly with no errors Actual Results: Plenty of errors appeared: "Task X attempted to execute unexpectedly" Notes: Attaching log file
Seeing a similar issue on AB, also for eSDK build. The branch is ross/mut2 though... https://autobuilder.yoctoproject.org/main/builders/nightly-oecore/builds/1013/steps/BuildImages_1/logs/stdio --- NOTE: recipe core-image-minimal-1.0-r0: task do_populate_sdk_ext: Started ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Failed to generate filtered task list for extensible SDK: ### Shell environment set up for builds. ### You can now run 'bitbake <target>' Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support You can also run generated qemu images with a command like 'runqemu qemux86' ERROR: bitbake failed: Parsing recipes...done. Parsing of 848 .bb files complete (0 cached, 848 parsed). 1303 targets, 86 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Initialising tasks...done. NOTE: Executing SetScene Tasks NOTE: Running setscene task 7 of 533 (virtual:native:/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oecore/build/build/tmp-glibc/work/qemuarm-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/build/meta/recipes-core/zlib/zlib_1.2.8.bb:do_populate_lic_setscene) (...skipped hundreds of "Running setscene task" lines...) NOTE: Running setscene task 533 of 533 (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oecore/build/build/tmp-glibc/work/qemuarm-oe-linux-gnueabi/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/build/meta/recipes-devtools/quilt/quilt-native_0.64.bb:do_populate_sysroot_setscene) NOTE: Executing RunQueue Tasks ERROR: Task unfs3-native.do_fetch attempted to execute unexpectedly ERROR: Task unfs3-native.do_unpack attempted to execute unexpectedly ERROR: Task unfs3-native.do_patch attempted to execute unexpectedly ERROR: Task unfs3-native.do_configure attempted to execute unexpectedly ERROR: Task unfs3-native.do_compile attempted to execute unexpectedly ERROR: Task unfs3-native.do_install attempted to execute unexpectedly ERROR: Task unfs3-native.do_populate_sysroot attempted to execute unexpectedly and should have been setscened NOTE: Tasks Summary: Attempted 1577 tasks of which 1577 didn't need to be rerun and all succeeded. Summary: There were 7 ERROR messages shown, returning a non-zero exit code. ---------- NOTE: "attempted to execute unexpectedly and should have been setscened" errors indicate this may be caused by missing sstate artifacts that were likely produced in earlier builds, but have been subsequently deleted for some reason. ERROR: core-image-minimal-1.0-r0 do_populate_sdk_ext: Function failed: copy_buildsystem ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oecore/build/build/tmp-glibc/work/qemuarm-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_populate_sdk_ext.7929 NOTE: recipe core-image-minimal-1.0-r0: task do_populate_sdk_ext: Failed ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oecore/build/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext) failed with exit code '1'
Humberto: What system/environment was this in? What else had you done previously? I pulled the same installer and it worked fine on ubuntu-14.04. Jussi: The AB error you point to is a failure of bitbake to create the esdk while Humberto's is the installer itself failing because it can't use the sstate to repopulate the sysroot (for a bunch of things including quilt-native). do you think these stem from a related issue?
I see the failure on Debian 8 host
Brian: I have a Fedora 24. I didn't do anything special, just downloaded the file, added running permissions and ran it with all defaults options.
I've run some tests on my Fedora machine, using the procedure documented here to access the bitbake environment internal to the SDK: https://wiki.yoctoproject.org/wiki/Extensible_SDK_Debugging Since core-image-sato is the image the SDK was built for, I used the brute-force method of running: BB_SETSCENE_ENFORCE=1 bitbake -n core-image-sato then I worked backwards re-running it on selected tasks the list it reported until I got all the way to texinfo-dummy-native:do_populate_sysroot which is very early on in the build. I then added -DDD to the command line and found this: ----- snip ----- DEBUG: SState: Looked for but didn't find file /home/paul/poky_sdk_ab/sstate-cache/universal/26/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:26eafe7eadb99d79214e9d6fad514926_populate_sysroot.tgz DEBUG: SState: Looked for but didn't find file /home/paul/poky_sdk_ab/sstate-cache/universal/d8/sstate:texinfo-dummy-native:x86_64-linux:1.0:r0:x86_64:3:d8db362619aacdddbba99c63b4b8148c_populate_sysroot.tgz ----- snip ----- Since the native sstate packages shipped within the eSDK can actually be found in sstate-cache/universal-4.8 (and not sstate-cache/universal where the message reports bitbake looking) that tells me that the uninative NATIVELSBSTRING values are different. This suggests that this recent commit may be responsible: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c21cec84886d9c70396e9be0ceb9a8ef300b54be I'm not sure why we are getting a version in the NATIVELSBSTRING we use to build it and not in the SDK, but whatever the cause, we need to have a way for the eSDK to be installable on distros regardless of the gcc version in use, or it's going to be much less useful even if it didn't break horribly like this.
(In reply to comment #2) > Jussi: The AB error you point to is a failure of bitbake to create the esdk > while Humberto's is the installer itself failing because it can't use the > sstate to repopulate the sysroot (for a bunch of things including > quilt-native). do you think these stem from a related issue? No, not really. I don't understand the issue very well so was just looking at the output and seeing similar messages. Also apparently mut builds sometimes do this so feel free to forget my comment.
We had similar issues with my uninative patch, but Ross fixed them. Ross, can you point us out to your fix?
I can't reproduce this on my OpenSUSE 13.2 machine (gcc version 4.8.3): $ wget http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh --2016-12-23 15:33:41-- http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh Resolving proxy-chain.intel.com (proxy-chain.intel.com)... 163.33.7.139 Connecting to proxy-chain.intel.com (proxy-chain.intel.com)|163.33.7.139|:911... connected. Proxy request sent, awaiting response... 200 OK Length: 2952023807 (2.7G) [text/x-sh] Saving to: ‘poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh’ poky-glibc-x86_64-core-image-sato-i586-toolch 100%[================================================================================================>] 2.75G 1.56MB/s in 33m 55ss 2016-12-23 16:07:37 (1.38 MB/s) - ‘poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh’ saved [2952023807/2952023807] [ed@vmed build (master)]$ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh [ed@vmed build (master)]$ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.2 ========================================================================== Enter target directory for SDK (default: ~/poky_sdk): You are about to install the SDK to "/home/ed/poky_sdk". Proceed[Y/n]? Extracting SDK...........................................................................................................................done Setting it up... Extracting buildtools... Preparing build system... Parsing recipes: 100% |###############################################################################################################################################| Time: 0:00:15 Initialising tasks: 100% |############################################################################################################################################| Time: 0:00:13 done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /home/ed/poky_sdk/environment-setup-i586-poky-linux
I can't reproduce this on Fedora 24: $ cat /etc/redhat-release Fedora release 24 (Twenty Four) $ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.2.sh Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.2 ========================================================================== Enter target directory for SDK (default: ~/poky_sdk): The directory "/home/ed/poky_sdk" already contains a SDK for this architecture. If you continue, existing files will be overwritten! Proceed[y/N]? y Extracting SDK...........................................................................................................................done Setting it up... Extracting buildtools... Preparing build system... Parsing recipes: 100% |###############################################################################################################################################| Time: 0:00:11 Initialising tasks: 100% |############################################################################################################################################| Time: 0:00:15 done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /home/ed/poky_sdk/environment-setup-i586-poky-linux
Reproduced on Debian 8 (gcc version 4.9.2)
Also reproduced on Fedora 24. What's happening: commit c21cec84886d9c70396e9be0ceb9a8ef300b54be added the concept of basing the uninative sstate-cache into uninative, uninative-4.8 and uninative-4.9. The 4.8 and 4.9 represent the gcc versions of the HOST default gcc compiler. This was in order to fix bug 10441. Unfortunately, this results in the esdk installer failing because as part of it's installation, the esdk installer repopulates a sysroot from the sstate it has packed inside. Since the build machine could be sstate-cache/uninative-4.9 while the install machine could be gcc-4.8 this results in a sstate-cache miss. In the case of a standard oe/poky environment, this just means that the native code is rebuilt on the fly and then the example would have a sstate-cache/uninative-4.8 and sstate-cache/uninative-4.9. In the case of the esdk, however, the sstate extraction is run with the env variable BB_SETSCENE_ENFORCE=1. This means that a sstate-cache miss is an error. Since the esdk is intended to provide a repeatable platform, this is in keeping with my understanding of the intended behaviour. I am (running tests to verify atm) planning to send a patch to the ml which reverts the above commit. This will force bug 10441 to reopen but will allow the esdk to install. One possibility for a longer term fix is to reimplement the above commit and add checks to the esdk installer so that it errors out if the host gcc version and the esdk version differ. we would also have to provide esdk-4.8, esdk-4.9 and esdk-5/6 versions of the installer to cover this.
(In reply to comment #11) > I am (running tests to verify atm) planning to send a patch to the ml which > reverts the above commit. This will force bug 10441 to reopen but will allow > the esdk to install. One possibility for a longer term fix is to reimplement > the above commit and add checks to the esdk installer so that it errors out > if the host gcc version and the esdk version differ. we would also have to > provide esdk-4.8, esdk-4.9 and esdk-5/6 versions of the installer to cover > this. We may be able to add in sstate mirror urls so that on 5.x, 4.8 and 4.9 work and on 4.9, 4.8 works. That would mean the sdk would only have to error if it was being installed on a machine where the gcc was older than the available sstate...
Added SSTATE_MIRRORS as suggested: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/130742.html It caused yet another failure, which is hopefully fixed by this patch: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/130743.html
both fixes have been merged to poky master: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e30f5002c4f216757ace27ad8d06164716ca46b5
Created attachment 3676 [details] SDK installs script without errors
BUILD: 2.3.m3.rc1: 6e20b31d5d17133e0fca086e12a0ad06ab5c4cc8 ENVIRONMENT: genericx86-64 on NUC Expected Results: The SDK installs correctly with no errors Actual Results: The SDK installs correctly with no errors Notes: Attaching log file
I see this on 2.3.1.rc2 6bd890d9e011014cf323e61267f8b256949d44aa
Created attachment 3876 [details] log_new
For issues like this, please create a new bug, don't reopen an old one which was confirmed as resolved. It may or may not be a related issue. Also, please include a link to where the failure was observed. For example, was this a failure at installation time of an eSDK (in which case which one was it)?
also please include additional information: link to esdk installer that failed and host system type (fedora 24 for example)
(In reply to comment #20) > also please include additional information: > link to esdk installer that failed > and host system type (fedora 24 for example) Yes, sure. I've downloaded the installer from : https://autobuilder.yocto.io/pub/releases/yocto-2.3.1.rc2/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.1.sh Reproduced on Debian 8 I've done the same steps: Download the file, changed permissions, and run poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.1.sh with all the default options.
(In reply to comment #19) > For issues like this, please create a new bug, don't reopen an old one which > was confirmed as resolved. It may or may not be a related issue. Also, > please include a link to where the failure was observed. For example, was > this a failure at installation time of an eSDK (in which case which one was > it)? Yes this failure was at installation of an eSDK script, I've downloaded the file: https://autobuilder.yocto.io/pub/releases/yocto-2.3.1.rc2/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.1.sh , it fails following the same steps, giving the same errors. I've reopened this bug in particular because it has reappeared in the same branch, I thought that would be easier to solve if there is already a preliminary investigation.
I tried this on a ubuntu:16.04 container and a debian:8 container. On the ubuntu-16.04 container it worked fine. Ubuntu:16.04 gcc version is 5.4.0. On the debian:8 container I got the following legitimate error: cow222@a497d06ec6fb:/home/bavery/src/myBugs/esdk-10832$ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.1.sh Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1 ============================================================================ Error: Incompatible SDK installer! Your host gcc version is 4.9 and this SDK was built by gcc higher version. cow222@a497d06ec6fb:/home/bavery/src/myBugs/esdk-10832$ gcc --versio gcc (Debian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ------------------------------- So, since my results were quite different: 1) what is your gcc --version return? 2) what does /bin/sh actually link to? 3) Have you changed any host side configuration?
(In reply to comment #23) > I tried this on a ubuntu:16.04 container and a debian:8 container. > On the ubuntu-16.04 container it worked fine. Ubuntu:16.04 gcc version is > 5.4.0. > > > On the debian:8 container I got the following legitimate error: > cow222@a497d06ec6fb:/home/bavery/src/myBugs/esdk-10832$ > ./poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.1.sh > Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.3.1 > ============================================================================ > Error: Incompatible SDK installer! Your host gcc version is 4.9 and this SDK > was built by gcc higher version. > cow222@a497d06ec6fb:/home/bavery/src/myBugs/esdk-10832$ gcc --versio > gcc (Debian 4.9.2-10) 4.9.2 > Copyright (C) 2014 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ------------------------------- > So, since my results were quite different: > 1) what is your gcc --version return? > 2) what does /bin/sh actually link to? > 3) Have you changed any host side configuration? My gcc version is 4.9.2 I manually set SDK_GCC_VER=’ -4.10’ in the script to solve the incompatibility error, (I comment on it in Bug 11471)
(In reply to comment #24) > My gcc version is 4.9.2 > I manually set SDK_GCC_VER=’ -4.10’ in the script to solve the > incompatibility error, (I comment on it in Bug 11471) In general, if you ever have to do something manual like this, please please please mention it in the bug report. A bug report which says "it fails" doesn't help us, we need to know what failed and how you tested it. Knowing which esdk tarball helps immensely, as does knowing about the above setting. In this case the eSDK isn't expected to work on an older gcc version and the warning is therefore correct. It would depend on which autobuilder it was build as to whether it would work or not. Setting this variable isn't expected to make it work. I'm therefore going to reclose this bug as I don't believe this is a valid issue.
(In reply to comment #25) > (In reply to comment #24) > > My gcc version is 4.9.2 > > I manually set SDK_GCC_VER=’ -4.10’ in the script to solve the > > incompatibility error, (I comment on it in Bug 11471) > > In general, if you ever have to do something manual like this, please please > please mention it in the bug report. A bug report which says "it fails" > doesn't help us, we need to know what failed and how you tested it. Knowing > which esdk tarball helps immensely, as does knowing about the above setting. > > In this case the eSDK isn't expected to work on an older gcc version and the > warning is therefore correct. It would depend on which autobuilder it was > build as to whether it would work or not. > > Setting this variable isn't expected to make it work. I'm therefore going to > reclose this bug as I don't believe this is a valid issue. Ah, sorry , that explains it all, I didn't think the 2 bugs were related, that's why I didn't mention it in the first place. So, since the eSDK will not work with an older gcc version it will not be possible to test it in debian 8 since the most recent and stable version is 4.9.2.
the error is rechecked since there is no valid problem The eSDK installs correctly with no errors BUILD: 2.3.2.rc1: ce26a57e04ad65c02087629701d96448a44e73d5 ENVIRONMENT: ubuntu1604 x86-64 Steps: 1. Downloaded 2.3.2.rc1 install script from: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3.2.rc1/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.2.sh 2. Changed permissions to allow execution chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.2.sh 3. Ran poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-2.3.2.sh script with all the default options. Expected Results: The SDK installs correctly with no errors Actual Results: The SDK installs correctly with no errors full-log in attchment
Created attachment 4022 [details] full-log