Bug 35733 - RPM 4.0.2 crashes spuratically
RPM 4.0.2 crashes spuratically
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
6.2
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-11 18:59 EDT by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-03 18:50:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-04-11 18:59:28 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)


I've recently installed a fresh copy of Red Hat Linux 6.2 onto one of my 
workstations.  I'm going through all the updates and errata RPMs and 
installing the appropriate ones.  One of the first things I did was update 
RPM itself, so now I'm attempting to install many older updates with the 
new RPM for 6.2.  When attempting to update several various packages, RPM 
segfaults.  I've tried several things, and RPM still segfaults.  For 
instance, every time I try 'rpm -Uvh bash-1.14.7-23.6x.i386.rpm' I 
get "Segmentation fault (core dumped)" 100% percent of the time, about 50% 
to 30% of the time it will also say "error: cannot open Depends index 
using db1 - Invalid argument (22)" before it segfaults.  On other packages 
(glibc-devel is one such package [even though glibc installed with not 
problems]) it will segfault during the "Preparing..." stage.  All these 
RPMs I'm trying to install are the latest 6.2 udpate RPMs from 
updates.redhat.com.

I'm not to certain what's causing this bug...  I've tried several things, 
but have yet to get very far with it.  Anyways, I just wanted to point 
this out to you guys.  Maybe you can give it a try yourselves: install a 
fresh copy o' RH6.2, install all updates required to install the RPM 4.0.2 
update, then install the RPM 4.0.2 update, then try to install all 
remaining updates.  At least that's all I've done so far.

Reproducible: Always
Steps to Reproduce:
1. Install fresh Red Hat 6.2
2. Update to RPM 4.0.2 before anything else.
3. Try to install all remaining updates, RPM now has problems with several 
of the updates.
	

Actual Results:  All sorts of Bad Things(tm).

Expected Results:  I expect RPM to work.  *grin*

I hope ya fix this one soon.
Comment 1 Jeff Johnson 2001-04-11 19:16:21 EDT
Have you tried --rebuilddb to convert your database from db1 to db3 format?
Comment 2 Need Real Name 2001-04-11 21:04:03 EDT
Yes, I did do an rpm --rebuilddb.  When I got the first segfault (after about 
two successful installations of seperate RPMs after upgrading to RPM 4) I 
attempted a --rebuilddb.  It chugged away for a minute or two, trashed the disk 
a lot, and I assume attempted to rebuild the database, only to segfault before 
it could successfully complete.  I tried running --rebuilddb twice more, with 
still no success.  Now, I didn't do the --rebuilddb immediately, I successfully 
installed a few RPMs /then/ after a failure or two I attempted a --rebuilddb.  

I got tired of trying to hack RPM 4 so I decided to try and downgrade to RPM 
3.  I did successfully downgrade to RPM 3.  I'm now using RPM 3 to install what 
updates I can with RPM 3.  Once I'm finished updating all I can, I'll give RPM 
4 a try again, but this time I'll do a --rebuild immediately.  Maybe I'll have 
better luck that way.
Comment 3 Jeff Johnson 2001-04-11 21:19:03 EDT
Do a --rebuilddb with rpm-3.0.x before upgrading, as the errror handling
for already damaged db1 databases in rpm-4.0.2 is not as good as that in
rpm-3.0.x. I've had a couple of bug reports for those sorts of problems.

I'm gonna close this bug, but please reopen if, after doing an initial
--rebuilddb
with rpm-3.0.x to insure db1 integrity, you still have problems upgrading to
rpm-4.0.2 and doing --rebuilddb one more time to convert from db1 to db3
format.
Comment 4 Need Real Name 2001-04-11 22:06:41 EDT
Okay, I finished installing all my updates with rpm-3.0.x so I did:

% rpm --rebuilddb [still using rpm-3.0.x]
% rpm -Fvh rpm-4.0.2-6x.i386.rpm
% rpm --rebuilddb [now using rpm-4.0.2]
[...chugged along for a while...]
Segmentation fault (core dumped)

Still unsuccessful.  *frown*  You said to reopened the ticket if it didn't 
work, so here ya go.  Hopefully this isn't a toughie.  Since I don't know how 
reproducable this actually is, I can give you access to my machine if need be, 
I've got all the development tools and debuggers and stuff installed.
Comment 5 Jeff Johnson 2001-04-12 11:26:09 EDT
Please mail me <jbj@redhat.com> a copy of your database
	cd /var/lib
	tar czvf /tmp/rpmdb.tar.gz ./rpm
and I'll see what's up. Thanks
Comment 6 John Franks 2001-04-23 15:14:49 EDT
I have encountered the identical problem on five machines.  I have other
quite similar machines which do not exhibit the problem.  Has there been
any success in a workaround to this?
Comment 7 Jeff Johnson 2001-04-23 15:40:51 EDT
The basic general "fix" is still
	1) rebuild with rpm-3.0.x to insure that the database is initially consistent
	2) upgrade to rpm-4.0.2
	3) rebuild with rpm-4.0.2 to convert from db1 to db3
	4) if there are still segfaults,  identify/replace the faulty package and
