[yocto] Fixing build when changing kernel PREFERRED_PROVIDER

[Bryan Evenson]

Andre,

> -----Original Message-----
> From: Andre McCurdy [mailto:armccurdy at gmail.com]
> Sent: Wednesday, December 02, 2015 4:57 PM
> To: Bryan Evenson <bevenson at melinkcorp.com>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] Fixing build when changing kernel
> PREFERRED_PROVIDER
> 
> On Wed, Dec 2, 2015 at 1:08 PM, Bryan Evenson
> <bevenson at melinkcorp.com> wrote:
> > I'm on poky/dizzy-1.7.2 and I'm in the process of updating to poky/dizzy-
> 1.7.3.  I'm using an Atmel processor, so while I'm at it I'm pulling in changes
> from meta-atmel (over at https://github.com/linux4sam/meta-atmel, dizzy
> branch).  One of the commits I pulled in was this one:
> https://github.com/linux4sam/meta-
> atmel/commit/ae10c274a681adebb1b59ea1173e6a8c603b66f1.  This
> renamed the kernel package from linux-yocto-custom to linux-at91.  After
> this change when I tried to build the image, I was greeted with a very long list
> of files and the following error:
> >
> > The build has stopped as continuing in this scenario WILL break
> > things, if not now, possibly in the future (we've seen builds fail several
> months later). If the system knew how to recover from this automatically it
> would however there are several different scenarios which can result in this
> and we don't know which one this is. It may be you have switched providers
> of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in
> that case you need to execute the clean task for both recipes and it will
> resolve this error. It may be you changed DISTRO_FEATURES from systemd
> to udev or vice versa. Cleaning those recipes should again resolve this error
> however switching DISTRO_FEATURES on an existing build directory is not
> supported, you should really clean out tmp and rebuild (reusing sstate should
> be safe). It could be the overlapping files detected are harmless in which
> case adding them to SSTATE_DUPWHITELIST may be the correct solution. It
> could also be your buil  d is including two different conflicting versions of
> things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to
> resolve the conflict. If in doubt, please ask on the mailing list, sharing the
> error and filelist above.
> > ERROR: If the above message is too much, the simpler version is you're
> advised to wipe out tmp and rebuild (reusing sstate is fine). That will likely fix
> things in most (but not all) cases.
> > ERROR: Function failed: sstate_task_postfunc
> >
> > I issued 'bitbake -c clean linux-at91' and then 'bitbake -c clean linux-yocto-
> custom'.  Linux-at91 cleaned without issue, but when I tried to clean linux-
> yocto-custom I got an error saying "Nothing PROVIDES 'linux-yocto-custom'".
> That in itself makes sense as there is no longer any recipe for linux-yocto-
> custom.  However, I'd like to avoid deleting the entire tmp directory.  I don't
> have the speediest machine and I'd like to avoid wasting a day if there was a
> simpler solution.
> >
> > Is there a less destructive fix to this problem than deleting the tmp
> directory, or is that the only safe way to fix this problem?
> 
> If you can restore the old linux-yocto-custom recipe (e.g. temporarily git
> revert the commit that removed it) then you should be able to run it's clean
> task.
> 
> Deleting tmp is probably safer and quicker though. It certainly should not
> take a day to recreate it if you keep your downloads and sstate directories
> intact.

I had no idea how much is stored in the sstate.  I thought if I deleted the tmp directory it would have to rebuild everything instead of just populate the sysroot and repackage.  The rebuild of tmp and image build only took about 45 minutes; much better than I expected.

Thanks,
Bryan

> 
> > Thanks,
> > Bryan
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto