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

[Fernando Lopez-Lezcano]

On Mon, 2007-09-03 at 08:44 -0700, Ken Dawson wrote:
> 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.

Wow, I was not expecting this to make a difference... so it should/must
be something in comcast land? (I'm using comcast without problems but I
have a much older cable modem - that I need to exchange because it
self-reboots randomly - and a linksys router / firewall). 

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

[can't be the problem, but also make sure your router is running the
latest firmware - it did make a difference in my case]

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

Let us know what happens, and thanks for your patience...
-- Fernandpo


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