Bug 529349 - Can't use PackageKit with outdated or no repo data
Summary: Can't use PackageKit with outdated or no repo data
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
Whiteboard: NeedsRetesting
Depends On:
Blocks: F12Blocker, F12FinalBlocker
TreeView+ depends on / blocked
Reported: 2009-10-16 09:56 UTC by Bastien Nocera
Modified: 2014-01-21 23:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-02 23:31:49 UTC

Attachments (Terms of Use)

Description Bastien Nocera 2009-10-16 09:56:18 UTC

PackageKit nags me on a regular basis that:
Cannot retrieve repository metadata (repomd.xml) for repository: rpmfusion-free. Please verify its path and try again

It doesn't tell me what's wrong with it, doesn't tell me where to verify the path, and seems to be fatal when running on the command-line as well.

I'd like to tell it:
it's not there, do without

Comment 1 James Antill 2009-10-16 13:25:12 UTC
You can do --disablerepo=rpmfusion\* ... the API to turn a repo. off forever is about 2 lines of code, and we even have test scripts to do it for you:


...we'd need to be convinced a lot to ask this kind of question at the cmd line though, so from what I can tell you just filed against the wrong component.

Comment 2 Bastien Nocera 2009-10-16 13:44:54 UTC
The error message is the same one I see on the command-line. Instead of just skipping the repo it errors out. Completely.

Comment 3 seth vidal 2009-10-16 14:18:41 UTC
Since repos can impact one another disabling an errored repo is not wise. The hard and fast rule is: if a repo that is enabled is down then we abort.

your options are:

1. fix the problem with the repo being inaccessible
2. disable the repo with --disablerepo

Comment 4 David Timms 2009-10-20 23:56:33 UTC
(In reply to comment #3)
> Since repos can impact one another disabling an errored repo is not wise. The
Unless it is taken temporarily offline...or forever. It would be helpful if the error message generated made it clear what is going on, with suggested solutions.

At the moment, in the gui desktop, the user sees just a popup notification (that disappears even if they never actually saw it!) That's what I noticed. It's not clear that you can get more details.

Perhaps it is reasonable for yum to automatically (temporarily) disable inaccessible mirrors, and do updates/installs regardless. (Resilience).

Examples might be:
- repo that is moving URL etc
- repo that is having some technical difficulty

Neither should stop me getting an important security update or installing new software/updates (as long as I don't have something installed from the inaccessible repo, that blocks the transaction from occurring).

In fact, let's say a possible security scenario:
- an important security update is released
- as soon as he sees the secupdate, attacker takes out a popular third party repo.
- no user of the third party repo can get the important security update, and won't even be notified that the update(s) exist.

I won't be so annoying as to reopen, but what do you think of the above scenario ?

Comment 5 David Timms 2009-10-20 23:57:47 UTC
(In reply to comment #4)
> - an important security update is released
 ... (in a working repo eg fedora-updates)

Comment 6 James Antill 2009-10-21 00:45:25 UTC
The error only happens if you have no cache on disk already to revert to.

The fact that PK gives a temporary popup, and doesn't let you deal with it sanely isn't a yum bug.

We've discussed changing the yum client to do something like:

"Repo rpmfusion-updates is not available, do you want to: [fail] [disable] [[temp. disable]]"

...and we aren't opposed to doing something like that, HOWEVER there are at least 4 reasons why this isn't at the top of anyone's list:

1. As I said, this problem only happens if someone did "yum clean all" or has never accessed a particular repo. ... don't do that.

2. Because of #1 yum is _much_ more likely to fail when downloading _packages_, so we'd need to handle that too (which is a much bigger problem).

3. PK, which is in a much easier position to do the right thing here is happily doing worse than yum (message disappears) and from what I've heard is about to do _even_worse_ by just auto. disabling repos.

4. It's really easy to work around on the cmd line already, using --disablerepo etc.

...obviously if you have an idea for a better message, or want to work on #2 for the yum cmd line client ... patches accepted.

Comment 7 Bastien Nocera 2009-10-23 18:02:11 UTC

I've seen that on a newly installed machine without network access, when trying to install a local rpm file using yum.

Here's the backtrace from PK:
Traceback (most recent call last):
  File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2577, in simulate_install_files
    txmbr = self.yumbase.installLocal(inst_file)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3296, in installLocal
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2803, in install
    if self.tsInfo.exists(pkgtup=po.pkgtup):
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 729, in <lambda>
    tsInfo = property(fget=lambda self: self._getTsInfo(),
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 111, in _getTsInfo
    pkgSack = self.pkgSack
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 720, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 549, in _getSacks
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 277, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 164, in populate
    if self._check_db_version(repo, mydbtype):
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 222, in _check_db_version
    return repo._check_db_version(mdtype)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1244, in _check_db_version
    repoXML = self.repoXML
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1408, in <lambda>
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1404, in _getRepoXML
    raise Errors.RepoError, msg
RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again

Looks to me that the whole problem stack here belongs to yum.

Comment 8 seth vidal 2009-10-23 18:06:56 UTC
Actually - it stats in yumbackend  which is PK's - and it looks to me like PK is not catching the RepoError exception when there is no metadata available and should do so.

Comment 9 Richard Hughes 2009-10-29 10:38:17 UTC
commit 17cf7c2bfadef59690c0c96a6af18ae2fb3430a2
Author: Richard Hughes <richard@hughsie.com>
Date:   Tue Oct 20 15:47:36 2009 +0100

    yum: disable repos that are not contactable

:100755 100755 8632e53... 5625089... M  backends/yum/yumBackend.py

I'll do a build with this fix in a few minutes.

Comment 10 Adam Williamson 2009-10-30 20:20:44 UTC
This is the patched build:


tag request is:


Bastien, can you please test and confirm that it does the trick for you? Thanks! It's on the F12 blocker list so if you could do it ASAP that would be really good.

Fedora Bugzappers volunteer triage team

Comment 11 Bill Nottingham 2009-11-02 21:27:02 UTC
This was tagged and will be in tomorrow's rawhide (20091103) - please test.

Comment 12 Adam Williamson 2009-11-02 23:31:49 UTC
I've tested and confirmed the fix for this, here. I installed a new VM from F12 Beta live CD with no network adapter. Dumped a test RPM (nedit) and the updated PackageKit RPMs into it with guestfish (neat tool).

Booted the VM. Without upgrading PackageKit, attempted to install the nedit RPM by double-clicking on it in Nautilus. Got a nasty 'an internal system error has occurred' dialog with the 'cannot retrieve repository metadata' message at the bottom.

Upgraded PackageKit to the patched build, tried the nedit test again. The process goes further, there's no 'internal system error has occurred' dialog, instead it fails at dependency resolution because a few of nedit's dependencies aren't installed, which is what I'd expect.

So this looks fixed, to me. Closing. Please re-open if you still hit problems, Bastien or any other reporter.

Fedora Bugzappers volunteer triage team

Note You need to log in before you can comment on or make changes to this bug.