Bug 520044 - YumBaseError: Error: rpmdb open failed
Summary: YumBaseError: Error: rpmdb open failed
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 12
Hardware: athlon
OS: Linux
low
high
Target Milestone: ---
Assignee: Martin Sivák
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: anaconda_trace_hash:cb368f4850978ecd9...
: 530293 684334 (view as bug list)
Depends On:
Blocks: 528143 730906
TreeView+ depends on / blocked
 
Reported: 2009-08-28 05:56 UTC by Joachim Backes
Modified: 2011-08-16 07:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 528143 (view as bug list)
Environment:
Last Closed: 2010-12-05 06:32:11 UTC


Attachments (Terms of Use)
anaconda TB (227.41 KB, text/plain)
2009-08-28 05:56 UTC, Joachim Backes
no flags Details
Attached traceback automatically from anaconda. (226.05 KB, text/plain)
2009-11-18 00:33 UTC, John Mellor
no flags Details
Attached traceback automatically from anaconda. (215.13 KB, text/plain)
2010-01-06 10:28 UTC, Igor Zhang
no flags Details
Attached traceback automatically from anaconda. (501.28 KB, text/plain)
2010-01-31 13:11 UTC, E Mair
no flags Details
My Anaconda traceback (299.72 KB, text/plain)
2010-02-20 15:14 UTC, Thomas White
no flags Details
Attached traceback automatically from anaconda. (178.72 KB, text/plain)
2010-03-12 10:02 UTC, Alexey Kuznetsov
no flags Details
Anaconda TB (428.61 KB, text/plain)
2010-06-13 23:31 UTC, alweiner7
no flags Details

Description Joachim Backes 2009-08-28 05:56:17 UTC
Created attachment 358993 [details]
anaconda TB

Description of problem:
Trying to make a fresh install of F12 alpha into an existing partition crashes with traceback. 

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

F12 alpha
How reproducible:


Steps to Reproduce:
1.Start from F122 alpha DVD
2.Select custom layout for disk partitions
3.
  
Actual results:
Anaconda crashes

Expected results:
installed F12

Additional info:

Comment 1 Joachim Backes 2009-08-28 07:28:23 UTC
Could resolve the problem by re-formatting the partition in a running F11 to ext4 before installing.

Comment 2 Chris Lumens 2009-10-22 12:34:11 UTC
*** Bug 530293 has been marked as a duplicate of this bug. ***

Comment 3 Henrik Nordström 2009-10-24 19:28:40 UTC
May be related to the /mnt/sysroot confusion seen in Bug #527302

Comment 4 Bug Zapper 2009-11-16 11:47:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 John Mellor 2009-11-18 00:33:30 UTC
Created attachment 369990 [details]
Attached traceback automatically from anaconda.

Comment 6 John Mellor 2009-11-18 00:44:53 UTC
BLOCKER BUG REQUIRING A NEW RELEASE IMAGE
Unable to install product.
I feel like I'm talking to deaf ears.  This bug and several minor variants of same has been present and repeatedly reported in Rawhide (f11+), F12alpha, F12Beta, and now F12release.  How about a fix this time?  F12 is effectively useless without a new install image with a correction.

Comment 7 Martin Sivák 2009-11-18 08:07:13 UTC
No you are not talking to a deaf ears. Sorry for not responding to every report about this, but we just can't reproduce it.

Can you give us a detailed reproducer so we can actually see what is going on?

Comment 8 John Mellor 2009-11-21 16:06:34 UTC
The system is a Dell T800r, which has 2 drives, an 11GB and a 4GB on the same PATA2 cable, a floppy and a DVD reader, a Dell NV2-based nvidia graphics card, 512MB RAM, and a P3 processor@800MHz.

The problem seems to be related to having more than one drive in the root pv.

I'm not sure how to get more detailed information than that.  Is there a way to put Anaconda into debug mode as it starts up?

Comment 9 Martin Sivák 2009-11-23 08:08:29 UTC
You can pass 'debug' argument on the boot prompt and during stage2 (the graphical part of UI) you can also use the second VT (C-A-F2).

During the whole install we show logs on 3rd and 4th VT. The logs can be also found in /tmp during the install.

Comment 10 John Mellor 2009-11-24 00:34:51 UTC
It looks like I'm getting a device ready error on the second disk at sector 0 while writing the journal.  I can see this multiple times on the F4 console.  Then the F3 console shows the error that is attached, as a Yum error.

Comment 11 Igor Zhang 2010-01-06 10:28:07 UTC
Created attachment 381946 [details]
Attached traceback automatically from anaconda.

Comment 12 E Mair 2010-01-31 13:11:36 UTC
Created attachment 387835 [details]
Attached traceback automatically from anaconda.

Comment 13 Thomas White 2010-02-20 15:14:22 UTC
Created attachment 395269 [details]
My Anaconda traceback

Hi all,

I experienced a very similar problem a few days ago.  I was trying to install over a previous installation (of a different RPM-based distro, Scientific Linux), and I hadn't told Anaconda to format the /var and /tmp partitions.  To me, it looks like the old information in the /var partition may have confused Anaconda.  Trying again, this time formatting both partitions, made the rest of the installation go smoothly.

So, if you're having this problem and are doing anything other than installing from scratch to a completely clean disk, make sure that there's no possibility of an old RPM database hanging around.

