when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

[Robert P. J. Day]

  while the problem has since gone away, something strange happened
yesterday i figured i'd share.

  as a quick test, wanted to build core-image-sato so started with:

  $ bitbake -c fetchall core-image-sato

just to grab everything and i'd start the build later.  but, as i
reported yesterday, fetch failed for two packages, one of them being
that linux tarball, linux-2.6.37.2.tar.bz2.

  being lazy, back off a bit and just go for a minimal image:

  $ bitbake -c fetchall core-image-minimal

unsurprisingly, the fetch for the linux tarball still failed for the
same reason as before -- incorrect checksums.  huh.  i typically don't
expect to see that in a simple fetch.  so check KERNELORG_MIRROR (http
site), *manually* download that tarball and, sure enough, its md5 and
sha256 sums are the (incorrect) ones that bitbake is reporting, which
don't match what's expected.  how odd.  (i verified this two
additional times, same result.)

  just as a test, i edited the bitbake.conf and changed
KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the
remnants of that fetch, re-ran it and ... success!  huh?  so the
tarball via http is broken, but the one via ftp is good?  but it was
late, so i just threw up my hands and went to bed.

  this morning, manually download both tarballs (ftp and http), check
their sums and ... they match!  reset everything, go back to the
original http KERNELORG_MIRROR value and it's all good.  what the heck
was *that* all about?

  obviously, the fetch issue is now resolved but i'm baffled as to
what happened there.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

[Paul Eggleton]

On Friday 15 July 2011 11:47:44 Robert P. J. Day wrote:
> unsurprisingly, the fetch for the linux tarball still failed for the
> same reason as before -- incorrect checksums.  huh.  i typically don't
> expect to see that in a simple fetch.  so check KERNELORG_MIRROR (http
> site), *manually* download that tarball and, sure enough, its md5 and
> sha256 sums are the (incorrect) ones that bitbake is reporting, which
> don't match what's expected.  how odd.  (i verified this two
> additional times, same result.)
> 
>   just as a test, i edited the bitbake.conf and changed
> KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the
> remnants of that fetch, re-ran it and ... success!  huh?  so the
> tarball via http is broken, but the one via ftp is good?  but it was
> late, so i just threw up my hands and went to bed.
> 
>   this morning, manually download both tarballs (ftp and http), check
> their sums and ... they match!  reset everything, go back to the
> original http KERNELORG_MIRROR value and it's all good.  what the heck
> was *that* all about?

Do you still have the tarball with the bad md5sum? Can you diff the contents? 
Or was it simply a case of the bad tarball being truncated?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: when checksums collide -- the saga of linux-2.6.37.2.tar.bz2

[Robert P. J. Day]

On Fri, 15 Jul 2011, Paul Eggleton wrote:

> On Friday 15 July 2011 11:47:44 Robert P. J. Day wrote:
> > unsurprisingly, the fetch for the linux tarball still failed for the
> > same reason as before -- incorrect checksums.  huh.  i typically don't
> > expect to see that in a simple fetch.  so check KERNELORG_MIRROR (http
> > site), *manually* download that tarball and, sure enough, its md5 and
> > sha256 sums are the (incorrect) ones that bitbake is reporting, which
> > don't match what's expected.  how odd.  (i verified this two
> > additional times, same result.)
> >
> >   just as a test, i edited the bitbake.conf and changed
> > KERNELORG_MIRROR to refer to the kernel ftp site, cleared out the
> > remnants of that fetch, re-ran it and ... success!  huh?  so the
> > tarball via http is broken, but the one via ftp is good?  but it was
> > late, so i just threw up my hands and went to bed.
> >
> >   this morning, manually download both tarballs (ftp and http), check
> > their sums and ... they match!  reset everything, go back to the
> > original http KERNELORG_MIRROR value and it's all good.  what the heck
> > was *that* all about?
>
> Do you still have the tarball with the bad md5sum? Can you diff the
> contents? Or was it simply a case of the bad tarball being
> truncated?

  sadly, i tossed the "bad" tarball, but i do recall that when i just
tried to check the contents with "tar tvjf", it eventually reported
unexpected EOF -- yes, i might have mentioned that earlier. :-P

  so i'll just chalk it up to cosmic rays or something, but i did try
the same thing three times and got the same error result all three
times.  this morning, though, everything's back to normal.  go figure.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================