[PlanetCCRMA] YUM chews up my karma, and spits out evil

[Fernando Lopez-Lezcano]

On Sun, 2007-09-02 at 12:52 -0400, Jason Russler wrote:
> kernel failed likely because it was a recent update and they're
> haven't cached a recent "primary.xml.gz". 

Hmmm, that does not seem to be the case. The current kernel is being
downloaded (2.6.22.6-1.rt9.1), and that information (ie: kernel version)
can only come from the correct metadata file being downloaded from
CCRMA. 

It is only at install time of the package that yum is complaining about
it ("package does not match intended download"). That test is done
in /usr/lib/python2.5/site-packages/yum/__init__.py, either
verifyLocalPkg or YumLocalPackage are failing (they spew out the same
error message). 

Most probably it is verifyLocalPkg, which is supposed to:
        """check the package checksum vs the localPkg
           return True if pkg is good, False if not"""
so... the package is downloaded, is the right one, but the checksum of
the download does not match what it should be. I don't know if the
checksum is part of the package itself or comes from the metadata. 

Just to check I just erased the latest kernel-rt and other associated
packages, did a "yum clean" and reinstalled them - I'm also sitting on
Comcast cable and it did work fine. 

I have seen this happen before (once) in a machine at CCRMA. Most
probably a faulty motherboard or other critical component, or something
that is on the edge of being broken. Very large packages would fail with
a checksum error (the package was > 400Mbytes) - the message in older
versions of yum was more explicit. But I could copy the package over nfs
(or transfer through ssh, I don't remember which) and it would install
fine with rpm. All other machines worked perfectly, only this one would
fail (and it would also exhibit other problems which pointed to
something corrupting memory or disk). 

But in this case he apparently can install other packages just fine,
only Planet CCRMA has problems (which could indicate problems in the
server, right? - except I'm using it constantly and don't see that
problem). 

Still in the dark as to why this is failing consistently in his case. 

> I find it unlikely that
> Comast will honor either the "cach-control" or "Expires" headers.  But
> they may surprise.  I tried calling once - they won - I gave up.  Now
> I'm writing a letter.  It will be ignored I imagine.  Unfortunately,
> they're the only game in town here - so all my indignation can pretty
> much go sit on it's ear.
> 
> In the mean time, "export HTTP_PROXY=http://server:port" to a proxy
> server and then use yum - it should honor the environment variable(s).
>  You can google around for proxy-servers.  I don't have a checksum
> mismatch to confirm this on right now but if you're still having
> trouble, you can give it a try.

That's a good idea. At least something to try. 
(but why would a proxy server be any different? After all it has to go
through the same caching mechanism in Comcast, right?)

Of course it could something as simple as flaky networking equipment
somewhere in the route from his machine to CCRMA, you know, a bit flips
every once in a while and you're dead in the water. 

Ken: I forget how you connect to the net, dsl, cable, do you have a
firewall & router in between the modem and the computers, etc, etc. 

-- Fernando