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.
Have you tried --rebuilddb to convert your database from db1 to db3 format?
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.
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.
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.
Please mail me <jbj> a copy of your database cd /var/lib tar czvf /tmp/rpmdb.tar.gz ./rpm and I'll see what's up. Thanks
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?
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.
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
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.
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.
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"
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.
I was having exactly the same symptoms as <linux>, 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.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?
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.