Bug 164302 - rpm upgrade breaks rpm
Summary: rpm upgrade breaks rpm
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-26 18:41 UTC by Joshua Jensen
Modified: 2007-11-30 22:07 UTC (History)
0 users

Clone Of:
Last Closed: 2006-03-16 12:56:05 UTC

Attachments (Terms of Use)

Description Joshua Jensen 2005-07-26 18:41:06 UTC
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):


Actual results:

Further rpm command all break

Expected results:

rpm upgrading rpm doesn't break rpm commands

Additional info:

Comment 1 Paul Nasrat 2005-07-26 18:55:41 UTC
As documented on the bugzilla front page support requests need to go through


Please file an appropriate request.

Comment 2 Joshua Jensen 2005-07-26 21:24:49 UTC
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?

Comment 3 Paul Nasrat 2005-07-26 21:39:30 UTC
For RHEL customers issues should go through support as documented so that it is
tracked appropriately.

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.

Comment 4 Paul Nasrat 2005-07-26 21:43:43 UTC
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.

Comment 5 Joshua Jensen 2005-07-26 22:47:23 UTC
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.

Comment 6 Joshua Jensen 2005-07-26 22:48:21 UTC
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?

Comment 7 Paul Nasrat 2005-07-26 23:32:01 UTC
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.  

Comment 8 Joshua Jensen 2005-07-28 14:58:45 UTC
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  ??

Comment 9 Paul Nasrat 2005-07-28 17:27:18 UTC
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
command run).

Comment 10 Joshua Jensen 2005-07-28 17:40:11 UTC
There is no LD_ASSUME_KERNEL being set.  We are using yum to update our
machines... so it is something like:

yum -y update

Comment 11 Paul Nasrat 2005-07-28 17:44:37 UTC
What version of yum?  What source did you obtain yum from?  Out of curiosity why
aren't you using RHN and up2date?

Comment 12 Joshua Jensen 2005-07-28 18:45:54 UTC
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
1)  small
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
3)  proprietary
4)  very costly

Comment 13 Paul Nasrat 2005-07-28 18:59:18 UTC
Can you replicate the issue just using the rpm cli to upgrade rpm?

Comment 14 Joshua Jensen 2005-07-28 19:51:16 UTC
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

Comment 16 Jeff Johnson 2006-02-19 21:48:37 UTC
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.

Comment 17 Joshua Jensen 2006-02-20 01:28:02 UTC
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

Comment 18 Jeff Johnson 2006-03-01 14:19:49 UTC
What is the %post script in the rpm package being upgraded?

Comment 19 Joshua Jensen 2006-03-14 16:31:05 UTC
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.

Comment 20 Jeff Johnson 2006-03-16 12:56:05 UTC
There are fixes to handle (at least some) problems with stale NFS mounts
in rpm-4.4.5.

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 fixes.

And RHEL questions, like when RHEL rpm will be "fixed" should be pursued
through RHEL support channels.

Comment 21 Joshua Jensen 2006-03-16 15:47:43 UTC
Thanks Jeff

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