The following was filed automatically by anaconda: anaconda 13.37 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/__init__.py", line 1718, in parseFSTab raise Exception("fstab entry %s is malformed: %s" % (devspec, e)) File "/usr/lib/anaconda/storage/__init__.py", line 1313, in mountExistingSystem fsset.parseFSTab() File "/usr/lib/anaconda/upgrade.py", line 172, in upgradeMountFilesystems mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0) File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1313, in nextClicked self.anaconda.dispatch.gotoNext() Exception: fstab entry /dev/sda3 is malformed: scanned format (ext3) differs from fstab format (swap)
Created attachment 402865 [details] Attached traceback automatically from anaconda.
All indications in your log files indicate that sda3 really is an ext3 filesystem, though your fstab calls it swap. Which is it really?
It could be that we are running into a problem as to what is sda and sdb. sdb3 is a swap device. when booting into rescue mode from the install disk, fdisk gives the following info sda1 ntfs sda2 w95 extd sda3 linux (this should be my /home partition) sda5 ntfs sda6 ntfs sdb1 linux (this should be /boot) sdb2 linux (this should be / for my f12) sdb3 swap sdb4 w95 extd sdb5 linux (this should be / for my f13) sdb5 ntfs As far as I know, this info is correct except that I can change disk order in the bios. The linux system is not currently valid. In the past, to maintain my ability to dual boot into XP, I had to remap my drives in grub. Perhaps anaconda couldn't handle an fstab that came from a different bios disk order?
(In reply to comment #3) > It could be that we are running into a problem as to what is sda and sdb. sdb3 > is a swap device. > > when booting into rescue mode from the install disk, fdisk gives the following > info > > sda1 ntfs > sda2 w95 extd > sda3 linux (this should be my /home partition) > sda5 ntfs > sda6 ntfs > > sdb1 linux (this should be /boot) > sdb2 linux (this should be / for my f12) > sdb3 swap > sdb4 w95 extd > sdb5 linux (this should be / for my f13) > sdb5 ntfs > > As far as I know, this info is correct except that I can change disk order in > the bios. The linux system is not currently valid. In the past, to maintain my > ability to dual boot into XP, I had to remap my drives in grub. Perhaps > anaconda couldn't handle an fstab that came from a different bios disk order? sda / sdb order may change with BIOS order, but is mostly dependend upon when the kernel probes which disk, as the kernel does probing in parallel now a days, which disk is sda and which one is sdb may differ even from boot to boot. Now a days specifying partitions by their /dev/sdx# path in fstab is considered a bad idea, you should use UUID= instead. When does this happen? When you choose to upgrade your system, or before you get the change to choose between upgrading or installing ?
This happens after choosing upgrade. I had two systems on the drive (as stated in comment 3). Both had their fstab created by fedora installs so they should have been ok. It shouldn't make a difference, but for completeness, this was a vnc install since x was not working on this system.
Thanks for the input. If this happens after choosing upgrade, then this is not a bug, we cannot upgrade systems with invalid info in their fstab (which is why we do the sanity checking of fstab). So you need to fix your fstab, note btw, that if as you say your current install is non functional, upgrading might not be the best of ideas. The upgrade could fix things, but things might still be broken after the upgrade.
I just did a minimal install of f13 beta rc3 on the above system. fstab lists swap as /dev/sdb3, no uuid so this problem can happen again. I didn't test to see what would happen if I asked for the swap partition to be reformatted.
*** Bug 579507 has been marked as a duplicate of this bug. ***
Created attachment 407628 [details] Attached traceback automatically from anaconda.
My situation is slightly different. I have "auto" as filesystem in fstab.
I hit that with my fstab mounting an ext3 filesystem as ext4. I read somewhere that this was encouraged. I'll try setting it to ext3 and see what happens. As a side note, anaconda froze in the process requiring some SysRq magic to see the traceback.
*** Bug 587919 has been marked as a duplicate of this bug. ***
*** Bug 591821 has been marked as a duplicate of this bug. ***
*** Bug 595901 has been marked as a duplicate of this bug. ***
*** Bug 595916 has been marked as a duplicate of this bug. ***
*** Bug 595975 has been marked as a duplicate of this bug. ***
*** Bug 596116 has been marked as a duplicate of this bug. ***
*** Bug 596462 has been marked as a duplicate of this bug. ***
Chris, it seems like you're marking a lot of bugs as dupes of this bug, not all of which are the same case, and some of which seem reasonably legitimate: things like 'ntfs-3g' and 'auto' in the fstab. Surely anaconda could be somewhat more liberal in such cases? Do you have a plan for tackling this sort of problem in the future? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 596508 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Chris, it seems like you're marking a lot of bugs as dupes of this bug, not all > of which are the same case, and some of which seem reasonably legitimate: > things like 'ntfs-3g' and 'auto' in the fstab. Surely anaconda could be > somewhat more liberal in such cases? Do you have a plan for tackling this sort > of problem in the future? I'm looking at it now. My current plan is to just ignore (and preserve) lines in /etc/fstab that describe filesystems we don't support (eg: ntfs-3g). As for "auto"... I'm not sure yet what I want to do with that. The other case I *might* loosen things up for is people who mount extX filesystems as extY. I'm thinking people should have their systems in better shape than that if they expect to perform an upgrade, though.
*** Bug 596616 has been marked as a duplicate of this bug. ***
*** Bug 596863 has been marked as a duplicate of this bug. ***
*** Bug 597500 has been marked as a duplicate of this bug. ***
*** Bug 597497 has been marked as a duplicate of this bug. ***
*** Bug 597522 has been marked as a duplicate of this bug. ***
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 599119 has been marked as a duplicate of this bug. ***
The handling of auto and of unrecognized filesystem types like ntfs-3g is present in anaconda-14.7-1. People who specify their extX filesystems as extY in /etc/fstab can track that issue in bug 599119.
Why has this bug been closed? I don't see any reference to a fix for the subject matter of the bug that was actually reported. Namely, older versions of fedora set up swap as /dev/sdxx on multiple disk systems but the disk order can change for install and anaconda complains. A new install properly used UUID for swap but even an f13 beta install had this problem. Does the "fix" remain, fix your fstab?
(In reply to comment #30) > Why has this bug been closed? I don't see any reference to a fix for the > subject matter of the bug that was actually reported. Namely, older versions of > fedora set up swap as /dev/sdxx on multiple disk systems but the disk order can > change for install and anaconda complains. A new install properly used UUID for > swap but even an f13 beta install had this problem. Does the "fix" remain, fix > your fstab? There is nothing we can do if your /etc/fstab is just plain incorrect. It's unfortunate, but yes -- you will have to fix it. It would be good practice to replace the device paths with the filesystem/swap UUID in any case.
(In reply to comment #31) > > There is nothing we can do if your /etc/fstab is just plain incorrect. It's > unfortunate, but yes -- you will have to fix it. It would be good practice to > replace the device paths with the filesystem/swap UUID in any case. Since this error was not a user error (fstab was set up by a fedora install) but caused by a change in how fedora works, this is a very sad situation. At the very least, 1) abort without crashing since anaconda knows what happened, it just doesn't have any safe way to proceed. 2) suggest to the user that he can fix his fstab by adding the UUID's reported by blkid
Regarding auto file system type: I don't know how it has been solved in rawhide, but I have a tip: util-linux-ng package contains library detecting file system type by magic bytes in superblock. You could use it if you wanted to reveal file system type.
*** Bug 610161 has been marked as a duplicate of this bug. ***
Created attachment 430922 [details] Attached traceback automatically from anaconda.
*** Bug 622154 has been marked as a duplicate of this bug. ***
Reading this, I will research: 1) howto fixup fstab. For me, I think it is a BIOS issue. I have a SATA disk running under IDE emulation, and I think the sda/sdb designation is ambiguous. I will change fstab to UUID's. The emulation is set because the system is dual booted with winXP, and I was too lazy to slipstream the SATA driver into the XP install media a couple of years ago. Now, I would probably have to re-install XP, if I did the slipstream and removed the emulation 2) How to use rescue when I screw up. I will need a copy of the liveCD, as well as the install DVD. 3) Write a blog post ?
*** Bug 624373 has been marked as a duplicate of this bug. ***
Created an attachment (id=442736) Attached traceback automatically from anaconda.
(In reply to comment #39) > Created an attachment (id=442736) > Attached traceback automatically from anaconda. Yours is a good example of why you should use UUID= instead of a device path. What has happened is this: the order in which the kernel discovers your disks has changed, causing them to have different names. What was sda in your old system is now sdc. To fix the immediate problem, replace "/dev/sda1" with "UUID=aa6a23dc-336c-4a6d-9857-c78feb13a2f8" in your /etc/fstab file. You should repeat this action for all other partitions identified by path in that file. Just partitions, though -- logical volumes are not subject to the same changes.
actually, I did replace sd? references with UUID=, but the upgrade would not proceed until I also corrected the fstab line for the boot partition, changing the "ext2" to the correct "ext3" file system. I am going to vote with the group who think think that anaconda is just too damn picky. This is a major stumbling block for the "less technical". I am just not patient enough, I continued to run fc12 until I had a free Sunday afternoon to decode the idiotic drivel from the python traceback.
*** Bug 646774 has been marked as a duplicate of this bug. ***
*** Bug 699882 has been marked as a duplicate of this bug. ***