Bug 431911 - Unable to mount ext4dev volume after update to kernel 2.6.24-23.fc9
Unable to mount ext4dev volume after update to kernel 2.6.24-23.fc9
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-07 14:46 EST by Joachim Frieben
Modified: 2008-02-07 23:18 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-07 16:07:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joachim Frieben 2008-02-07 14:46:07 EST
Description of problem:
After upgrading system to "rawhide" as of 2008-02-07, the /home volume
which used to be mounted successfully as ext4dev until 2008-02-07,
cannot be mounted anymore.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Update to "rawhide" as of 2008-02-07.
2. Reboot system.
Actual results:
System reports during boot-up that /dev/mapper/VolGroup00-LogVol02 cannot
be mounted. Also mounting the volume by hand also fails:
  "[root@fedora ~]# mount -t ext4dev /dev/mapper/VolGroup00-LogVol02 /home
   mount: wrong fs type, bad option, bad superblock on
         missing codepage or helper program, or other error
         In some cases useful info is found in syslog - try
         dmesg | tail  or so"

Expected results:
Volume /dev/mapper/VolGroup00-LogVol02 is mounted as /home.

Additional info:
- This ext4dev volume used to be mounted without problems for recent
  "rawhide" kernels including 2.6.24-17.fc9.
- SELinux is active but mode is "permissive".
- The content of /etc/fstab reads:

  /dev/VolGroup00/LogVol00 /         ext3       defaults        1 1
  /dev/VolGroup00/LogVol01 /usr      ext3       defaults        1 2
  /dev/VolGroup00/LogVol02 /home     ext4dev    defaults        1 2
  LABEL=/boot             /boot      ext3       defaults        1 2
  tmpfs                   /dev/shm   tmpfs      defaults        0 0
  devpts                  /dev/pts   devpts     gid=5,mode=620  0 0
  sysfs                   /sys       sysfs      defaults        0 0
  proc                    /proc      proc       defaults        0 0
  /dev/VolGroup00/LogVol03 swap      swap       defaults        0 0
Comment 1 Joachim Frieben 2008-02-07 15:00:24 EST
When the volume is mounted without specifying the fs type, then one

  sh-3.2# mount /dev/mapper/VolGroup00-LogVol02 /home
  mount: unknown filesystem type 'ext4'

This seems to imply that the fs is labeled or recognized as "ext4" whereas
it used to be handled as "ext4dev". The issue it thus probably due to some
inconsistent use of the fs identifier.
Comment 2 Chuck Ebbert 2008-02-07 15:22:37 EST
There was a recent update to the ext4 code, so that may have changed something.
Comment 3 Eric Sandeen 2008-02-07 16:07:20 EST
blkid recently changed... as did the kernel... welcome to the bleeding edge :)

In short, install e2fsprogs-1.40.5 from rawhide and run "tune2fs -E test_fs
/dev/mapper/VolGroup00-LogVol02" and it should be happy.  If not please reopen.

2 things here; the kernel code rejects the mount if test_fs isn't set, to try to
be sure we don't accidentally claim ext3 filesystems, as well as to put a bit of
an intentional barrier to premature use into place.  :)  If you look at "dmesg"
after the failed mount (as the mount command suggests...) it will say:

+               printk(KERN_WARNING "EXT4-fs: %s: not marked "
+                      "OK to use with test code.\n", sb->s_id);

Perhaps that should give more instruction about the tune2fs command to use.

Also, blkid now reports "ext4" instead of "ext4dev" if the test_fs feature isn't
set, so it tries to mount as ext4 instead of ext4dev.  That's what you saw with
the bare "mount" command.

Technically this is not a bug, but rather design, but it is unexpected.  Sorry
about that.
Comment 4 Eric Sandeen 2008-02-07 16:14:41 EST
I've updated http://fedoraproject.org/wiki/FedoraExt4 with this info.
Comment 5 Eric Sandeen 2008-02-07 23:18:56 EST
Ugh sorry tune2fs won't touch it.  This works:

[root@magnesium]# debugfs -w /dev/sda5
debugfs 1.40.5 (27-Jan-2008)
debugfs:  set_super_value s_flags 4
debugfs:  quit

I'll update the wiki again.

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