Bug 577260 - Exception: fstab entry /dev/sda3 is malformed: scanned format (ext3) differs from fstab format (swap)
Summary: Exception: fstab entry /dev/sda3 is malformed: scanned format (ext3) differs ...
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: anaconda_trace_hash:3bb71b3a2d89971c2...
Keywords: CommonBugs, Reopened
: 579507 587919 591821 595901 595916 595975 596116 596462 596508 596616 596863 597497 597500 597522 610161 622154 624373 646774 699882 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-26 15:21 UTC by shmuel siegel
Modified: 2011-04-26 20:59 UTC (History)
31 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-06-08 15:48:48 UTC


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (265.69 KB, text/plain)
2010-03-26 15:22 UTC, shmuel siegel
no flags Details
Attached traceback automatically from anaconda. (259.81 KB, text/plain)
2010-04-19 16:34 UTC, Tomasz Torcz
no flags Details
Attached traceback automatically from anaconda. (561.73 KB, text/plain)
2010-07-10 22:45 UTC, Xiaotian Sun
no flags Details
Attached traceback automatically from anaconda. (833.47 KB, text/plain)
2010-09-02 21:31 UTC, Phillip Lahman
no flags Details

Description shmuel siegel 2010-03-26 15:21:59 UTC
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)

Comment 1 shmuel siegel 2010-03-26 15:22:04 UTC
Created attachment 402865 [details]
Attached traceback automatically from anaconda.

Comment 2 Chris Lumens 2010-03-26 15:46:56 UTC
All indications in your log files indicate that sda3 really is an ext3 filesystem, though your fstab calls it swap.  Which is it really?

Comment 3 shmuel siegel 2010-03-27 19:12:13 UTC
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?

Comment 4 Hans de Goede 2010-03-29 08:15:12 UTC
(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 ?

Comment 5 shmuel siegel 2010-03-29 09:13:22 UTC
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.

Comment 6 Hans de Goede 2010-03-29 09:27:39 UTC
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.

Comment 7 shmuel siegel 2010-04-01 21:56:03 UTC
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.

Comment 8 Chris Lumens 2010-04-05 19:45:46 UTC
*** Bug 579507 has been marked as a duplicate of this bug. ***

Comment 9 Tomasz Torcz 2010-04-19 16:34:34 UTC
Created attachment 407628 [details]
Attached traceback automatically from anaconda.

Comment 10 Tomasz Torcz 2010-04-20 05:52:10 UTC
My situation is slightly different. I have "auto" as filesystem in fstab.

Comment 11 Julian Sikorski 2010-04-27 22:07:01 UTC
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.

Comment 12 Chris Lumens 2010-05-02 00:40:57 UTC
*** Bug 587919 has been marked as a duplicate of this bug. ***

Comment 13 Chris Lumens 2010-05-13 13:48:44 UTC
*** Bug 591821 has been marked as a duplicate of this bug. ***

Comment 14 Chris Lumens 2010-05-25 21:27:34 UTC
*** Bug 595901 has been marked as a duplicate of this bug. ***

Comment 15 Chris Lumens 2010-05-25 22:52:49 UTC
*** Bug 595916 has been marked as a duplicate of this bug. ***

Comment 16 Chris Lumens 2010-05-26 04:45:31 UTC
*** Bug 595975 has been marked as a duplicate of this bug. ***

Comment 17 Chris Lumens 2010-05-26 13:44:57 UTC
*** Bug 596116 has been marked as a duplicate of this bug. ***

Comment 18 Chris Lumens 2010-05-26 19:25:34 UTC
*** Bug 596462 has been marked as a duplicate of this bug. ***

Comment 19 Adam Williamson 2010-05-26 20:36:20 UTC
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

Comment 20 Chris Lumens 2010-05-26 20:38:50 UTC
*** Bug 596508 has been marked as a duplicate of this bug. ***

Comment 21 David Lehman 2010-05-26 21:14:40 UTC
(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.

Comment 22 Chris Lumens 2010-05-27 14:20:08 UTC
*** Bug 596616 has been marked as a duplicate of this bug. ***

Comment 23 Chris Lumens 2010-05-27 16:59:10 UTC
*** Bug 596863 has been marked as a duplicate of this bug. ***

Comment 24 Chris Lumens 2010-05-29 11:27:10 UTC
*** Bug 597500 has been marked as a duplicate of this bug. ***

Comment 25 Chris Lumens 2010-05-29 11:27:39 UTC
*** Bug 597497 has been marked as a duplicate of this bug. ***

Comment 26 Chris Lumens 2010-05-29 11:27:46 UTC
*** Bug 597522 has been marked as a duplicate of this bug. ***

Comment 27 Adam Williamson 2010-05-31 22:03:45 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 28 Chris Lumens 2010-06-02 17:56:21 UTC
*** Bug 599119 has been marked as a duplicate of this bug. ***

Comment 29 David Lehman 2010-06-08 15:48:48 UTC
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.

Comment 30 shmuel siegel 2010-06-09 00:53:05 UTC
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?

Comment 31 David Lehman 2010-06-09 19:38:19 UTC
(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.

Comment 32 shmuel siegel 2010-06-09 20:44:46 UTC
(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

Comment 33 Petr Pisar 2010-06-25 08:12:26 UTC
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.

Comment 34 Chris Lumens 2010-07-01 17:08:43 UTC
*** Bug 610161 has been marked as a duplicate of this bug. ***

Comment 35 Xiaotian Sun 2010-07-10 22:45:22 UTC
Created attachment 430922 [details]
Attached traceback automatically from anaconda.

Comment 36 Chris Lumens 2010-08-09 13:53:55 UTC
*** Bug 622154 has been marked as a duplicate of this bug. ***

Comment 37 Herbert Carl Meyer 2010-08-10 10:44:20 UTC
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 ?

Comment 38 Chris Lumens 2010-08-16 14:12:17 UTC
*** Bug 624373 has been marked as a duplicate of this bug. ***

Comment 39 Phillip Lahman 2010-09-02 21:31:22 UTC
Created an attachment (id=442736)
Attached traceback automatically from anaconda.

Comment 40 David Lehman 2010-09-02 21:52:02 UTC
(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.

Comment 41 Herbert Carl Meyer 2010-09-03 10:55:15 UTC
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.

Comment 42 Brian Lane 2010-10-26 21:54:13 UTC
*** Bug 646774 has been marked as a duplicate of this bug. ***

Comment 43 Chris Lumens 2011-04-26 20:08:14 UTC
*** Bug 699882 has been marked as a duplicate of this bug. ***

Comment 44 Chris Lumens 2011-04-26 20:59:39 UTC
*** Bug 699882 has been marked as a duplicate of this bug. ***


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