|Summary:||rpmdb: PANIC: fatal region error detected; run recovery|
|Product:||[Fedora] Fedora||Reporter:||Joerg Skottke <jsk_priv>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Version:||9||CC:||ahz001, astrand, cowan, daw, dgregor, duffy, esandeen, herrold, hypetech, jfrieben, landemaine, mishu, pnasrat, rc040203, redhat-bugzilla, simon.andrews, timborn, triage, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-14 17:04:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Joerg Skottke 2006-02-13 18:03:55 UTC
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: Always 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 18:16:43 UTC
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 18:26:32 UTC
Created attachment 124572 [details] Output from yum -y update evolution*
Comment 3 Joerg Skottke 2006-02-13 18:29:34 UTC
Ooops - i did not expect/notice the quick reply. I'm trying, it might take a few minutes.
Comment 4 Joerg Skottke 2006-02-13 18:36:16 UTC
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 19:06:11 UTC
OK. Sounds like a fix, reopen if you need more help.
Comment 6 Joerg Skottke 2006-02-13 19:09:53 UTC
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 19:22:27 UTC
Hmmm.... 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 19:50:11 UTC
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 05:25:30 UTC
Created attachment 124665 [details] Output from rpm -Uvv xorg*
Comment 10 Mike A. Harris 2006-02-22 04:16:47 UTC
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 20:59:03 UTC
Hi! 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 (5bd1f61966a17d237dadc325928bbbc005d5ef0a) D: BinÃÂ¤r-Paket hinzugefÃÂ¼gt (Added binary package)
Comment 12 Joerg Skottke 2006-02-26 15:14:08 UTC
The issue has been confirmed at least once on the fedora mailing list.
Comment 13 Jeff Johnson 2006-03-08 23:17:14 UTC
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 14:01:49 UTC
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 14:15:27 UTC
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 ? main() 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__ self.doConfigSetup() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 102, in doConfigSetup 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 19:01:02 UTC
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 13:38:21 UTC
Yes it does, results from comment 14 and comment 15 happen on a fresh install.
Comment 18 Joerg Skottke 2006-04-06 13:46:40 UTC
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 14:38:46 UTC
That seems odd - are there any hints in dmesg?
Comment 20 Joerg Skottke 2006-04-07 08:22:11 UTC
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 14:07:34 UTC
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 18:13:38 UTC
Fresh install of fc6 (final) shows same problem for both i386 and x86_64. :(
Comment 23 Joerg Skottke 2006-10-29 18:40:20 UTC
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 18:29:59 UTC
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 18:50:20 UTC
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-05 00:12:44 UTC
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 package!
Comment 27 Joachim Frieben 2006-11-13 20:54:42 UTC
Annoying: random freezes again with "kernel-2.6.18-1.2849.fc6".
Comment 28 Paul Nasrat 2006-11-14 08:48:22 UTC
Joachim, if you boot into 1.2835 is all well again?
Comment 29 Joachim Frieben 2006-11-14 11:29:44 UTC
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 11:40:46 UTC
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 11:44:02 UTC
*** Bug 211917 has been marked as a duplicate of this bug. ***
Comment 32 Paul Nasrat 2006-11-14 11:54:40 UTC
Dave any idea what changes between FC6 gold, 2835 and 2849 may account for this.
Comment 33 Simon Andrews 2006-11-16 09:22:04 UTC
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 05:16:56 UTC
Hi, this just happened to me on my IBM T41 running a 4.5 mo old install of FC5 final. 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 19:26:59 UTC
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 10:37:31 UTC
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 10:50:24 UTC
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 16:19:07 UTC
I am having this problem as well. However, for a possible fix, I found this link. http://www.rpm.org/hintskinks/repairdb/ 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 21:21:05 UTC
(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 "ext3".
Comment 40 Chris Lumens 2007-03-19 14:28:33 UTC
*** Bug 232635 has been marked as a duplicate of this bug. ***
Comment 41 matt cowan 2007-06-29 15:01:27 UTC
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 17:08:54 UTC
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 08:45:34 UTC
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 14:07:26 UTC
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-188.8.131.52-76.fc7. 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 15:43:10 UTC
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 21:22:41 UTC
(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 21:52:04 UTC
(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-13 03:30:06 UTC
What is the filesystem blocksize on the filesystem in question; does it happen to be < 4k?
Comment 49 Nathaniel Daw 2008-02-13 17:24:30 UTC
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 17:49:12 UTC
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-14 04:28:27 UTC
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-04 02:08:02 UTC
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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 05:40:56 UTC
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-14 02:05:47 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 55 Bug Zapper 2009-06-09 22:06:49 UTC
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 56 Bug Zapper 2009-07-14 17:04:54 UTC
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.