Description of problem: Running 'yum update' from terminal fails with this example message: Error: failure: repodata/00257443dc142c0c75f92cf1706d1f8d24aef8de4d2191ce78c4967d296181e8-primary.sqlite.bz2 from updates: [Errno 256] No more mirrors to try. Version-Release number of selected component (if applicable): $ yum --version 3.4.3 Installed: rpm-4.9.1.3-7.fc17.x86_64 at 2012-08-08 06:41 Built : Fedora Project at 2012-05-07 10:05 Committed: Panu Matilainen <pmatilai> at 2012-05-07 Installed: yum-3.4.3-28.fc17.noarch at 2012-08-08 06:41 Built : Fedora Project at 2012-06-25 08:15 Committed: Zdenek Pavlas <zpavlas at redhat.com> at 2012-06-25 How reproducible: always. Steps to Reproduce: 1. open terminal 2. type 'yum update' Actual results: yum tries to connect to other mirror to download package for installation but it fails to do so with the example message: Trying other mirror. Error: failure: repodata/00257443dc142c0c75f92cf1706d1f8d24aef8de4d2191ce78c4967d296181e8-primary.sqlite.bz2 from updates: [Errno 256] No more mirrors to try. Expected results: yum downloading and installing a package cleanly. Additional info: My current kernel version is: $ uname -r 3.5.3-1.fc17.x86_64 At the moment not able to update to the latest version of anything. Have another system configured in exactly the same way and was able to update it normally. There was some timing out on the way though, saying 'could not retrieve mirrorlist ... time out'
Could you attach your /var/cache/yum/updates/metalink.xml? Maybe the mirror list is corrupt.. Also, does "sudo yum clean expire-cache" help?
(In reply to comment #1) > Could you attach your /var/cache/yum/updates/metalink.xml? Maybe the mirror > list is corrupt.. content of /var/cache/yum/x86_64/17/updates/metalink.xml: <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Mon, 01 Oct 2012 06:30:45 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <files> <file name="repomd.xml"> <mm0:timestamp>1349049247</mm0:timestamp> <size>4854</size> <verification> <hash type="md5">b1835f33c21d753a8ed6ac9e4aab6e86</hash> <hash type="sha1">8ba2923b5a66ede7516b3e57789412b00ee30e75</hash> <hash type="sha256">6af355d46ceaed6334c577509dfaa75eca7e82508724042c87ef6033586d7860</hash> <hash type="sha512">49526db5b313075e59a5391c8337342ca6a94d34a6ce002fb08910e0f92543e4fdfab4f8db406665c49c9e8bf868f348ae03bc369b71a35271b4cb047d56408e</hash> </verification> <mm0:alternates> <mm0:alternate> <mm0:timestamp>1348959359</mm0:timestamp> <size>4854</size> <verification> <hash type="md5">4bf7f4c63947cd04daa55f039e733986</hash> <hash type="sha1">a04fae193428219428c54971a7cdf6726633785c</hash> <hash type="sha256">a23ef33070c5c9e78d57f9122c1aeb4b1a528b7a6873e769bb9ec46d72b4efb6</hash> <hash type="sha512">b65acc75de40ae747210b4be58e893e523df869a214593b1c6d5510e042e25b4176a549aa22d8b38080ad8d651bd496d59b3fb97dfe0b9b6846cfe7e74b4923d</hash> </verification> </mm0:alternate> </mm0:alternates> <resources maxconnections="1"> <url protocol="http" type="http" location="JP" preference="100" >http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="ftp" type="ftp" location="JP" preference="100" >ftp://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="rsync" type="rsync" location="JP" preference="100" >rsync://ftp.riken.jp/fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="ftp" type="ftp" location="JP" preference="99" >ftp://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="http" type="http" location="JP" preference="99" >http://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="rsync" type="rsync" location="JP" preference="99" >rsync://ftp.jaist.ac.jp/pub/Linux/Fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="http" type="http" location="CN" preference="98" >http://mirrors.ustc.edu.cn/fedora/linux/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="ftp" type="ftp" location="CN" preference="98" >ftp://mirrors.ustc.edu.cn/fedora/linux/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="rsync" type="rsync" location="CN" preference="98" >rsync://mirrors.ustc.edu.cn/fedora-enchilada/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="ftp" type="ftp" location="SG" preference="97" >ftp://ftp.oss.eznetsols.org/linux/fedora/updates/17/x86_64/repodata/repomd.xml</url> <url protocol="rsync" type="rsync" location="SG" preference="97" >rsync://rsync.oss.eznetsols.org/ftp/linux/fedora/updates/17/x86_64/repodata/repomd.xml</url> </resources> </file> </files> </metalink> > ... Also, does "sudo yum clean expire-cache" help? Tried already: yum clean, clean headers, clean metadata, clean expire-cache, clean all, yum makecache. After running the above commands yum still fails.
Do I understand correctly that Yum does not try ANY mirror, and exits immediately (or almost immediately) with "No more mirrors to try"? Are you able to use any (eg. the first one, http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/repomd.xml) mirrors by other means (wget, curl)? Please, try running Yum with URLGRABBER_DEBUG=1,debug.log and attach the log file.
Created attachment 619876 [details] result of URLGRABBER_DEBUG=1,debug.log yum update This is the result of 'URLDEBUGGER_URL=1,debug.log yum update' command.
(In reply to comment #3) > Do I understand correctly that Yum does not try ANY mirror, and exits > immediately (or almost immediately) with "No more mirrors to try"? No. It actually does the opposite. It tries all of them, one by one, and fails with every single one. This is the example message for one of the mirrors: http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/f96c8c4434e371bfe8d0ad3263c495c1ddc92d9738b9b04ff4efa77856c2aff2-comps-f17.xml.gz: [Errno 14] HTTP Error 404 - Not Found : http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/f96c8c4434e371bfe8d0ad3263c495c1ddc92d9738b9b04ff4efa77856c2aff2-comps-f17.xml.gz Trying other mirror. > Are you able to use any (eg. the first one, > http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/repomd.xml) > mirrors by other means (wget, curl)? No, I'm not. It gives me 404 error. > Please, try running Yum with URLGRABBER_DEBUG=1,debug.log and attach the log > file. Attached.
Ok, thanks for clearing it out. Your metalink.xml references repomd.xml with sha256=6af355d4* but the current one has sha256=5d297297*, and the hashes that 404 are not in it: $ wget http://ftp.riken.jp/Linux/fedora/updates/17/x86_64/repodata/repomd.xml $ sha256sum repomd.xml 5d2972970f22615d4b80686c72cadd10466535b0aba389f56eb019d573fb005c repomd.xml $ grep 00257443dc142c0c75f repomd.xml || echo No No Could you please try the following: 1. /etc/yum.repos.d/fedora-updates.repo, section [updates]: Check that there is no baseurl option set, only "mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch" 2. remove file "/var/cache/yum/x86_64/17/updates/cachecookie". "yum clean expire-cache" or "yum clean all" could do as well. This tells Yum to fetch new metalink file. 3. run URLGRABBER_DEBUG=1,debug.log yum update. Yum should download fresh /var/cache/yum/x86_64/17/updates/metalink.xml. If it still contains "<hash type="sha256">6af355d46cea..", it's probably a mirror manager bug. Attach "debug.log", and I'll report it.
Created attachment 620191 [details] result of URLGRABBER_DEBUG=1,debug_2.log yum update
1. All baseurl's for [updates], [updates-debuginfo], [updates-source] are commented out. 2. Done. I manually removed the file. Just to add here: I already run 'yum clean expire-cache and yum clean all' before. 3. attached debug_2.log Success I got the updates. $ sha256sum repomd.xml 5d2972970f22615d4b80686c72cadd10466535b0aba389f56eb019d573fb005c repomd.xml $ grep 00257443dc142c0c75f repomd.xml || echo No No metalink.xml still contains "<hash type="sha256">6af355d46cea.." but this time under <mm0:alternates> section so it's updated now. Running 'yum update now' downloads everything as it should. What was different in what I did now by removing the file manually, from what I did previously by running 'yum clean all'?
I guess you ran "yum clean expire-cache" as user, maybe?
No. Always run it either with sudo, or logged in as root. Anyway. If you have an explanation. If not I guess we can forget about for now. Thanks for your assistance.
FWIW I got the same problem on F20. The procedure from Comment #6 fixed it.