Bug 861910

Summary:

yum failed updating from terminal - no more mirrors to try

Product:

[Fedora] Fedora

Reporter:

marodoc <marek.j.piatek>

Component:

yum

Assignee:

Fedora Packaging Toolset Team <packaging-team>

Status:

CLOSED WORKSFORME

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

urgent

Docs Contact:

Priority:

unspecified

Version:

CC:

ffesti, maurizio.antillon, maxamillion, nalimilan, packaging-team, tim.lauridsen, zpavlas

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2012-10-02 09:19:11 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
result of URLGRABBER_DEBUG=1,debug.log yum update	none
result of URLGRABBER_DEBUG=1,debug_2.log yum update	none

Description marodoc 2012-10-01 10:19:54 UTC

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'

Comment 1 Zdeněk Pavlas 2012-10-01 14:06:47 UTC

Could you attach your /var/cache/yum/updates/metalink.xml?  Maybe the mirror list is corrupt.. Also, does "sudo yum clean expire-cache" help?

Comment 2 marodoc 2012-10-01 14:18:35 UTC

(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.

Comment 3 Zdeněk Pavlas 2012-10-01 15:31:06 UTC

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.

Comment 4 marodoc 2012-10-01 16:37:52 UTC

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.

Comment 5 marodoc 2012-10-01 16:43:13 UTC

(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.

Comment 6 Zdeněk Pavlas 2012-10-02 08:16:53 UTC

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.

Comment 7 marodoc 2012-10-02 09:03:12 UTC

Created attachment 620191 [details]
result of URLGRABBER_DEBUG=1,debug_2.log yum update

Comment 8 marodoc 2012-10-02 09:10:30 UTC

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'?

Comment 9 Zdeněk Pavlas 2012-10-02 09:19:11 UTC

I guess you ran "yum clean expire-cache" as user, maybe?

Comment 10 marodoc 2012-10-02 10:13:01 UTC

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.

Comment 11 Milan Bouchet-Valat 2014-05-24 15:08:02 UTC

FWIW I got the same problem on F20. The procedure from Comment #6 fixed it.