Bug 162457 - after updating kdelibs and kdebase get PANIC fatal error ...
after updating kdelibs and kdebase get PANIC fatal error ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-05 02:04 EDT by Pete Lancashire
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-25 13:33:48 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)
db_error -- from first rebuilddb (14.68 KB, text/plain)
2005-07-05 02:07 EDT, Pete Lancashire
no flags Details
extended output rpm -vv --rebuilddb (663.04 KB, text/plain)
2005-07-05 02:11 EDT, Pete Lancashire
no flags Details
output of rpm -vv --rebuilddb &> (1.39 MB, text/plain)
2005-07-14 23:09 EDT, Pete Lancashire
no flags Details

  None (edit)
Description Pete Lancashire 2005-07-05 02:04:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
After new install of FC4 x86_64 i first ran yum update. During updating
the rpm db got corrupted.

many messages like:

error: error(-30977) getting "-
                               :d�>+
t " records from Filemd5s index


I then updated one package at a time and isolated it to the four kdelibs,
kdebase packages (x386 and x86_64).

Did the 'normal' process to fix

rm -f /var/lib/rpm/__db* ; db_verify /var/lib/rpm/Packages ; rpm --rebuilddb

but will not fix, same errors.

some extra info

#rpm -qa | grep kdelibs
kdelibs-3.4.0-6
kdelibs-3.4.1-0.fc4.1
kdelibs-3.4.1-0.fc4.1
#rpm -qa | grep kdebase
kdebase-3.4.0-5
kdebase-3.4.1-0.fc4.1
kdebase-3.4.0-5
kdebase-3.4.1-0.fc4.1

# rpm -qa | grep db4
db4-utils-4.3.27-3
db4-4.3.27-3
db4-4.3.27-3
db4-devel-4.3.27-3

Now for some real voodoo ..

did the following

1) #rm -f /var/lib/rpm/__db* ; db_verify /var/lib/rpm/Packages ; rpm --rebuilddb
2) #rpm -qa > /dev/nul
3) rpm --rebuilddb

and .. no errors !!!!

if i just do step 1) then do step 3) I get all the errors over again.

-pete

PS what versions of kdelibs and kdebase should I have ?



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. see above description
2.
3.
  

Actual Results:  way to long to give all .. attachments to follow



Additional info:
Comment 1 Pete Lancashire 2005-07-05 02:07:49 EDT
Created attachment 116342 [details]
db_error -- from first rebuilddb

# rm -f /var/lib/rpm/__db* ; db_verify /var/lib/rpm/Packages ; rpm --rebuilddb
&> /tmp/db_error
Comment 2 Pete Lancashire 2005-07-05 02:10:22 EDT
# rpm -qa  | grep yum
yum-2.3.2-7

# uname -a
Linux slug1out 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:56:33 EDT 2005 x86_64 x86_64
x86_64 GNU/Linux

Comment 3 Pete Lancashire 2005-07-05 02:11:40 EDT
Created attachment 116343 [details]
extended output rpm -vv --rebuilddb

-vv added
Comment 4 Pete Lancashire 2005-07-05 09:22:39 EDT
In addition: Did a fresh (re)install. Same results.
Comment 5 Jeff Johnson 2005-07-13 05:14:56 EDT
The difference in your 1.2.3 procedure in performing step 2) is that rpm -qa
creates a warm lookaside cache in the __db* files.

Running /usr/lib/rpm/rpmdb_verify on Packages should reproduce any error that
was also reported by running rpm. Does
    cd /var/lib/rpm
    /usr/lib/rpm/rpmdb_verify Packages
report the same error?

What happens if you do "rm -f __db*" and rerun rpmdb_verify?
Comment 6 Pete Lancashire 2005-07-13 23:46:55 EDT
What happens if you do "rm -f __db*" and rerun rpmdb_verify?

# cd /var/lib/rpm
# rm -f __db*
# /usr/lib/rpm/rpmdb_verfiy

   no output, no db files

then if I do a

rpm --rebuilddb &> /tmp/abc

4 db files will be created, and lot of the same type of
stuff with go to stderr

rpmdb: page 387: illegal page type or format
rpmdb: PANIC: Invalid argument
error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run
database recovery
error: error(-30977) getting "Ä<83>¾U<92>Ïù<96>Ç<93>ÄÍ^B;ó:`PÛÿÿ^?" records from
Filemd5s index
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run
database recovery
error: error(-30977) getting "ûÊàßÓJ¥<9c><95>" records from Filemd5s index
... [chop]
Comment 7 Jeff Johnson 2005-07-14 06:34:15 EDT
Ok. Can you repeat the sequence above, but add -vv to the --rebuilddb command, and
append the output here? I'm trying to identify the point where the problem occurs more
precisely.
Comment 8 Pete Lancashire 2005-07-14 23:09:36 EDT
Created attachment 116789 [details]
output of rpm -vv --rebuilddb &>
Comment 9 Pete Lancashire 2005-07-14 23:12:11 EDT
if access to the machine would help let me know, its going to get rebuilt
soon

-pete
Comment 10 Jeff Johnson 2005-07-14 23:14:20 EDT
What does the following say:
    cd /var/lib/rpm
    /usr/lib/rpm/rpmdb_stat -CA
(without removing the __db* files please).
Comment 11 Pete Lancashire 2005-07-15 00:48:08 EDT
 /usr/lib/rpm/rpmdb_stat -CA
Default locking region information:
5       Last allocated locker ID
0x7fffffff      Current maximum unused locker ID
5       Number of lock modes
1000    Maximum number of locks possible
1000    Maximum number of lockers possible
1000    Maximum number of lock objects possible
0       Number of current locks
5       Maximum number of locks at any one time
0       Number of current lockers
5       Maximum number of lockers at any one time
0       Number of current lock objects
4       Maximum number of lock objects at any one time
1158    Total number of locks requested
1158    Total number of locks released
0       Total number of lock requests failing because DB_LOCK_NOWAIT was set
0       Total number of locks not immediately available due to conflicts
0       Number of deadlocks
0       Lock timeout value
0       Number of locks that have timed out
0       Transaction timeout value
0       Number of transactions that have timed out
648KB   The size of the lock region
0       The number of region locks that required waiting (0%)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock REGINFO information:
Lock    Region type
3       Region ID
__db.003        Region name
0x2aaaaac17000  Original region address
0x2aaaaac17000  Region address
0x2aaaaacb8f00  Region primary address
0       Region maximum allocation
0       Region allocated
REGION_JOIN_OK  Region flags
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock region parameters:
1031    locker table size
1031    object table size
646752  obj_off
0       osynch_off
630248  locker_off
0       lsynch_off
0       need_dd
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lock conflict matrix:
0       0       0       0       0
0       0       1       0       0
0       1       1       1       1
0       0       0       0       0
0       0       1       0       1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Locks grouped by lockers:
Locker   Mode      Count Status  ----------------- Object ---------------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Locks grouped by object:
Locker   Mode      Count Status  ----------------- Object ---------------
[root@slug1out rpm]#
Comment 12 Jeff Johnson 2005-07-15 08:06:35 EDT
OK, looks sane. (I was looking for lock table overflow problems).

So the --rebuilddb fails after the kdelibs package. Hmm, you
have multiple kdelibs packages installed as well.

Can you try removing the kdelibs package
    rpm -e kdelibs --allmatches --nodeps
and then repeating "rpm --rebuilddb -vv"? I'm trying to see whether
the problem tracks with that kdelibs package or the x86_64 machine itself.
Comment 13 Jeff Johnson 2005-08-25 13:33:48 EDT
This problem fixed by reinstalling afaik.

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