Bug 595626 - RpmDBError: Package tuple could not be found in rpmdb
RpmDBError: Package tuple could not be found in rpmdb
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-25 04:31 EDT by Mads Kiilerich
Modified: 2014-01-21 18:15 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 12:37:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2010-05-25 04:31:53 EDT
When trying to install an update I got

could not do simulate: Traceback (most recent call last):
  File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2120, in _update_packages
    txmbr = self.yumbase.update(po=pkg)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3326, in update
    updated_pkg =  self.getInstalledPackageObject(updated)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2610, in getInstalledPackageObject
    raise Errors.RpmDBError, _('Package tuple $s could not be found in rpmdb') $ str(pkgtup)
RpmDBError: Package tuple ('exo', 'i686', '0', '0.3.106', '2.fc13') could not be found in rpmdb

I would expect PackageKit to handle it some other and more user friendly way than showing the backtrace. The content of the yum exception content do however also not seem to be suitable for displaying to a user. :-(

PackageKit-0.6.4-1.fc13.i686
gnome-packagekit-2.30.1-1.fc13.i686
yum-3.2.27-4.fc13.noarch
Comment 1 Mads Kiilerich 2010-05-25 04:37:56 EDT
It seems like exo was successfully updated anyway:

May 25 10:24:08 localhost yum: Updated: exo-0.3.106-3.fc13.i686

The update was successful, only leaving bug 579748.
Comment 2 Steven M. Parrish 2010-06-04 21:58:44 EDT
This bug has been triaged



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Richard Hughes 2010-06-18 10:57:03 EDT
I'll re-assign and ask the yum guys what's going on. Feel free to reassign back to PK if it's my problem.
Comment 4 seth vidal 2010-06-18 11:45:20 EDT
Mads,
 What version of yum is that? 

Did you modify the traceback output you pasted in?

B/c you have:
getInstalledPackageObject
    raise Errors.RpmDBError, _('Package tuple $s could not be found in rpmdb')


in the output - but $s doesn't exist in the yum pkgs I can find - only
     raise Errors.RpmDBError, _('Package tuple %s could not be found in rpmdb') % str(pkgtup)


and RpmDBError is just a sub of YumBaseError so - it should be catchable just the same for PackageKit.


What exceptions are you catching in yumbackend when you go to update, Richard?
Comment 5 James Antill 2010-06-18 11:45:20 EDT
Mads, what yum plugins do you have?
Comment 6 Mads Kiilerich 2010-06-18 15:13:36 EDT
(In reply to comment #4)
> Mads,
>  What version of yum is that? 

It was yum-3.2.27-4.fc13.noarch

> Did you modify the traceback output you pasted in?

No I did not modify the traceback. Perhaps PK modified it to be extra sure no spurious printf expansion is done?

Yes, an abrt report would have been more reliable than me cut'n'pasting ;-)

(In reply to comment #5)
> Mads, what yum plugins do you have?    

Loaded plugins: auto-update-debuginfo, fastestmirror, merge-conf, presto, refresh-packagekit, remove-with-leaves


Requesting info from rhughes to answer seths question.
Comment 7 Richard Hughes 2010-07-13 06:19:28 EDT
(In reply to comment #4)
> What exceptions are you catching in yumbackend when you go to update, Richard?    

Just exceptions.IOError -- but RpmDBError exception should not be generated surely as yum has just queried the rpmdb for the update list surely?
Comment 8 James Antill 2010-07-13 12:49:38 EDT
 I'm not sure where "package_ids" is coming from in PK but I wonder if something is going wrong there (is this from a client? -- so could it be a bad cache of data clientside?), or maybe _findPackage() (side note: wow to that function).

 If you can reproduce it, it'd probably be helpful to know of the PK pkgid says it's repo is "installed" or not. Dito. what the po.repoid is after _findPackage(). And the installed/available versions of the package.
 From what I can see on the yum side the pkg you are passing in to yb.update() is the latest available pkg, which is then doing the reverse lookup for what it updates ... it then gets a pkgtup and then looks that up in the rpmdb, but that pkgtup doesn't exist in the rpmdb.

 I'm not sure how self.up.updating_dict can contain pkgtups which aren't in the rpmdb, so that seems like a yum bug ... but it also seems like one which would hit us all the time.
Comment 9 seth vidal 2010-07-13 13:08:15 EDT
So a theory of the interaction:
1. user runs PK- it generates the updates list and hold onto this data - it doesn't require locking anything b/c nothing is happening, really.
2. user goes to a prompt and runs 'yum update foo' or 'yum install bar' which modifies the rpmdb
3. user then goes back to the PK box and says 'update' (or whatever) and PK then tries to use the info it has in state.

For the original reporter: does that process ring any bells to you? Does it seem possible that is what happened?
Comment 10 Mads Kiilerich 2010-07-13 13:44:13 EDT
(In reply to comment #9)
> So a theory of the interaction:
> 1. user runs PK- it generates the updates list and hold onto this data - it
> doesn't require locking anything b/c nothing is happening, really.
> 2. user goes to a prompt and runs 'yum update foo' or 'yum install bar' which
> modifies the rpmdb
> 3. user then goes back to the PK box and says 'update' (or whatever) and PK
> then tries to use the info it has in state.
> 
> For the original reporter: does that process ring any bells to you? Does it
> seem possible that is what happened?    

If
"1. user runs PK" happens automatically when the user logs in (and an alert might appear)
"2. user goes to a prompt" thus discusses _any_ direct use of yum
"3. user goes back to PK box" means that the user clicks the alert icon
- then it sounds like a plausible explanation.

I still haven't figured out where PackageKit stores its state, how to see it and how to control it. But it seems like stores something (besides what it can get from rpm and yum). That can get of of sync, and then the user has no idea what is going on can't do anything.
Comment 11 Bug Zapper 2011-06-02 09:34:02 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 12 Bug Zapper 2011-06-27 12:37:43 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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