Bug 181363 - rpmdb: PANIC: fatal region error detected; run recovery
rpmdb: PANIC: fatal region error detected; run recovery
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: 211917 232635 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-02-13 13:03 EST by Joerg Skottke
Modified: 2009-07-14 13:04 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 13:04:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from yum -y update evolution* (177.96 KB, text/plain)
2006-02-13 13:26 EST, Joerg Skottke
no flags Details
Output from rpm -Uvv xorg* (150.02 KB, text/plain)
2006-02-15 00:25 EST, Joerg Skottke
no flags Details

  None (edit)
Description Joerg Skottke 2006-02-13 13:03:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5

Description of problem:
Plain installation (Modifications to default: added/selected german locale, selinux off and no firewall)

Initial system update as root:
"yum -y update" downloads all headers ok, resolves dependencies but breaks at some point during installation. After that the database is locked.

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

How reproducible:

Steps to Reproduce:
1. Fresh install fedora core (modifications as in description)
2. Log in as root
3. Open a Terminal, run "yum -y update"
-> at some point during installation the database appears to get corrupted and the update is aborted

Actual Results:  rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery

Expected Results:  The update of all packages should have completed ok

Additional info:

LANG, LC_ALL are "de_DE.UTF8"
Comment 1 Jeff Johnson 2006-02-13 13:16:43 EST
Try this to fix:
    cd /var/lib/rpm
    mkdir SAVE
    mv __db* SAVE
    /usr/lib/rpm/rpmdb_verify Packages

If that reports no problems, then a --rebuilddb to regenerate indices should be fine.

Does the above fix for you?
Comment 2 Joerg Skottke 2006-02-13 13:26:32 EST
Created attachment 124572 [details]
Output from yum -y update evolution*
Comment 3 Joerg Skottke 2006-02-13 13:29:34 EST
Ooops - i did not expect/notice the quick reply. I'm trying, it might take a few
Comment 4 Joerg Skottke 2006-02-13 13:36:16 EST
OK, the proposal appears to work, the database is accessible again. 
I just started a "yum -y update" which will take considerably more minutes ;-)
Comment 5 Jeff Johnson 2006-02-13 14:06:11 EST
OK. Sounds like a fix, reopen if you need more help.
Comment 6 Joerg Skottke 2006-02-13 14:09:53 EST
Too bad - the fix was only temporary. After a couple of packages the database
broke again. Same thing, same messages.

This happens for both x86 and x86_64.
Comment 7 Jeff Johnson 2006-02-13 14:22:27 EST

Can you reproduce on the CLI using the same packages that yum is installing using rpm -Uvv?

Otherwise its off to yum for a fix ...
Comment 8 Joerg Skottke 2006-02-13 14:50:11 EST
Currently i'm stuck - the database is a mess and i need to do some serious
cleanup work before i can continue. 
But i cannot do this now, it's getting late and i have other tasks to see to. I
will try my luck again tomorrow.

Thank you for your help. I guess the correct status would be "Needinfo", right?
Comment 9 Joerg Skottke 2006-02-15 00:25:30 EST
Created attachment 124665 [details]
Output from rpm -Uvv xorg*
Comment 10 Mike A. Harris 2006-02-21 23:16:47 EST
Someone requested I review this bug in case xorg packages need to be
adjusted.  The attachments in comment #2 and comment #9 are mostly in
German however, making it extremely difficult to easily determine wether
there is anything I should be concerned about.  If anyone thinks that the
xorg packaging is at fault in any of this, please file individual bug
reports against the appropriate xorg component(s) that are thought to
be problems, and attach rpm output as above, but in English.  You will
probably need to reconfigure your system or fiddle with i18n settings
to get English errors though.

Comment 11 Joerg Skottke 2006-02-25 15:59:03 EST

This issue has nothing to do with the xorg packages - they were merely taken as
an example to demonstrate a misbehavior of yum/rpm or the rpm database.

I cannot find a single german word in comment #2 and most of the content of
comment #9 are english as well - if you leave out the size comparision of the
files to be installed. 

If you need more info or help translating the remaining parts i'll be happy to
help. For now i've quickly translated the most common expressions from the log
to comment #9

