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): kernel-2.6.24-23.fc9 How reproducible: Always. 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 /dev/mapper/VolGroup00-LogVol02, 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
When the volume is mounted without specifying the fs type, then one obtains: 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 about that.
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 debugfs: quit I'll update the wiki again.