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

[Ken Dawson]

Hello,

I assigned "proxy=http://68.180.195.13:80" in yum.conf, and tried the yum upgrade.  It was clearly slower, but did 
manage to succeed. So, as a workaround, this approach may be viable.

I connect to comcast though a motorola surfboard cable modem connected to a netgear wpn824 router.  Both fedora boxes 
run the firewall.

I'm going to try the a/b test I did earlier: copy down the planet's f7-related repos using wget using direct and proxied 
methods, and then do a tree diff.  They should be the same.

/ken

Fernando Lopez-Lezcano wrote:
> 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
> 
> 
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>