On Friday, 22 September 2017 1:06:19 AM NZST Andrea Galbusera wrote: > On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera <giz...@gmail.com> wrote: > > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton < > > paul.eggle...@linux.intel.com> wrote: > >> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera wrote: > >> > Seeing the errors below while installing an eSDK. This is a routinely > >> > generated VM that installs the eSDK from installation script. The errors > >> > appeared with the latest iteration of the eSDK script, which is > >> generated > >> > with almost up-to-date revisions from master. Of course I have extra > >> layers > >> > in the mix, but none of them apparently had relevant changed since last > >> > (working) iteration: mostly synching to master branches happened. Can > >> > anyone help suggesting how to investigate this further? What do those > >> > unexpected task mean? I'm blocked on releasing this SDK to developers > >> and > >> > clues from expert would be very appreciated... > >> > > >> > ==> default: Checking sstate mirror object availability... > >> > ==> default: done. > >> > ==> default: ERROR: Task python-native.do_fetch attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot > >> attempted > >> > to execute unexpectedly > >> > ==> default: ERROR: Task python-native.do_unpack attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_patch attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_populate_lic attempted to > >> execute > >> > unexpectedly and should have been setscened > >> > ==> default: ERROR: Task python-native.do_configure attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_compile attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_install attempted to execute > >> > unexpectedly > >> > ==> default: ERROR: Task python-native.do_populate_sysroot attempted to > >> > execute unexpectedly and should have been setscened > >> > ==> default: ERROR: SDK preparation failed: error log written to > >> > /home/vagrant/poky_sdk/preparing_build_system.log > >> > > >> > >> Basically this means that these tasks tried to execute where really the > >> results should have been able to be restored from sstate. > >> > >> The cause of this type of error is one of three things: > >> > >> 1) The sstate archive corresponding to a task wasn't able to be fetched > >> from > >> the server (for a minimal eSDK) or wasn't present in the installer (for a > >> full > >> eSDK - less likely as we basically do a trial run as part of building the > >> eSDK > >> in the first place) > >> > >> 2) The signature was somehow different to what it should have been. > >> (Locked > >> signatures are supposed to guard against this.) > >> > >> 3) A task that wasn't expected to execute did execute and thus the sstate > >> wasn't available. > >> > >> Given that this was python-native which I would expect would be a normal > >> part > >> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. what > >> is > >> SDK_EXT_TYPE set to)? > >> > > > > That was a "full" eSDK. I noticed that the "same" eSDK installer from > > another build host was not affected and I'm trying to rebuild on the > > original one with even more recent revision and see if it still happens or > > not. Failure with the first one was repeatable, hence I suspect an issue at > > sdk population stage, not during installation. > > Nuking tmp/ and rebuilding with the same revisions of the successful build > host didn't fix the issue... Same error on installation of the generated > eSDK. Would you suggest any other investigation step? On my todo list I'd > put using the sstate from that other build host than nuking local > sstate-cache/ and going to take a very long coffee break. :-(
Right, so the next step would be looking for the hash for python-native.do_populate_sysroot in conf/locked_sigs.inc within the failed SDK install directory and then looking for that in both the sstate-cache directory within the failed SDK and then in the sstate-cache directory of the build that built it. I suspect it may not be there, but let me know what you find. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto