[yocto] eSDK install script failure

[Paul Eggleton]

On Friday, 22 September 2017 1:06:19 AM NZST Andrea Galbusera wrote:
> On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera <gizero at gmail.com> wrote:
> > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton <
> > paul.eggleton at 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