[CentOS-devel] 5.3´s anaconda src.rpm missing

Les Mikesell

lesmikesell at gmail.com
Wed Apr 8 23:28:25 UTC 2009

R P Herrold wrote:
>> That is, why does yum do something different after a 'yum 
>> clean all'?  Shouldn't it be trying all the mirrors anyway 
>> if it fails to get a file for any reason?  Otherwise, what's 
>> the point of having the list that generally screws up 
>> caching?
> I do not see that yum failover is **not** working; indeed it 
> seems to be working just fine in my testing against a 'as 
> designed' "centos-release" package as we ship it.  The outcome 
> _I_ see when I hit 'centos.mirror.nac.net' is the failure, a 
> failover, and a success on a later listed peer.  The 
> workaround will permit you to test this as well (simulating a 
> dead mirrorlist entry); transparent proxies are out of our 
> control by definition.

Dead mirrors are different from live mirrors that don't have a file.  I 
can't simulate the latter, which seemed to be the source of the problem.

Most of my x86 updates required this:

yum -y --exclude tk --exclude linuxwacom --exclude wxGTK --exclude 
nss-devel --exclude 'rpm-*' --exclude  popt --exclude kernel\* update

on the first pass or they failed with one or more missing packages.

After this completed and I did a 'yum clean all' a subsequent 'yum 
update' picked up all of the rest, including the previously missing 
package(s).  Proxies were involved in most cases, but not transparent 

> I am not so interested in trying slow motion debug via mailing 
> list of what a person's setup is, and will (and do) read 
> bugs.centos.org for reports from people who file a formal 
> report

I don't know how to submit a sensible bug report about something that is 
not repeatable.  I have an odd mix of 3rd party repositories enabled but 
that shouldn't cause a 'missing' package in the first place and didn't 
change between runs.  It also seemed to be the same thing happening to 
others, since I got most of the --exclude's from the mail list postings.
The only thing visibly different between runs was that after the "yum 
clean all"  it went through the motions of recomputing the fastest mirror.

>> I don't think the answer is to expect the repos to be perfect but rather
>> to make the clients recover without intervention (and without killing
>> the good repos too...).
> patches to yum upstream are still welcome, I assume.  Feel 
> free to ask Seth, et al.

Seth doesn't like my ranting any more than you do.  Usually it is about 
the mirrorlist rotation screwing up caching - which isn't even his 
fault, but this time the download speeds were fast enough that I didn't 
care about the duplication.  So your mirrors have great performance even 
if some contents are missing.

   Les Mikesell
    lesmikesell at gmail.com

More information about the CentOS-devel mailing list