Bug 218663

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.

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.

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*

(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?

or 3. we could re-invoke rpm module by reload(rpm) once its updated before
proceeding with the rest of the upgrades.

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.  

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

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

User bnackash's account has been closed

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.