Comment 14 Alexey Kuznetsov 2010-03-12 10:02:08 UTC
Created attachment 399615 [details]
Attached traceback automatically from anaconda.

Comment 15 Alexey Kuznetsov 2010-03-12 10:13:36 UTC
that is easy to reproduce, as i understand this problem: anaconda try to determine which version of fedora already installed on hard drive and die on try.

I think that exception peprecede Uprade/Fresh install screen.

I think anaconda try to connect to /var/rpm_db and crash when found some uncompabile values (for example fedora 13 when f12 installer works).

Comment 16 Alexey Kuznetsov 2010-03-12 10:14:32 UTC
easy to solve = remove /var from destination drive (or what i did everyting except /home folder)

Comment 17 Martin Sivák 2010-05-18 14:01:33 UTC
This might actually make sense, incompatible or missing rpmdb might confuse Yum and we are not catching this kind of exception.

But I'm not sure what are we supposed to do about it, we cannot just erase some directory from upgraded system, that's asking for accidentaly removing something useful... (like rpmdb in perfect condition or /var/www for example)

I think we are facing two use cases then:

- For install I would say you should always format /var area (because during plain install you do not want to keep that stuff, it would be upgrade if you wanted)

- For upgrade.. does just changing repo to newer version and running yum upgrade work? Corrupted or incompatible rpmdb or partition/filesystem is not really a case for us either, that is not something we can fix in the program code.. (without crystal ball that is..)

Comment 18 alweiner7 2010-06-13 23:31:39 UTC
Created attachment 423709 [details]
Anaconda TB

Comment 19 alweiner7 2010-06-13 23:33:12 UTC
(In reply to comment #18)
> Created an attachment (id=423709) [details]
> Anaconda TB    

Sorry, this is my first use of bugzilla. Here is my textual info:

I encountered this problem while trying to do a fresh install of F13 32-bit DVD on a PC with F11 currently installed. I specified a "custom layout" to use the same partitioning setup for F13 that I'm currently using for F11.

Anaconda progresses to the point where it would prompt for package selection. It encounters an "unhandled exception".

rpmdb: Program version 4.8 doesn't match environment version 4.7
error: db3 error (-30971) from dbenv -> open: DB_VERSION_MISMATCH

This is the HDD setup on my PC:

HDD1: (sda) The MBR that I use for booting is here. GRUB is installed in that HDD.

HDD2: (sdb)  All of my Linux partitions are here: Fedora "/" is sdb6. Fedora "/boot" is sdb5. Fedora /home" is sdb9.

Also of note: whenever I run the installer, a fresh copy of the file "rhinstall-install.img" is stored in sdb1. There is no legitimate reason that I can see for the installer to store anything in sdb1. sdb1 contains a collection of downloaded documents.

Anaconda TB attached.

Comment 20 Martin Sivák 2010-06-14 10:45:18 UTC
alweiner: Did you ask for formating the / or /var partition in the custom layout?

Comment 21 alweiner7 2010-06-15 02:00:33 UTC
(In reply to comment #20)
> alweiner: Did you ask for formating the / or /var partition in the custom
> layout?    

Upon viewing your response to my comment I reran the installer and specified that "/" should be formatted. The install completed successfully.

Thanks for spelling out that I should have Anaconda format "/". Earlier, I had read the discussion in this thread about formatting "/var". I misinterpreted this to mean manually formatting "/var" before running Anaconda. I don't have a separate partition for "/var". It didn't occur to me that those who don't have a separate partition for "/var" should have Anaconda format "/".

Comment 22 Milos Jakubicek 2010-08-20 12:02:05 UTC
Just confirming that formatting the root partition solves this problem.

Comment 23 Bug Zapper 2010-11-04 10:19:41 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 24 Bug Zapper 2010-12-05 06:32:11 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.

Comment 25 Chris Lumens 2011-03-11 20:27:17 UTC
*** Bug 684334 has been marked as a duplicate of this bug. ***

Comment 26 Ganapathi Kamath 2011-03-11 22:17:35 UTC
copy comment from bug 684334

It took me some time to figure it out.
I just got the fedora-15 alpha up and running.
resolution: 
Check the format partition for each linux partition.

Here is a the use-case scenario leading to this.

* Brand new hard disk

* Choose Manually create your own partition
   In this option there is no explicit option to indicate that one is doing do a upgrade or a clean install.

* First time around, the user (me) knows the drive is unformatted and remembers to explcitly format and create a file sysstem for each partition. 

* Start installing. The installation-scripts know that they are installing to a blank partitions and proceed.  Very soon after, the laptop switches off abruptly due to overheating (Something was blocking the fan outlets). It is possible, in /mnt/sysimage, the rpm repository in sysimage was partially initialized/invalid.

* Second time around,  the user forgets/does not think formatting is necessary again. (Because he/she believes that was done the last time around), (This in hind sight appears to be an oversight, and the error also seems meaningfull in hindsight, but there is nothing to clue the user at the time of error as to what the real problem is)

* on continuation error shows up, and user suspects bad DVD/installation script.

* User wastes quite a bit of time, before hitting on the solution. 

Suggestion
------------
a) immediately upon partition info selection, test for this condition whether installation is to proceed as an upgrade on unclean disk / back .  
b) Trap the error and indicate that as a possible cause, ask user to format partition

It might be a bad idea to automatically clean the rpm-db as it may legitly be a upgrade of a previously installed system, in which case maybe other options to restore sysimage's rpmdb should be provided.


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