The following was filed automatically by anaconda: anaconda 14.22 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1747, in parseFSTab raise Exception("fstab entry %s is malformed: %s" % (devspec, e)) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1342, in mountExistingSystem fsset.parseFSTab() File "/usr/lib64/python2.7/site-packages/pyanaconda/upgrade.py", line 229, in upgradeMountFilesystems mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 212, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 131, in gotoNext self.moveStep() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1190, in nextClicked self.anaconda.dispatch.gotoNext() Exception: fstab entry LABEL=Bootsdc2 is malformed: scanned format (ext3) differs from fstab format (ext4)
Created attachment 457351 [details] Attached traceback automatically from anaconda.
Created attachment 458392 [details] Attached traceback automatically from anaconda.
*** Bug 650410 has been marked as a duplicate of this bug. ***
*** Bug 651336 has been marked as a duplicate of this bug. ***
Created attachment 464642 [details] Attached traceback automatically from anaconda.
For what it is worth: 1. I attempted an upgrade of an existing (updated and happily working) Fedora 12 installation from the Fedora 14 DVD 2. I specified the simple storage mode and selected two devices for the boot. 3. The device in question (md2) is normally built from the four external (ESATA) disks that I left as data disks in the GUI installation options. 4. The contents of /proc/mdstat from the running Fedora 12 is below though I am not sure this is useful. Anybody has an idea what the problem is here? I'm guessing the installer does not support ext4 and a downgrade of the file system to ext3 might fix it? Or just unplug the ESATA drive while I upgrade :-) Allan # cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md2 : active raid5 sdf1[0] sdc1[4] sdd1[2] sde1[1] 2197714944 blocks super 1.2 level 5, 256k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/350 pages [0KB], 1024KB chunk md0 : active raid1 sda1[0] sdb1[1] 104320 blocks [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 976655488 blocks [2/2] [UU] unused devices: <none>
It looks like your md arrays are getting different names in anaconda that they are in your installed system. md0 (as seen by anaconda) contains an ext4 filesystem. md1 contains ext3 and md2 contains an LVM physical volume. You could change your /etc/fstab to use UUIDs instead of paths or you could unplug the unneeded drives. Another option would be to choose "specialized storage" and only include the drives you are interested in.
(In reply to comment #7) > It looks like your md arrays are getting different names in anaconda that they > are in your installed system. md0 (as seen by anaconda) contains an ext4 > filesystem. md1 contains ext3 and md2 contains an LVM physical volume. > > You could change your /etc/fstab to use UUIDs instead of paths or you could > unplug the unneeded drives. Another option would be to choose "specialized > storage" and only include the drives you are interested in. Dave: I can confirm that changing /etc/fstab to use UUID for my two md devices allowed the installer to mount the disks and move on to the next stage. (The installer still can't figure out that /boot is an array (/dev/md0) but that is another problem.) Thank you for your help!
I also encountered this issue (the original): Exception: fstab entry /dev/vg3/f10 is malformed: scanned format (ext3) differs from fstab format (ext4) Since mounting ext3 fs with ext4 driver is a common backward-compatible performance enhancement I found the forced installation stop quite unnecessary.
I personally don't consider this a priority at all. However, if someone else does, they could write code to do a "test mount" as the fstab-specified type, maybe verify a basic write-then-read-back operation and, if that works, set up a new format of that type for the device in question. This could be done as a last resort before throwing the exception from pyanaconda.storage.FSSet._parseOneLine.
It probably isn't a priority. (I found this way that i forgot to upgrade one fs :-) But a simple ext3-ext4 exception should be enough.
Created attachment 494386 [details] Attached traceback automatically from anaconda.
Created attachment 501345 [details] Attached traceback automatically from anaconda.
I tried to upgrade from Fedora 14 to 15. The installation program offered me to upgrade my /boot partition from ext2 to something newer (obviously ext3). but later on the upgrade failed as the /boot partition did have too few space free! after rebooting the machine and freeing some space on /boot I hit this bug, because /boot was already upgraded to ext3 but not the /etc/fstab entry! Please, use the ext4 driver for ext2 and ext3 partitions. Both are supported by ext4 driver and remove this silly check that produces this error.
It's not a silly check. It is code that expects filesystems of type X to be used as type X -- not type Y or type Z. Adding support for this nonsense will actually take a fair amount of work, while it takes almost no work at all for you to adjust your fstab entries so they make sense. If you want to change it back after you install, knock yourselves out.
(In reply to comment #15) > It's not a silly check. It is code that expects filesystems of type X to be > used as type X -- not type Y or type Z. Adding support for this nonsense will > actually take a fair amount of work, while it takes almost no work at all for > you to adjust your fstab entries so they make sense. If you want to change it > back after you install, knock yourselves out. AFAIK the ext4 driver is the only one well maintained and _the way_(tm) to mount even ext2 (see lwn and lklm). Hence it makes perfect sense to have ext4 entries for ext* filesystems in /etc/fstab. PS: Concerning the "no work at all for you to adjust your fstab entries" -- it's important to note that we are speaking about install time, when there possibly is no "no work at all" solution at hand for the average user. Not to the mention the wasted time.
In fact, I've tried David Lehman suggestion of fixing my fstab since it inccorrectly matched /boot to ext2 format and the /boot fs was, in fact ext3. When I've changed the type of file system prior to the upgrade in fedora 14. The upgrade work in a breeze. A better solution would be for anaconda to report the problem in a better way and let the user fixe his fstab somehow.
Created attachment 503105 [details] Attached traceback automatically from anaconda.
Created attachment 503770 [details] Attached traceback automatically from anaconda.
I have a dual boot system (linux/Windows XP). I mount the Windows partitions during the boot - I has to remove the ntfs mounts in order for the installation to proceed. The error indicates that the file system type "ntfs" is not recognized.
(In reply to comment #20) > I have a dual boot system (linux/Windows XP). I mount the Windows partitions > during the boot - I has to remove the ntfs mounts in order for the installation > to proceed. The error indicates that the file system type "ntfs" is not > recognized. What it says is that you are specifying that your vfat filesystems should be mounted as ntfs. Is this something that's expected to work?
Created attachment 524603 [details] Attached traceback automatically from anaconda.
Created attachment 528106 [details] Attached traceback automatically from anaconda.
For what it's worth, there is a fix in anaconda-16.21-1 (Fedora 16) that would prevent this failure for those of you whose fstab mismatches make some sense (eg: ext3 mounted as ext4). The approach is to try a test mount of your filesystem as the type specified in /etc/fstab and, if it works, go with that as the filesystem type. If it fails, you'll still see the error message and be forced to fix your fstab.
*** Bug 701640 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This was in anaconda's upgrade code, which no longer exists. I don't think fedup cares about filesystems. So let's just close it out now.