Erwartete Größe:       (expected size)
D: Aktuelle Größe:       (current size)
D: SHA1-Kurzfassung des Headers (SHA1 Summary of the header)
D: Offene   DB-Umgebung    (Open DB-Environment)
D: Öffne    DB-Index      (Opening DB-Index)
D: Gesperrter  DB-Index    (Locked DB-Index)
D: Öffne    DB-Index      (Opening DB-Index)
D:  read h#     891 SHA1-Kurzfassung des Headers: OK
D: 	Binär-Paket hinzugefügt (Added binary package)
Comment 12 Joerg Skottke 2006-02-26 10:14:08 EST
The issue has been confirmed at least once on the fedora mailing list.
Comment 13 Jeff Johnson 2006-03-08 18:17:14 EST
This "someone" pointed out that there are dependency loops within xorg
packages that need to be fixed (in spite of the German). I know less German
than you do as well.
Comment 14 Joerg Skottke 2006-03-27 09:01:49 EST
Nope, this doesn't have anything to do with the Xorg packages. Read my earlier
comments and please note the translation i provided (in parentheses, comment #11).

I can still reproduce the issue in FC5 final (tested for x86_64). So this issue
seems to be here to stay. That's bad.
Comment 15 Joerg Skottke 2006-03-27 09:15:27 EST
Output from pup:

Component: Software Updater
Summary: TB3705923b config.py:674:_getsysver:TypeError: rpmdb open failed

Traceback (most recent call last):
  File "/usr/sbin/pup", line 382, in ?
  File "/usr/sbin/pup", line 377, in main
    pup = PackageUpdater()
  File "/usr/sbin/pup", line 77, in __init__
    GraphicalYumBase.__init__(self, False)
  File "/usr/lib/python2.4/site-packages/pirut/__init__.py", line 122, in __init__
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 102, in
    self.conf = config.readMainConfig(fn, root)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 574, in readMainConfig
    vars['releasever'] = _getsysver(earlyconf.installroot, earlyconf.distroverpkg)
  File "/usr/lib/python2.4/site-packages/yum/config.py", line 674, in _getsysver
    idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed

Local variables in innermost frame:
installroot: /
ts: <rpmUtils.transaction.TransactionWrapper instance at 0x2b4e31908ea8>
distroverpkg: redhat-release

Comment 16 Paul Nasrat 2006-04-03 15:01:02 EDT
Does this happen with FC5 final?  Please do a fresh install and test, as
upgrades from test releases to final are not supported.
Comment 17 Joerg Skottke 2006-04-06 09:38:21 EDT
Yes it does, results from comment 14 and comment 15 happen on a fresh install.
Comment 18 Joerg Skottke 2006-04-06 09:46:40 EDT
Hm, just a thought: This is a SCSI system (AICU160). If i install fc5 (i386) in
VPC (which emulates IDE) on this machine i have no problems. On a native install
rpm for both x86 and x86_64 fails.
Comment 19 Paul Nasrat 2006-04-06 10:38:46 EDT
That seems odd - are there any hints in dmesg?
Comment 20 Joerg Skottke 2006-04-07 04:22:11 EDT
Not that i can remember, the controller initializes ok, the disk/dvd-drives are
found and work as expected. Unfortunately i don't have the file at hand as i
needed the diskspace.
Comment 21 Paul Nasrat 2006-06-30 10:07:34 EDT
Does a fresh install of fc6t1 have the same issue.  The fact that changing the
h/w config works around makes me think it may be kernel related.
Comment 22 Joerg Skottke 2006-10-29 13:13:38 EST
Fresh install of fc6 (final) shows same problem for both i386 and x86_64. :(
Comment 23 Joerg Skottke 2006-10-29 13:40:20 EST
Now happens with package pygtk2-devel-2.10.1-5.fc6.i386.rpm.

Snippet from rpm -Uvv output:

D: sanity checking 4 elements
D: opening  db index       /var/lib/rpm/Name create mode=0x42
D:  read h#    1160 Header V3 DSA signature: OK, key ID 4f2a6fd2
D:  read h#    1161 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: running pre-transaction scripts
D: computing 1400 file fingerprints
Preparing packages for installation...
D: computing file dispositions
D: opening  db index       /var/lib/rpm/Basenames create mode=0x42
rpmdb: page 1205: 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 "class-gdkcolor.html" records from Basenames index
rpmdb: PANIC: fatal region error detected; run recovery
error: db4 error(-30977) from db->cursor: DB_RUNRECOVERY: Fatal error, run datab
ase recovery
Comment 24 Joerg Skottke 2006-10-31 13:29:59 EST
I found a dirty workaround for the problem:
When the database is ok - e.g. after doing a full recovery i can install the
updates using rpm -Uvh --force --nodeps *.rpm. This still brings the fatal
region error but apparently the packages get installed. Only remaining problem
is that the packages

frysk x86_64
pygtk2-devel x86_64
pygtk2-devel i386

don't make it into the database so i'm probably running into dependency troubles
at some point. Note that these packages are the ones that trigger the fatal
region error. Maybe finding out what they have in common might yield some
information about the root cause.
Comment 25 Joerg Skottke 2006-10-31 13:50:20 EST
i did a strace on rpm --rebuilddb:

pwrite(19, "\0\0\0\0\1\0\0\0\326\1\0\0\0\0\0\0\0\0\0\0\336\0\242\3"..., 4096,
1925120) = 4096
pread(19, "\0\0\0\0\1\0\0\0002\1\0\0\362\0\0\0\0\0\0\0\260\0\220\6"..., 4096,
1253376) = 4096
pwrite(19, "\0\0\0\0\1\0\0\0T\1\0\0\0\0\0\0\0\0\0\0\344\0L\3\0\2\357"..., 4096,
1392640) = 4096
pread(19, "\0\0\0\0\1\0\0\0\306\1\0\0\0\0\0\0\0\0\0\0\346\0Z\3\0\2"..., 4096,
1859584) = 4096
pwrite(19, "\0\0\0\0\1\0\0\0\324\0\0\0\0\0\0\0U\2\0\0\366\0\"\2\0\2"..., 4096,
868352) = 4096
pread(19, "\0\0\0\0\1\0\0\0\265\0\0\0\0\0\0\0\0\0\0\0\350\0\220\3"..., 4096,
741376) = 4096
pwrite(19, "\0\0\0\0\1\0\0\0^\2\0\0\361\0\0\0\0\0\0\0\240\0p\7\0\2"..., 4096,
2482176) = 4096
pread(19, "\0\0\0\0\1\0\0\0\353\0\0\0\0\0\0\0\230\0\0\0\374\0004\2"..., 4096,
962560) = 4096
write(2, "rpmdb: ", 7rpmdb: )                  = 7
write(2, "page 235: illegal page type or f"..., 37page 235: illegal page type or
format) = 37
write(2, "\n", 1
)                       = 1
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such
file or directory)
write(2, "rpmdb: ", 7rpmdb: )                  = 7
write(2, "PANIC: Invalid argument", 23PANIC: Invalid argument) = 23
write(2, "\n", 1
)                       = 1
write(2, "error: ", 7error: )                  = 7
write(2, "db4 error(-30977) from dbcursor-"..., 91db4 error(-30977) from
dbcursor->c_get: DB_RUNRECOVERY: Fatal error, run database recovery
) = 91
write(2, "error: ", 7error: )                  = 7
write(2, "error(-30977) getting \"\272.\31\fT\264\377\354."..., 72error(-30977)
getting "º.^Y^LT´ÿì.^TñÈå¼<94>B ^^a" records from Filemd5s index
) = 72
Comment 26 Joachim Frieben 2006-11-04 19:12:44 EST
As far as "FC6" is concerned, upgrading to "kernel-2.6.18-1.2835.fc6"
from "updates/testing/6" appears to have solved the issue for me.
I strongly recommend every affected user to try out this new kernel
Comment 27 Joachim Frieben 2006-11-13 15:54:42 EST
Annoying: random freezes again with "kernel-2.6.18-1.2849.fc6".
Comment 28 Paul Nasrat 2006-11-14 03:48:22 EST
Joachim, if you boot into 1.2835 is all well again?
Comment 29 Joachim Frieben 2006-11-14 06:29:44 EST
Definitely yes. After giving "kernel-2.6.18-1.2849.fc6" a try,
I am happy that "kernel-2.6.18-1.2835.fc6" still does the job
perfectly. [Btw, bug 211917 is concerned with the same issue].
Comment 30 Jeff Johnson 2006-11-14 06:40:46 EST
If booting kernel-2.6.18-1.2835.fc6 is the cure, then please reassign to the kernel.

vmlinuz-2.6.18-1.2835.fc6 is not contained in any rpm component package last I checked.
Comment 31 Paul Nasrat 2006-11-14 06:44:02 EST
*** Bug 211917 has been marked as a duplicate of this bug. ***
Comment 32 Paul Nasrat 2006-11-14 06:54:40 EST
Dave any idea what changes between FC6 gold, 2835 and 2849 may account for this.
Comment 33 Simon Andrews 2006-11-16 04:22:04 EST
Since BZ211917 has been marked as a duplicate of this I'll add here that I can
reproduce a similar error to the one reported here using yum-updatesd, and that
this error persists even on the latest kernel update (2849).

The symptoms are pretty much the same.  Yum-updatesd segfaults and all further
rpm transcations fail until the __db* files are cleared from /var/lib/rpm.  I've
even had duplicate entries in the database which had to be cleaned up manually.
 There are a coulple of strace logs of this near the end of #211917 if that's
any help.
Comment 34 Máirín Duffy 2006-11-19 00:16:56 EST
Hi, this just happened to me on my IBM T41 running a 4.5 mo old install of FC5

I noticed the 'db4 error(-30977) from dbenv->open: DB_RUNRECOVERY: Fatal error,
run database recovery' recovery immediately after successfully (or so pirut told
me) installing a set of packages via pirut. I clicked on an rpm on my desktop in
order to install it and system-install-packages gave me a python traceback
indicating the rpmdb error. 

