Red Hat Bugzilla – Bug 431911
Unable to mount ext4dev volume after update to kernel 2.6.24-23.fc9
Last modified: 2008-02-07 23:18:56 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):
Steps to Reproduce:
1. Update to "rawhide" as of 2008-02-07.
2. Reboot system.
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"
Volume /dev/mapper/VolGroup00-LogVol02 is mounted as /home.
- 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
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.
There was a recent update to the ext4 code, so that may have changed something.
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
I've updated http://fedoraproject.org/wiki/FedoraExt4 with this info.
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
I'll update the wiki again.