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): https://rhn.redhat.com/errata/RHBA-2005-147.html Actual results: Further rpm command all break Expected results: rpm upgrading rpm doesn't break rpm commands Additional info:
As documented on the bugzilla front page support requests need to go through support: https://www.redhat.com/apps/support/ 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 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.
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 command run).
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 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 Enterprise: 1) not small; requires an Oracle backend 2) Satellite server is complex 3) proprietary 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 breakage.
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: https://rhn.redhat.com/errata/RHBA-2005-147.html 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 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.
Thanks Jeff