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):
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
LANG, LC_ALL are "de_DE.UTF8"
Try this to fix:
mv __db* SAVE
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
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.
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.
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)
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 ?
File "/usr/sbin/pup", line 377, in main
pup = PackageUpdater()
File "/usr/sbin/pup", line 77, in __init__
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:
ts: <rpmUtils.transaction.TransactionWrapper instance at 0x2b4e31908ea8>
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
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
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
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
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
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.
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
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
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.
(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
*** 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
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,
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
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
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
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:
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:
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.