Mirrorlist missing mirrors?

Jeff Spaleta jspaleta at gmail.com
Wed Mar 22 14:51:23 UTC 2006


On 3/21/06, Jesse Keating <jkeating at redhat.com> wrote:
> I am reverting to the old style of the complete mirror list.  The single
> redirector URL is not working as planned.  Please wait for the new mirror
> list files to make it to the live webserver.

I just want to clarify..I take it the behavior has been reverted again
back to the redirector approach?

I'm seeing the same behavior as was seen ealier in the day yesterday
with regard to catching an out of sync mirror and not being able to
failover to another mirror.  Should I start direct people to file bugs
about this behavior per occurance? And which component do I have them
file against?

I continue to see a failure to failover to a second mirror with the
redirector mirrorlist in place.  Even after running yum clean all and
confirming by visual inspection that the cache directory is clear of
cached metadata.
Errors like:
http://download.fedoraproject.org/pub/fedora/linux/core/5/i386/os/repodata/primary.xml.gz:
[Errno 12] Timeout: <urlopen error timed out>
Trying other mirror.
Error: failure: repodata/primary.xml.gz from core: [Errno 256] No more
mirrors to try.

or

http://download.fedoraproject.org/pub/fedora/linux/core/updates/testing/5/i386/repodata/primary.xml.gz:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from updates-testing: [Errno
256] No more mirrors to try.

When I use the -redirect mirrorlist instead.. IF there is a checksum
mismatch because of an out of sync mirror then the failover to the
second mirror in the lis occurs as expected. Also I can't seem to
cause a checksum mismatch right after do a yum clean all when using
the -redirect list, whereas the default mirrorlist is failing with the
above errors multiple times right after a yum clean all. Not 100% of
the time, because I'm sure it depends on which mirror I'm redirected
to when i pull the repomd from and then which mirror i am redirected
to for the primary pull.

With the server-side redirector active, I'm assuming that every
communication to the server means a potentially different mirror. As
in the pull to get repomd.xml can be a different mirror than the
primary.xml? If thats true.. thats russian rulette when there is a
single out of sync mirror in the pool for redirection. I really wish I
knew more about how the redirect works, or I could probe the redirect
so I could understand the potential failure modes. This is really
frustrating. I'm really considering telling people to edit their
configs so they are using a flat list instead.

This is vastly different than the logic I'm use to with yum. Normally
when you have a flat list of potential mirrors yum will start with a
mirror in the list and if there is a failure situation, yum will
failover to the next mirror and continue with that mirror unless there
is another error. Yum will continue to do this until it runs out of
mirrors never going back to a previous mirror.  With the server-side
redirect is there any garuntee that the server-side redirect won't
redirect me to a problematic out-of-sync mirror a second time during
the transaction?

-jef




More information about the devel mailing list