Re: opkg_install_pkg: Package <name> md5sum mismatch. Either the opkg or the package index are corrupt.

[Denys Dmytriyenko <denis@denix.org>]

On Wed, May 06, 2015 at 07:31:37PM -0400, Denys Dmytriyenko wrote:
> On Wed, May 06, 2015 at 09:12:43PM +0200, Steffen Sledz wrote:
> > Am 02.05.2015 um 23:55 schrieb Andrea Adami:
> > > On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> > >> Has anyone ever seen this message during <image>.do_rootfs task?
> > >>
> > >> Collected errors:
> > >>  * opkg_install_pkg: Package <package> md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.
> > >>  * opkg_install_cmd: Cannot install package <package>.
> > >>
> > >> We started seeing it on random packages inside the <image> few weeks ago on
> > >> different machines. At the time we had switched to bitbake 1.26. But even
> > >> trying different bitbake versions still occasionally caused the same error, so
> > >> the culprit is still unknwon. Using oe-core/daisy for now.
> > >>
> > >> Any comments or suggestions to where start looking would be appreciated!
> > > 
> > > yes, I have seen this during multimachine builds.
> > > My TMPDIR is on tmpfs in ram so everytime I reboot it is re-populated
> > > from sstate.
> > > ...
> > 
> > We have the same problem here. Also with packages from the "all" feed in a 
> > multimachine build environment. But it does not seem related to 
> > packagegroups.
> > 
> > I've a hypothesis but was not able to validate or falsify it till now: Given 
> > a recipe which does only use file:// type SRC_URI. If i change something in 
> > these sources and do not update PR the prserv/hashing mechanism detects the 
> > changes a builds a new package. But this package has the same version info 
> > as the one before. So for opkg there's no need to update it's "package 
> > database".
> 
> After fixing few of our own goofs in packagegroups, I still saw this issue 
> with some real packages like weston-init. It went away after it got rebuilt 
> due to the dependencies, but I'll keep an eye on it and report if it comes 
> back...

Ok, so on the second day it failed again on weston-init and couple of our own 
packages. They are all marked as allarch, but it seems they get re-packaged 
for some reason for different machines in multi-machine build - the timestamp 
of the ipk package changed, while nothing else in the recipe or its data has 
changed. There's nothing obvious in weston-init I can see that would trigger 
it. And in the logs I see that do_package_write_ipk_setscene being triggered - 
I'm trying to figure out why... Any pointers?

-- 
Denys