On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote:
> 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. > Good catch! In the failing SDK neither conf/locked_sigs.inc nor sstate-cache do include any python-native signature or object... Only python3-native stuff is there. Weird! As said, SDKs from the same build directory, used to work since a few weeks ago. May any recent change in poky master have caused this while periodically upgrading without regenerating the sstate-cache?
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
