Description of problem: When all repos are enabled in /etc/yum.repos.d/{fedora.repo, fedora-updates.repo, fedora-updates-testing.repo}, yum terminates with an error: $ sudo yum repolist -q --noplugins Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=x86_64 error was No repomd file Error: File /var/cache/yum/x86_64/15/updates-debuginfo/metalink.xml does not exist Version-Release number of selected component (if applicable): yum-3.2.29-4.fc15.noarch Prerelease repos. How reproducible: Always. Steps to Reproduce: 1. Enable all repos in /etc/yum.repos.d/ fedora.repo fedora-updates.repo fedora-updates-testing.repo 2. $ sudo yum repolist -q --noplugins Actual results: Error. Expected results: Repolist. Additional info: $ curl 'http://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=x86_64' <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sat, 30 Apr 2011 09:54:57 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <!-- # repo = updates-released-debug-f15 arch = x86_64 error: invalid repo or arch # following repositories are available: # repo=core-2, arch=i386 ... # repo=updates-testing-source-fc6, arch=source --> </metalink>
Correction: Expected results: No error. ("-q" suppresses all non-error output.)
This reproducer does not require editing *.repo files: $ sudo yum repolist -q --noplugins --enablerepo='*' Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=x86_64 error was No repomd file Error: File /var/cache/yum/x86_64/15/updates-debuginfo/metalink.xml does not exist
This bug was noted with the prerelease F14 repos. The workaround was to create empty repos (Jesse's reply). F14 updates-debuginfo repo is missing http://lists.fedoraproject.org/pipermail/test/2010-September/093201.html
Part of the problem is that metalinker is returning an ad hoc error message in an xml comment, rather than in xml. If the error message were encoded in xml, yum could parse that and distinguish between a metalink file and an error message. There doesn't seem to be a metalinker component in BZ ... http://www.metalinker.org/
See also: Bug 700231 - Repository updates-released-debug-f15 arch = i386 missing
(In reply to comment #4) > Part of the problem is that metalinker is returning an ad hoc error message in > an xml comment, rather than in xml. If the error message were encoded in xml, > yum could parse that and distinguish between a metalink file and an error > message. > > There doesn't seem to be a metalinker component in BZ ... > http://www.metalinker.org/ The component would be mirrormanager: Bug 625922 - yum --releasever=14 update gives a unclear error message when repo is not available
Bug 701046 - mirrormanager reports errors inside of an xml comment instead of as xml
(In reply to comment #1) > Correction: > > Expected results: > No error. > ("-q" suppresses all non-error output.) Of course there should be an error message. (I'm thinking of tracebacks.) The message would be more informative if it said that metalink.xml could not be retrieved from the repo and reported the proposed error message from mirrormanager (Bug 701046). A similar case occurs when the host name cannot be resolved. If the host name in fedora.repo is changed to foo_mirrors.fedoraproject.org, yum reports: $ sudo yum repolist -q --noplugins Could not get metalink https://foo_mirrors.fedoraproject.org/metalink?repo=fedora-15&arch=x86_64 error was 14: curl#6 - "Couldn't resolve host"
*** Bug 700231 has been marked as a duplicate of this bug. ***
Possibly all I did to drive myself into this ditch was enable a couple more repos under "Software Sources" with Add/Remove Software. (This was trying to respond to another bug 702354 saying "get the latest latest latest") Whatever, once stuck nothing could get me out. [Tom@TLSF15beta yum.repos.d]$ sudo yum repolist all Loaded plugins: langpacks, presto, refresh-packagekit updates-debuginfo/metalink | 19 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=i386 error was No repomd file Error: File /var/cache/yum/i386/15/updates-debuginfo/metalink.xml does not exist Not seeing any solutions offered here (and I couldn't remove software sources from add/remove, because of the error), I ended up removing that section from /etc/yum.repos.d/fedora-updates.repo --- fedora-updates.repo.original 2011-05-06 11:53:41.530393322 -0500 +++ fedora-updates.repo 2011-05-07 11:39:50.309802759 -0500 @@ -7,14 +7,6 @@ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch -[updates-debuginfo] -name=Fedora $releasever - $basearch - Updates - Debug -failovermethod=priority -#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/debug/ -mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f$releasever&arch=$basearch -enabled=1 -gpgcheck=1 -gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch [updates-source] name=Fedora $releasever - Updates Source Only then could I get yum to run, [Tom@TLSF15beta yum.repos.d]$ sudo yum repolist all Loaded plugins: langpacks, presto, refresh-packagekit updates/metalink | 17 kB 00:00 repo id repo name status fedora Fedora 15 - i386 enabled: 19,340 fedora-debuginfo Fedora 15 - i386 - Debug disabled fedora-source Fedora 15 - Source disabled rawhide Fedora - Rawhide - Developmental packa disabled rawhide-debuginfo Fedora - Rawhide - Debug disabled rawhide-source Fedora - Rawhide - Source disabled updates Fedora 15 - i386 - Updates enabled: 0 updates-source Fedora 15 - Updates Source disabled updates-testing Fedora 15 - i386 - Test Updates disabled updates-testing-debuginfo Fedora 15 - i386 - Test Updates Debug disabled updates-testing-source Fedora 15 - Test Updates Source disabled repolist: 19,340 Why no workaround offered above? Why does the (planned? customary?) absence of a repository produce an unrecoverable error for the beta user? Why create frustration, instead of creating an empty repo at start of beta?
(In reply to comment #10) > Possibly all I did to drive myself into this ditch was enable a couple more > repos under "Software Sources" with Add/Remove Software. (This was trying to > respond to another bug 702354 saying "get the latest latest latest") The "updates" and "updates-debuginfo" repos are not used during the prerelease period. The "workaround" is to use the default *.repo files from fedora-release: $ rpm -V fedora-release
(In reply to comment #10) ... > Why does the (planned? customary?) absence of a repository produce an > unrecoverable error for the beta user? Bug 679783 - [abrt] abrt-1.1.17-2.fc15.1: metalink.py:184:__init__:MetaLinkRepoErrorParseFail: File /var/cache/yum/i386/15/updates-debuginfo/metalink.xml does not exist Bug 701046 - mirrormanager reports errors inside of an xml comment instead of as xml > Why create frustration, instead of creating an empty repo at start of beta? https://fedorahosted.org/rel-eng/ticket/4682
This bug affects repoquery too -- you even get a traceback. :-) This is a workaround: $ sudo repoquery glibc --releasever=15 --disablerepo='updates-debuginfo' glibc-0:2.13.90-9.i686 glibc-0:2.13.90-9.x86_64 yum-3.2.28-5.fc14.noarch yum-utils-1.1.28-1.fc14.noarch $ sudo repoquery glibc --releasever=15 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=x86_64 error was No repomd file Traceback (most recent call last): File "/usr/bin/repoquery", line 1187, in <module> main(sys.argv) File "/usr/bin/repoquery", line 1181, in main repoq.runQuery(regexs) File "/usr/bin/repoquery", line 763, in runQuery pkgs = self.matchPkgs(items, plain_pkgs=plain_pkgs) File "/usr/bin/repoquery", line 739, in matchPkgs pkgs = self.returnPkgList(patterns=items) File "/usr/bin/repoquery", line 692, in returnPkgList pkgs = self.pkgSack.returnNewestByNameArch(**kwargs) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 827, in <lambda> pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 617, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 283, in populateSack sack.populate(repo, mdtype, callback, cacheonly) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 163, in populate if self._check_db_version(repo, mydbtype): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 221, in _check_db_version return repo._check_db_version(mdtype) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1224, in _check_db_version repoXML = self.repoXML File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1413, in <lambda> repoXML = property(fget=lambda self: self._getRepoXML(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1409, in _getRepoXML raise Errors.RepoError, msg yum.Errors.RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: updates-debuginfo. Please verify its path and try again
I have done today a preupgrade from f14 to f15 and I'm now concerned by this bug. Note: under f14, testing repositories (package + debug) were enabled.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping