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 ======================================================================== |
|