continue.

FWIW, you might try rpm-4.0.3 from ftp:://ftp.rpm.org/pub/rpm/test-4.0.3. I've
fixed all the segfault's I've personally experienced, but the general problem,
graceful behavior when presented with damaged data, is harder to solve.
Comment 8 wwwatnf 2001-04-26 05:06:59 EDT
I too had gotten wedged like this, with coredumps from rpm-4.0.2.
I found a new wrinkle. You might like to call this 
 "rpm-4.0.3 can trash the rpm Package index"

I followed the directions above, almost. See if you can spot the error
# rpm --version
(4.0.2-6x)
# rpm -Uvh --oldpackage rpm-3.0.4-0.48.i386.rpm
# rpm --version
(3.0.4)
# rpm --rebuilddb -vv
(a few lines output, then ...
record number 3261080 in database is bad -- skipping
# rpm --initdb
# rpm --rebuilddb -vv
(v. short output, but no errors, and rpm -qa gives a reassuringly long list)
# rpm -Uvh rpm-4.0.3.*rpm
(complains it wants db3 installed)
# rpm -Uvh db3-3*.rpm
# rpm -Uvh db3-ut*.rpm
(bitches about Tcl8.0 being missing, so I skipped this)
# rpm -Uvh rpm-4.0.3.*rpm
# rpm --version
(4.0.3)
# rpm -qa
(nada   - uh-oh)

Astute readers will have noticed an OOPS at
# rpm --initdb
Now the Good Book (http://rpmdp.org/rpmbook) sayeth
  If there is an RPM database in place already, it's still
  perfectly safe to use the option, even though it won't accomplish much

However the gods of rpm seem to have changed their minds, and decided to
punish me by removing the Packages index file:
# rpm --rebuilddb
error: cannot open the Packages index

I'm puzzled by this because there is a packages.rpm file in the right place:
# /bin/ls /var/lib/rpm
conflictsindex.rpm  groupindex.rpm  packages.rpm       requiredby.rpm
fileindex.rpm       nameindex.rpm   providesindex.rpm  triggerindex.rpm
Perhaps the change of version/db format fooled it?

So what do I do now - reinstall the box from scratch?

To make all this less painful, would it be possible to have the RPM spit out a
little reminder during the post-install:
 "If you are upgrading from rpm3 to rpm4, make sure to do an rpm --rebuilddb
  BEFORE you add any more packages"
It's not something you would want to do for every package, but in this case
I think it would save you a lot of bug reports.

PS I got my rpms from www.rpmfind.net

Comment 9 wwwatnf 2001-04-26 05:12:42 EDT
just found bug 27435 which seems to be the same problem I have.
The reply from jbj promises instructions, but they did not get tacked onto
the bug report.
Comment 10 wwwatnf 2001-04-26 05:42:31 EDT
I read more bug reports. The following might be useful for diagnosis:
# ls -l /var/lib/rpm
total 4636
-rw-r--r--    1 root     root        16384 Apr 26 18:32 conflictsindex.rpm
-rw-r--r--    1 root     root      1306624 Apr 26 18:32 fileindex.rpm
-rw-r--r--    1 root     root        16384 Apr 26 18:32 groupindex.rpm
-rw-r--r--    1 root     root        16384 Apr 26 18:32 nameindex.rpm
-rw-r--r--    1 root     root      3626120 Apr 26 18:32 packages.rpm
-rw-r--r--    1 root     root        49152 Apr 26 18:32 providesindex.rpm
-rw-r--r--    1 root     root        45056 Apr 26 18:32 requiredby.rpm
-rw-r--r--    1 root     root        16384 Apr 26 18:32 triggerindex.rpm

# rpm --version
RPM version 4.0.3
# rpm --rebuilddb -vv 
D: rebuilding database /var/lib/rpm into /var/lib/rpmrebuilddb.1649
D: creating directory /var/lib/rpmrebuilddb.1649
D: opening old database with dbapi 1
D: opening db index       /var/lib/rpm/Packages rdonly mode=0x0
D: closed  db index       /var/lib/rpm/Packages
error: cannot open Packages index
D: removing directory /var/lib/rpmrebuilddb.1649

For some reason it is using the db1 api, not db3, even though db3 is installed.
# ls /lib/libdb*
/lib/libdb-2.1.3.so  /lib/libdb.so.2  /lib/libdb1-2.1.3.so
/lib/libdb-3.1.so    /lib/libdb.so.3  /lib/libdb1.so.2

One could imagine /var getting full and Packages not getting closed properly.
But /var is a long way from full(hundred Mb free), so that's not the problem.
Comment 11 Daniel 2001-05-02 16:02:24 EDT
I am having a similar problem, except rpm is halfway working. If I do:
   rpm -qa
The list stops after:
kernel-2.2.14-5.0
kernel-pcmcia-cs-2.2.14-5.0
Segmentation fault

Admittedly, I got further along the upgrade process. Furthermore, when I do a
rpm --rebuilddb, I get a "Bus error" I am searching around for rpm-3.0.5-9.6x, 
which I found at:
ftp://ftp.redhat.com/up2date/rhl-6.2.old/i386/RedHat/RPMS/
I am going to try the basic "fix"
Comment 12 John Franks 2001-05-02 16:43:01 EDT
I have a fair amount of experience with this problem by now.  Unfortunately,
there appears to be no good solution after your data base is corrupted.
What appears to be happening is that an an upgrade from rpm-3.x to rpm-4.x goes
fine but continues using the old db1 format.  After some number of addition rpm
transactions with the old format the data base is corrupted and rpm-4.0.2 will
segfault with any operation. The PREVENTIVE step is to do rpm --rebuilddb 
immediately after upgrading to 4.0.2.

Once the damage is done there are two possibilities I have used with limited
success.  

1. You can get a copy of rpm-3.x and use it to do an rpm --rebuilddb. This
produces a non-corrupt data base, but one which omits some number of the
packages which are actually installed.  I know no good way to find out which
ones, but by trial and error I have found four or five on each machine where
I have tried this.  If you can find them then you can re-install them, after
which they will be in the database.   You should then do a rebuilddb with
rpm-4.0.2 to convert the database to db3 format.

2. The second alternative is to do an rpm --rebuilddb with rpm-4.0.2.  This
will segfault, but will produce a replacement for the data base directory 
/var/lib/rpm anyway. The original /var/lib/rpm is unchanged and the new one
has a tmp name and is in /var/lib/.  At this point if you rename /var/lib/rpm
and replace it with the new one, every thing seems to work fine, but again
some packages are missing from the data base.  I would do another 
rpm --rebuilddb at this point.

I don't know how many packages are missing -- it likely varies.  Doing 
rpm -qa | wc gives a resonable number so it is not the majority, at least
for me.

Anyway, YMMV, and do this at your own risk, but I have done both of these.
Comment 13 Will Cox 2001-05-03 18:50:53 EDT
I was having exactly the same symptoms as <linux@zendigital.com>, with the 
segfault immediately after listing kernel-pcmcia-2.14 (why the pcmcia module is 
on a system that doesn't have pcmcia slot beat me, though).

I attempted to downgrade RPM to 3.0.4-0.48 but was unable to remove the 
dependent package ucd-snmp because of a segfault. It's segfaulting at 
Depends.idx:

[root@bldblocks01 RPMS]# rpm -evv ucd-snmp
D: opening db file        /var/lib/rpm/packages.rpm mode 0x82
D: opening db file        /var/lib/rpm/nameindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/requiredby.rpm mode 0x82
D: getting list of mounted filesystems
D: opening db file        /var/lib/rpm/fileindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/groupindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/providesindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/conflictsindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/triggerindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/Depends.idx mode 0x82
D: closed  db file        /var/lib/rpm/Depends.idx
D: removed db file        /var/lib/rpm/Depends.idx
error: cannot open Depends index using db1 - File exists (17)
Segmentation fault

Trying again ends up with a segfault at the nearly the same spot, but leaves a 
zero-length Depends.idx behind.

[root@bldblocks01 RPMS]# rpm -evv  ucd-snmp
D: opening db file        /var/lib/rpm/packages.rpm mode 0x82
D: opening db file        /var/lib/rpm/nameindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/requiredby.rpm mode 0x82
D: getting list of mounted filesystems
D: opening db file        /var/lib/rpm/fileindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/groupindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/providesindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/conflictsindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/triggerindex.rpm mode 0x82
D: opening db file        /var/lib/rpm/Depends.idx mode 0x82
Segmentation fault

<john@math.nwu.edu>'s suggestion to copy the temp rebuild dir to /var/lib/rpm 
seems to have avoided segfaults, but at this point I'm pretty sure it doesnn't 
reflect the actual state of the system. I have a rpm -qa from before 
immediately before the segfaults. I would think that 208 packages before and 81 
packages after is a significant difference. :-(

There doesn't happen to be a way to downgrade to db1 from db3, does there?
Comment 14 Jeff Johnson 2001-05-21 09:32:06 EDT
Downgrading to db1 is not the answer, but is possible using
--dbapi 3 --rebuilddbapi 1 options.

If you still don;'t have a "fix", reopen this bug with a pointer
to a tarball of your database attached
	cd /var/lib
	tar czvf /tmp/rpmdb.tar.gz
and I'll take a look.

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