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:
Could resolve the problem by re-formatting the partition in a running F11 to ext4 before installing.
*** Bug 530293 has been marked as a duplicate of this bug. ***
May be related to the /mnt/sysroot confusion seen in Bug #527302
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
Created attachment 369990 [details] Attached traceback automatically from anaconda.
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.
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?
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?
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.
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.
Created attachment 381946 [details] Attached traceback automatically from anaconda.
Created attachment 387835 [details] Attached traceback automatically from anaconda.
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.
Created attachment 399615 [details] Attached traceback automatically from anaconda.
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).
easy to solve = remove /var from destination drive (or what i did everyting except /home folder)
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..)
Created attachment 423709 [details] Anaconda TB
(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.
alweiner: Did you ask for formating the / or /var partition in the custom layout?
(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 "/".
Just confirming that formatting the root partition solves this problem.
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
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.
*** Bug 684334 has been marked as a duplicate of this bug. ***
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.