Hi Andrea, 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)? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
