On 3/21/06, Jesse Keating <jkeating@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
