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"
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?
Created attachment 124572 [details] Output from yum -y update evolution*
Ooops - i did not expect/notice the quick reply. I'm trying, it might take a few minutes.
OK, the proposal appears to work, the database is accessible again. I just started a "yum -y update" which will take considerably more minutes ;-)
OK. Sounds like a fix, reopen if you need more help.
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.
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 ...
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?
Created attachment 124665 [details] Output from rpm -Uvv xorg*
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.
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)
The issue has been confirmed at least once on the fedora mailing list.
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.
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.
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
Does this happen with FC5 final? Please do a fresh install and test, as upgrades from test releases to final are not supported.
Yes it does, results from comment 14 and comment 15 happen on a fresh install.
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.
That seems odd - are there any hints in dmesg?
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.
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.
Fresh install of fc6 (final) shows same problem for both i386 and x86_64. :(
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
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.
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
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!
Annoying: random freezes again with "kernel-2.6.18-1.2849.fc6".
Joachim, if you boot into 1.2835 is all well again?
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].
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.
*** Bug 211917 has been marked as a duplicate of this bug. ***
Dave any idea what changes between FC6 gold, 2835 and 2849 may account for this.
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.
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.
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.
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 ..
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.
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.
(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".
*** Bug 232635 has been marked as a duplicate of this bug. ***
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.
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.
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.
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-2.6.22.5-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?
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.
(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.
(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?
What is the filesystem blocksize on the filesystem in question; does it happen to be < 4k?
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?
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.
Yes it was 1k. And I had fixed the problem by moving the data to a new partition that's 4k.
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
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)
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
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
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.