According to /var/log/yum.log, I installed 18 packages in that run of pirut, but
the rpm database only seems to think one of them (the first one) is installed.
Actually, i think RPM is right though because I can't seem to run any of the
programs they installed :) But they are still listed in yum.log. 

package versions:
rpm-4.4.2-15.2, kernel-2.6.18-1.2200.fc5, pirut-1.0.3-0.fc5, yum-2.6.1-0.fc5, 

I haven't tried the workaround in comment 1 yet. 
Comment 35 Joachim Frieben 2006-12-02 14:26:59 EST
I have just tried "kernel-2.6.18-1.2856.fc6.i686.rpm", and it gives
me the same disk I/O related system freezes which ultimately led to
"rpmdb" corruption on my system with "2.6.18-1.2849.fc6.i586".
Reverting to "2.6.18-1.2835" allowed to immediately achieve stable
operation again.
Comment 36 Joachim Frieben 2006-12-15 05:37:31 EST
I have built "kernel-2.6.19-1.2860.fc7" from D. Jones' kernel "CVS"
repository. Using the "ext4dev" driver, no problems of the kind
reported above show up. Pobably time for a kernel update then ..
Comment 37 Simon Andrews 2006-12-15 05:50:24 EST
Ext4 isn't ready for release in a stable version of fedora yet.  If the ext3
driver is behind all of this then the problem needs to be found there and fixed.
 It would seem odd that this is the only reported manifestation of a filesystem
