Red Hat Bugzilla – Bug 164302
rpm upgrade breaks rpm
Last modified: 2007-11-30 17:07:08 EST
Description of problem:
RHEL3, upgraded with "rpm -Uvh rpm*rpm popt*rpm" after downloading packages from
this errata: https://rhn.redhat.com/errata/RHBA-2005-147.html
Afterwards, I get this:
rpmdb: Program version 4.2 doesn't match environment version
error: db4 error(22) from dbenv->open: Invalid argument
error: cannot open Packages index using db3 - Invalid argument (22)
error: cannot open Packages database in /var/lib/rpm
The solution is to "rm -f /var/lib/rpm/__.db*".... why isn't that part of the
the rpm postinstall script/process?
Version-Release number of selected component (if applicable):
Further rpm command all break
rpm upgrading rpm doesn't break rpm commands
As documented on the bugzilla front page support requests need to go through
Please file an appropriate request.
I just *did* file a request. "Hey Red Hat, this is broken" is what I said :-)
I'm curious, is this a new standard reply to all new bugzilla's that are opened?
For RHEL customers issues should go through support as documented so that it is
Support channels have SLA's, etc where as reports directly to bugzilla don't.
Please file a support request referencing this bug.
This is not a new procedure.
Also please not the rpm %post scripts do check for db version changes and act
appropriately to remove the __db files. Is the issue 100% reproducible for you,
would you have been running another process (up2date, rhn_check) that would have
created them during or following the install.
Community knowledge of this bug is vital... it is *still* open source after all.
I will file a bug with my Red Hat support representive should we deem it neccisary.
We don't use up2date or rhn_check at all. This issue happened on hundreds of
machines in the past 24 hours. The issue isnt' that they were recreated... it
is that they weren't... and the old files remained in place. If the were
recreated after the install, from my understanding of how it all works, we
wouldn't have this problem... right?
If you have multiple transaction sets open against the rpmdb running with the
old libraries then although the scriptlet would run in the first transaction,
the __db files would be repl
I'm just trying to rule that out that first.
I'll try and reproduce - what was the initial state of your system RHEL 3 GA,
RHEL 3 U1, U2, U4? Are you runningwith any environment variables such as
LD_ASSUME_KERNEL set - or just the command line in the bug.
Really if you are having the issue with 100's of machines filing with support
will get the request appropriately prioritised.
The machines all had rpm-* 4.2.3-10 on them, an upgrade to the 4.2.3-21_nonptl
caused the problem.
Hey, isn't this a duplicate of BZ # 143532 ??
143532 is the rhn_check issue I mentioned in comment #7 where the old library is
still in use following upgrade so even though %post works the second ts creates
the old format __db files on exit.
Could you clarify on the other details I asked about (LD_ASSUME_KERNEL, exact
There is no LD_ASSUME_KERNEL being set. We are using yum to update our
machines... so it is something like:
yum -y update
What version of yum? What source did you obtain yum from? Out of curiosity why
aren't you using RHN and up2date?
We use yum 2.2.1 that is "rpmbuild --rebuild" from
http://linux.duke.edu/projects/yum/download/2.2/yum-2.2.1-1.src.rpm on RHEL3.
We use yum because it is
2) very very simple
3) free software
4) free as in beer
RHN is none of these things in any configruation that would work well in the
1) not small; requires an Oracle backend
2) Satellite server is complex
4) very costly
Can you replicate the issue just using the rpm cli to upgrade rpm?
I was able to, yes. It does seem hit and miss though. yum is the way we mass
deploy rpms, but by hand using the rpm cli you can occasionally get the same
You are likely to have 2 different versions of rpm that you are trying to use,
each with a different version of Berkeley DB inside.
That is the only plausible explanation for a version string mis-match
reappearing on the same machine repeatedly.
If different machines, then up2date has had a known bug when upgrading
rpm, where the older bindings in use end up rewriting the old version string
into __db files even though rpm attempted to correct the problem in %post.
You have neglected to include any details whatsoever how you were "able to, yes"
reproduce the problem.
We aren't using up2date or RHN. My reference to using the rpm cli is to do the
rpm upgrade like this:
rpm -Uvh rpm*rpm
What is the %post script in the rpm package being upgraded?
Jeff, the %post script is the %post script of these packages:
Remember, this is only when upgrading rpm*rpm itself (along with popt).
This might be a fuction of the many many hung NFS mounts we have in our
environment. I can't cleanly recreate this problem without HUNG nfs mounts.
There are fixes to handle (at least some) problems with stale NFS mounts
Any other problems need a clear reproducer. I can't fix what I can't see.
Please open a new bug, as there are at least 3 issues here so far, with different casues
And RHEL questions, like when RHEL rpm will be "fixed" should be pursued
through RHEL support channels.