Bug 246050 - rpm database not working
rpm database not working
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
7
i386 Linux
low Severity low
: ---
: ---
Assigned To: Paul Nasrat
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-28 00:48 EDT by Ben York
Modified: 2014-01-21 17:58 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-28 15:53:57 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 Ben York 2007-06-28 00:48:05 EDT
Description of problem:

Whenever I try to use anything to update/install rpm's I get an error.


Version-Release number of selected component (if applicable):


How reproducible:

Many ways:
 - use yum
 - open "Add/Remove Software"
 - rpm -Uvh
 - etc..


Steps to Reproduce:
1. use any command that accesses the rpm database
2.
3.
  
Actual results:

"TypeError: rpmdb open failed" or the like

Expected results:

the rpm database opens and works

Additional info:

[dragonsapp@wench ~]$ sudo yum update subversion
Password:
Loading "installonlyn" plugin
rpmdb: Lock table is out of available locker entries
rpmdb: Unknown locker ID: 7d2
error: db4 error(22) from db->close: Invalid argument
error: cannot open Packages index using db3 - Cannot allocate memory (12)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 82, in main
    base.getOptionsConfig(args)
  File "/usr/share/yum-cli/cli.py", line 146, in getOptionsConfig
    errorlevel=opts.errorlevel)
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 153, in _getConfig
    self._conf = config.readMainConfig(startupconf)
  File "/usr/lib/python2.5/site-packages/yum/config.py", line 601, in readMainConfig
    yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
  File "/usr/lib/python2.5/site-packages/yum/config.py", line 664, in _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed

--------------------------------------------------------------------------------------

Component: Software Manager
Summary: TBe1153693 config.py:664:_getsysver:TypeError: rpmdb open failed

Traceback (most recent call last):
  File "/usr/sbin/pirut", line 428, in <module>
    main()
  File "/usr/sbin/pirut", line 421, in main
    pm = PackageManager(options.config, options.onlyrepo)
  File "/usr/sbin/pirut", line 61, in __init__
    GraphicalYumBase.__init__(self, False, config)
  File "/usr/lib/python2.5/site-packages/pirut/__init__.py", line 120, in __init__
    plugin_types=(yum.plugins.TYPE_CORE,))
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 109, in
doConfigSetup
    errorlevel=errorlevel)
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 153, in _getConfig
    self._conf = config.readMainConfig(startupconf)
  File "/usr/lib/python2.5/site-packages/yum/config.py", line 601, in readMainConfig
    yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
  File "/usr/lib/python2.5/site-packages/yum/config.py", line 664, in _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed

Local variables in innermost frame:
installroot: /
ts: <rpmUtils.transaction.TransactionWrapper instance at 0xa137b8c>
distroverpkg: redhat-release
Comment 1 Ben York 2007-06-28 01:42:38 EDT
I just found out this does not occur if the default init is set to 5 (I had it
set to 3)
Comment 2 Ben York 2007-06-28 06:21:12 EDT
Changed Severity level since it only occurs in default init level 3 (forgot to
do this last time)
Comment 3 Ben York 2007-06-28 15:53:57 EDT
after changing the default init level to 3 and restarting , the problem no
longer occurs.

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