bug though.
Comment 38 Glenn Barrett 2006-12-15 11:19:07 EST
I am having this problem as well. However, for a possible fix, I found this link.  


And more specifically this command

rm -f /var/lib/rpm/__db*

After running that command, I succesfully ran a system update and two seperate
package installations without issue. I'm not sure if this is a permenant fix,
but I would imagine that the original problem of database corruption will re-occur.
Comment 39 Joachim Frieben 2006-12-15 16:21:05 EST
(In reply to comment #37)
> Ext4 isn't ready for release in a stable version of fedora yet. ..

To be more precise: even "ext4dev" works fine for me but so does
Comment 40 Chris Lumens 2007-03-19 10:28:33 EDT
*** Bug 232635 has been marked as a duplicate of this bug. ***
Comment 41 matt cowan 2007-06-29 11:01:27 EDT
I've been having this problem very consistently with fedora 7 on a dell
optiplex gx620 sff, pentium d, 2gb ram, 2.6.21-1.3228.fc7 (most recently, but
I've had the problem with every f7 kernel I've tried, including xen variants).  

I've done numerous fresh installs of this system with different package
selections etc. including just the defaults, and very minimal installs,
and always end up with rpmdb corruption after a short while.  The only thing
I haven't yet tried varying or going with the defaults on is the disk
partitioning.  running out of ideas I memtested it and it went through 8 or so
iterations with no issue at which point I stopped it.

Installs fine, but rpmdb gets corrupted some seemingly random time later
(minutes to days), other than the rpmdb the system seems fine and stable. 
Thought some update must have fixed it when I had 5-6 days of uptime, but
happened again yesterday.  I have an identical system which has been running
fc6, 2.6.20-1.2962.fc6xen happily since that kernel came out and 2.6.18/19
before that.

I'll try varying the partitioning, and am in the process of upgrading the
identical fc6 system to f7 to see if it then has issues too.  I have another,
non-identical, system which has been running f7 with no problems.
Comment 42 matt cowan 2007-07-26 13:08:54 EDT
I did a fresh f7 install with default everything, including partitioning, and
still have this issue.

Did a fresh install of fc6 on this system and it's totally stable.

A yum upgrade from fc6 to f7 on an identical system has been totally stable for
some time now.

I'm starting to think the f7 installer kernels have weird issues and that this
is the cause (in this case the installer kernel might cause some rpmdb
corruption which only shows up later???).  I have this rpm problem when doing a
fresh install of a regular system, and when I try to install an f7 xen guest (on
either an fc6 or an f7 (yum upgraded from fc6) host) I get an immediate crash
with irq lock inversion messages.
Comment 43 Peter Åstrand 2007-09-10 04:45:34 EDT
I can confirm this problem. Initially, I tried to upgrade from FC5 to F7, which
failed: see bug 253510. So instead, I tried upgrading from FC5 to FC6. I'm
experiencing the same problem as described by bug 232635: "During the system
installation of RPMs, the system goes crazy (text mode), the screen blinks and
gives a ton of errors". 

Before starting the upgrade, I did an RPM rebuild in the FC5 system. There are a
few F7 packages from the failed F7 upgrade, though. 

It might be that the F7 installer kernel is buggy, or that some of the installed
F7 packages causes this. 

In either case, this is a major pain. 
Comment 44 Nathaniel Daw 2007-09-17 10:07:26 EDT
I have what may be a reproduceable manifestation of the same problem on a system
that has been upgraded to fc7 from previous fedoras. In the past few months I
started having sporadic rpm database corruption during yum and rpm operations,
but with frequent database rebuilding I think the system is up to date,
including kernel-

In any case, I can:

* boot into single user mode
* run rpm --rebuild
* run /usr/lib/rpmdb_verify on all of the indexes and see they are ok
* still in single user mode, run rpm -Va
* have it complete
* run /usr/lib/rpm/rpmdb_verify on all of the indexes and see some are now
corrupt with errors like

db_verify: Page 48: bad page number 63
db_verify: Provideversion: DB_VERIFY_BAD: Database verification failed

The problem seems to be one page replaced in the files.

Now, given the history, this may be some idiosyncratic problem with this
machine's "Packages" database that produces subtly bad indexes from the rebuild
(though it checks out with db_verify, and I have also rebuilt it with dump &
restore); but it seems a lot like the problems reported above, and in any case
surely this isn't the intended behavior of these tools? 
Comment 45 isi.floss 2007-10-08 11:43:10 EDT
I get the "rpmdb: PANIC: fatal region error detected; run recovery" bug if I try
a basic install of FC6, F7, the Fedora 7 Re-Spin 20070912 of fedoraunity or
Fedora 8 Test 3/7.92. This is the same as described in Comment #43, bug 211917
or bug 232635.
Comment 46 Chuck Ebbert 2007-10-08 17:22:41 EDT
(In reply to comment #45)
> I get the "rpmdb: PANIC: fatal region error detected; run recovery" bug if I try
> a basic install of FC6, F7, the Fedora 7 Re-Spin 20070912 of fedoraunity or
> Fedora 8 Test 3/7.92. This is the same as described in Comment #43, bug 211917
> or bug 232635.

Those bugs had multiple causes. Mostly they were due to a kernel bug that was
fixed in 2.6.19, but at least one appears due to some kind of problem with
Adaptec SCSI controllers and another seems to be IDE problems.
Comment 47 Nathaniel Daw 2007-10-08 17:52:04 EDT
(In reply to comment #46)

> Those bugs had multiple causes. Mostly they were due to a kernel bug that was
> fixed in 2.6.19, but at least one appears due to some kind of problem with
> Adaptec SCSI controllers and another seems to be IDE problems.

Can you elaborate on the potential IDE problems? Is this discussed somewhere?

Second, regarding the bug in 2.6.19, could that have caused database corruption
that persist even once the kernel was replaced? and even once the rpmdb was rebuilt?

Comment 48 Eric Sandeen 2008-02-12 22:30:06 EST
What is the filesystem blocksize on the filesystem in question; does it happen
to be < 4k?
Comment 49 Nathaniel Daw 2008-02-13 12:24:30 EST
Yes, I think it was 1K (determined by the minimum size ls -l reports for a
directory? is that right?)

was there a bug related to this?
Comment 50 Eric Sandeen 2008-02-13 12:49:12 EST
stat -f /filesystem will tell you, look at "fundamental block size"

yes, there have been many issues related to this, but I'm far from an answer, yet.
Comment 51 Nathaniel Daw 2008-02-13 23:28:27 EST
Yes it was 1k. And I had fixed the problem by moving the data to a new partition
that's 4k.
Comment 52 Bug Zapper 2008-04-03 22:08:02 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 53 Mohd Izhar Firdaus Ismail 2008-04-26 01:40:56 EDT
i just got a rpm database problem again today of which rpm -qa locks up at some
random package, and caused yum to appear like hanging. Of course rebuilding the
database fixed the problem (temporarily), but it would be better if it never
happened in the first place.

p/s: is this bug really belong to the kernel ??. And i think this affect all
archs (i'm on x86 32bit)
Comment 54 Bug Zapper 2008-05-13 22:05:47 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 55 Bug Zapper 2009-06-09 18:06:49 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 56 Bug Zapper 2009-07-14 13:04:54 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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