Description of problem: After my kernel update from 2.4.20-13.9 to 2.4.20-18.9 and a normal reboot: "rpm -qa | grep kernel" => the WHOLE system hangs (=> hard-reset) (well, my ISP is going around and slaps me...). Version-Release number of selected component (if applicable): kernel-2.4.20-13.9 kernel-2.4.20-18.9 (rpm of Red Hat Linux 9.0) How reproducible: see before and below ;-) Steps to Reproduce: 1. wget http://updates.redhat.com/9/en/os/i686/kernel-2.4.20-18.9.i686.rpm 2. rpm -ivh kernel-2.4.20-18.9.i686.rpm 3. reboot 4. [login as root] 5. rpm -qa | grep kernel 6. [the system hangs] Actual results: Well, either there is a bug at rpm or in the 2 kernel packages...because in the last few minutes the system crashed with the old kernel at the same position, too. Tried (but failed): hurricane:~ # rpm --rebuilddb Fehler: db4 error(16) from dbenv->remove: Das Geraet oder die Ressource ist belegt hurricane:~ # rm -f /var/lib/rpm/__db.00* hurricane:~ # rpm --rebuilddb Fehler: db4 error(16) from dbenv->remove: Das Gerät oder die Ressource ist belegt [the error-message in english should maybe be: "The device or ressource is busy"] So, how can I fix that problem (soon as possible)?! Aso and I don't want to reinstall all...it is a used server! Hope to hear soon from you, Robert
Created attachment 92138 [details] output from rpmdb --rebuilddb -vv Well, that's the output from rpmdb -vv --rebuilddb - maybe someone can help me?
The rebuild error is caused by a known bug, but it doesn't affect the success of the rebuild.
Thanks first, but are you sure? --- snipp --- hurricane:/var/lib/rpm # dir insgesamt 25432 drwxr-xr-x 2 rpm rpm 4096 4. Jun 18:21 . drwxr-xr-x 16 root root 4096 4. Jun 19:39 .. -rw-r--r-- 1 rpm rpm 2670592 4. Jun 16:03 Basenames -rw-r--r-- 1 rpm rpm 12288 4. Jun 15:44 Conflictname -rw-r--r-- 1 root root 16384 4. Jun 18:21 __db.001 -rw-r--r-- 1 root root 1318912 4. Jun 18:21 __db.002 -rw-r--r-- 1 root root 458752 4. Jun 18:21 __db.003 -rw-r--r-- 1 rpm rpm 421888 4. Jun 16:03 Dirnames -rw-r--r-- 1 rpm rpm 5103616 4. Jun 16:03 Filemd5s -rw-r--r-- 1 rpm rpm 12288 4. Jun 16:03 Group -rw-r--r-- 1 rpm rpm 12288 4. Jun 16:03 Installtid -rw-r--r-- 1 rpm rpm 24576 4. Jun 16:03 Name -rw-r--r-- 1 rpm rpm 17629184 4. Jun 16:03 Packages -rw-r--r-- 1 rpm rpm 167936 4. Jun 16:03 Providename -rw-r--r-- 1 rpm rpm 40960 4. Jun 16:03 Provideversion -rw-r--r-- 1 rpm rpm 12288 4. Jun 16:03 Pubkeys -rw-r--r-- 1 rpm rpm 110592 4. Jun 16:03 Requirename -rw-r--r-- 1 rpm rpm 65536 4. Jun 16:03 Requireversion -rw-r--r-- 1 rpm rpm 45056 4. Jun 16:03 Sha1header -rw-r--r-- 1 rpm rpm 24576 4. Jun 16:03 Sigmd5 -rw-r--r-- 1 rpm rpm 12288 4. Jun 16:03 Triggername hurricane:/var/lib/rpm # --- snapp --- The time of __db.00* (4. Jun 18:21) was the last time of the rebuild from the db...WHY are all dates at the other files "4. Jun 16:03"? And could you say me why "rpm -qa | grep kernel" hangs up my system?
Yes I'm sure that the --rebuilddb message is harmless. Yes the __db* files are persistent, the files contain locks, but are not lock files themselves. Usually a "hang" is due to stale locks left behind in the __db* files. Try rm -f /var/lib/rpm/__db* If that fixes, then upgrade to rpm-4.2 (Red Hat 9) or rpm-4.1.1 (Red Hat 8.0) packages from ftp://ftp.rpm.org/pub/rpm/dist All known cases of stale locks causing hangs are fixed there.
Well, rpm -qa | grep kernel hangs after doing rm -f /var/lib/rpm/__db* too. After removing the second kernel, rpm works *largely* normal... P.S: Red Hat Linux 9 already has rpm-4.2-0.69 ;-)
Yup, but you need/want rpm-4.2-1 at the URL above.
:) okay, (hopefully) last question: Can I update rpm itself in the running system (!) with rpm -Uvh rpm-4.2-1.i386.rpm If no, how then?
You should be able to. If rpm-4.2-1 hangs the system with kernel-2.4.20-18.9, the reopen this bug, and I'll get you sorted out.
If you can't upgrade, add LD_ASSUME_KERNEL=2.2.5 prefix, that should fix.
Now, rpm works very much better then before (I didn't need that prefix at the install), but sometimes rpm needs 99,9% CPU for ~ 1 minutes at a simple query. In that time, my server respons very slow or it doesn't respond. If you want to debug that (or find the cause), you can have my databases and outputs from the programs you need - of cause - but: I don't want to experience at my server system that should run day by day... The last is the reason why I didn't reopen the bug. But thank you for all :)
Yup, rpm -qa verifies header signatures and/or digests every time it first reads a header from the database. Verifying signatures/digest is compute intensive. Add --nodigest --nosignature to disable if you wish, the default configuration is to always verify.