Description of problem: When installing a system using the "Nouveau Test Day" live CD with anaconda updated to release 11.5.0.38-1, ext3 has been chosen for the root volume (custom partitioning). Anaconda accepts the input, formats all volumes flagged correspondingly and then copies the live image to the hard disk. However, when the installer proceeds to performing the final stage, an error message pops up, "An error occurred mounting device /dev/mapper/VolGroup00-LogVol00 as /: mount failed: (2, None). This is a fatal error and the install cannot continue.", and the installer aborts. Version-Release number of selected component (if applicable): anaconda-11.5.0.38-1 How reproducible: Always. Steps to Reproduce: 1. Launch liveinst. 2. Choose ext3 for root volume. Actual results: After copying the live image to the hard disk, the installer aborts because the root volume cannot be mounted. Expected results: Installer proceeds to finishing the new setup. Additional info: - A further trial reveals that the root volume has been actually formatted as an ext4 file system and not as an ext3 one as chosen and accepted by the partitioning tool. - Choosing ext4 instead of ext3 allows to perform the install without problem. - Either ext3 is inadmissible, then liveinst has to reject this choice explicitly, or it has to format the volume as an ext3 one which would have allowed to mount the root volume after the copy stage correctly.
*** Bug 493139 has been marked as a duplicate of this bug. ***
*** Bug 493224 has been marked as a duplicate of this bug. ***
*** Bug 493374 has been marked as a duplicate of this bug. ***
We used to do the changing behind the user's back (eg, if you selected ext2 instead of ext3). With the storage rewrite, we seem to have lost that. On the plus side, it's now a little easier to actually check in the sanity checking and give you an indication when you do your installation that you need to select ext4 (or whatever the live image is) instead. Patch to do so sent for comments, should be in rawhide in a day or three
*** Bug 493206 has been marked as a duplicate of this bug. ***
*** Bug 493461 has been marked as a duplicate of this bug. ***
Thanks for looking into this Jeremy. I've found a little information that may or may no help you. I created an ext3 partition using fdisk and mke2fs, and I ran Anaconda and told it not to format the partition, but just to mount / to it, and it still managed to try converting it to ext4 unsuccessfully. I don't understand how it does that if it's not supposed to be formatting anything.
same here: I formatted the root partition in ext3 from another linux distro (using gparted). Then I install, but asked it *not* to format the "/" partition. I got the same "can't mount" error at the end of the install, and checking back, the partition is now appearing as ext4. So it formatted it, or changed it to ext4 somehow.
(In reply to comment #7) > I don't understand how it does that if it's not supposed to be formatting > anything. You can't not do a format of the rootfs with the live install -- the way the live install works is that we copy over the rootfs from the livecd as a direct block copy and then resize to fill the size you wanted.
So if you do a non-live install, you don't have to format? Does the DVD do non-live installs? I haven't really used Fedora extensively since before the LiveCDs came out. Could there be another way to do the install? Being a Gentoo user, you download a tarball and extract it to your rootfs, and really all it does is dump all the files and directories onto it. Couldn't Fedora just do something like that? So instead of formatting the filesystem, just dump the files onto it? Is there anything that Anaconda does that would make this impossible?
Fixed in git
Is there a rawhide ISO built with the fix implemented?
*** Bug 493948 has been marked as a duplicate of this bug. ***
*** Bug 494050 has been marked as a duplicate of this bug. ***
Created attachment 338337 [details] dmesg
Created attachment 338338 [details] anaconda log before this call trace
*** Bug 495234 has been marked as a duplicate of this bug. ***
*** Bug 496465 has been marked as a duplicate of this bug. ***
*** Bug 497060 has been marked as a duplicate of this bug. ***
This is not fixed. Fedora 11 liveCD. :(