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

Tue Sep 4 10:15:02 2007

On Tue, 2007-09-04 at 10:06 -0700, Ken Dawson wrote:
> Oops, forgot the list.
> 
> /ken
> 
> Ken Dawson wrote:
> > Hi again.
> > 
> > First off, I am using the latest Netgear firmware.
> > 
> > As for the a/b test:
> > 
> > I used the wget commands
> > 
> > wget -v -r -np -nH -c
> > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/6/i386/ 
> > 
> > wget -v -r -np -nH -c
> > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/6/i386/ 
> > 
> > 
> > in the comcast case, I used them just as you see them.  In the proxy 
> > case, I
> > set and exported the environment variable
> > "http_proxy=http://162.114.40.32:8080" and ran them.
> > 
> > (The proxy server is different from before because the previous one was 
> > refusing connections last night.)
> > 
> > As for the diffs, I just did "diff -rq <a> <b>".  In a perfect world, 
> > the output from this should be empty.  Instead, we get 212 files 
> > different.  For cleanliness, I attach them as exhibit "screenlog.0"
> > 
> > Ouch!

Wow, double ouch. That's a lot. 

> > I'll send a followup message to Nando with the md5sums for both trees.  
> > I'm wondering if either tree corresponds to what's really there at CCRMA.

Sure, I can check to see which one is real :-)
-- Fernando

> > Maybe I need to sit under the lammpost again to get /repo-google as well.
> > 
> > Thanks for listening to me.
> > 
> > /ken
> > 
> > Fernando Lopez-Lezcano wrote:
> >> 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.