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

Ken Dawson dawsonwu@rahul.net
Tue Sep 4 10:09:01 2007

Oops, forgot the list.


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=" 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!
> 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.
> 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=" 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 (, 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.
>> _______________________________________________
>> PlanetCCRMA mailing list
>> PlanetCCRMA@ccrma.stanford.edu
>> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma