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