Bug 218663 - rpm update from U4 does not delete /var/lib/rpm/__db*
rpm update from U4 does not delete /var/lib/rpm/__db*
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pradeep Kilambi
Brandon Perkins
:
Depends On: 143532
Blocks: 145467
  Show dependency treegraph
 
Reported: 2006-12-06 12:04 EST by Pradeep Kilambi
Modified: 2014-01-21 17:56 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 14:39:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Comment 2 Pradeep Kilambi 2007-01-02 13:54:46 EST
This issue happens only when we have a rpm db change which did from 3.3 to 3.4.
Fix should probably be in rpm itself, so that whenever its updated to newer
versions it should try to clear the lock files as well.
Comment 3 Pradeep Kilambi 2007-01-04 18:02:57 EST
this is what i tried:

1. freshly kickstarted a box to rhel u3

2. initially :

[root@fjs-0-19 root]# rpm -q rpm
rpm-4.2.3-10

3. scheduled an upgrade of rpm and  rmt to
rmt-0.4b37-1E &
rpm-4.2.3-30_nonptl

4. rhn_check -vv on client, everything looks good.
D: Header for ['rpm-python', '4.2.3', '30_nonptl', '', 'i386', '41153',
'rhel-i386-as-3'] Fetched via: localdisk
Preparing              ########################################### [100%]

Installing...
   1:rmt                    ########################################### [100%]
   2:rpm-libs               ########################################### [100%]
   3:rpm                    ########################################### [100%]
   4:rpm-python             ########################################### [100%]

D: Sending back response (0, 'Packages were installed successfully', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)

5. then queried rpm
[root@fjs-0-19 root]# rpm -q rpm
rpm-4.2.3-30_nonptl

also $rpm -qa no errors.

looks fine no errors. 

also tried the same with rpm upgrade alone and it went through fine again. no db
errors.

probably this might have been fixed as a part of librpm or something. but it
seems to work now.
Comment 4 Paul Nasrat 2007-01-05 07:22:04 EST
Nothing in rpmlib has changed that would "fix" this, this probably worked as no
transactions were held after rpm itself so the __db was not recreated.  Try a
transaction with things later than rpm*
Comment 5 Pradeep Kilambi 2007-01-05 10:15:21 EST
(In reply to comment #4)
> Nothing in rpmlib has changed that would "fix" this, this probably worked as no
> transactions were held after rpm itself so the __db was not recreated.  Try a
> transaction with things later than rpm*

ok looks like that was it. To revert back, i tried to downgrade the rpm package
through profile sync :

Changes Scheduled:

    * Replace rpm-4.2.3-30_nonptl with rpm-4.2.3-10
    * Replace rpm-libs-4.2.3-30_nonptl with rpm-libs-4.2.3-10
    * Replace rpm-python-4.2.3-30_nonptl with rpm-python-4.2.3-10
    * Replace sendmail-8.12.11-4.RHEL3.6 with sendmail-8.12.11-4.RHEL3.1

rhn_check went fine as usual.

but now when i do 

$ rpm -qa
rpmdb: fatal region error detected; run recovery
error: db4 error(-30982) from dbenv->open: DB_RUNRECOVERY: Fatal error, run
database recovery
error: cannot open Packages index using db3 -  (-30982)
error: cannot open Packages database in /var/lib/rpm
no packages

but then if I do : rm -f /var/lib/rpm/__db* & rpm --rebuilddb. its back to normal.

1. Is there any plan for this to be fixed in rpm itself such that if it finds
the db as not current, it tries to deal with it rather than barf.

2. other option probably would be to make rhn_check add rpm always as a last
transaction(if scheduled for upgrade) so that the __db files are not created
with other package upgrades.

but as this happens only when there is a db chnage on rpms side, the right place
to fix it probably is on rpms end.

comments/suggestions?




Comment 6 Pradeep Kilambi 2007-01-05 10:44:16 EST
or 3. we could re-invoke rpm module by reload(rpm) once its updated before
proceeding with the rest of the upgrades.
Comment 7 Fanny Augustin 2007-01-05 11:49:51 EST
This is bug is not a blocker.  According to pkilambi and bretm, it will be nice
to fix, but not worth holding the release for it.  Will take away the blocker
flag.  
Comment 8 Pradeep Kilambi 2007-01-10 11:20:51 EST
just updating the bug with paul's response:

On Tue, 2007-01-09 at 14:25 -0500, Pradeep Kilambi wrote:
> > Alternately, I wonder why the lock files are so dependent on the rpm db 
> > version, could there be a easy work around to make them independent of 
> > the db ?

It's a sleepycat (Berkeley DB) limitation, which would require a full db
upgrade and some changes to make it independant.  It's certainly not an
option for a RHEL update release.

Paul


Comment 9 Fanny Augustin 2007-01-12 16:18:48 EST
Moving to rhn-uncommitted from 4.5 and 3.9 respectively. Bret and pkilambi think
that the course of action on this bug is unclear and the fix probably might have
to go in a major release such as FC7/8(not sure yet). Its better we move it to
rhn-uncommitted until we have a concrete plan on this
Comment 10 Red Hat Bugzilla 2007-04-11 22:00:12 EDT
User bnackash@redhat.com's account has been closed
Comment 11 RHEL Product and Program Management 2007-10-19 14:39:49 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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