Bug 429782 - "extents" flag appeared on ext3 filesystem, can't mount filesystem
"extents" flag appeared on ext3 filesystem, can't mount filesystem
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
Blocks: F9Alpha
  Show dependency treegraph
Reported: 2008-01-22 18:10 EST by Charles R. Anderson
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version: kernel-2.6.24-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-28 17:12:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debugfs output showing filesystem flags and superblock stats (26.50 KB, text/plain)
2008-01-22 18:10 EST, Charles R. Anderson
no flags Details

  None (edit)
Description Charles R. Anderson 2008-01-22 18:10:24 EST
Description of problem:

After a fresh rawhide-20080121 install, running the rawhide-20080121 rescue CD
somehow caused the ext3 filesystems / and /boot to gain the "extents" filesystem
flag, making them completely unusable outside of the rawhide system.  In fact,
even the rawhide install itself cannot boot, mount, fsck, or deal with the
filesystems at all.

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

How reproducible:
didn't try

Steps to Reproduce:
1. Install rawhide-20080121 from rescue cd
2. Boot CD into rescue mode
3. Mount stuff, try grub-install, e2label, fsck, etc.
Actual results:

From the rawhide-20080121 rescue CD, I did a manual cryptsetup/vgchange/mount
for the rawhide install.  I needed to add entries to /etc/grub.conf and run
"grub-install" to put grub on the boot sector of /dev/sda3.  My first attempt
was to chroot to /mnt/sysimage and run grub-install there:

sh-3.2# grub-install /dev/sda3
Could not find device for /boot

I thought the filesystem label was the problem, so I tried to
check the labels:

sh-3.2# e2label /dev/sda2
sh-3.2# e2label /dev/sda3
e2label: Filesystem has unsupported feature(s) while trying to open
Couldn't find valid filesystem superblock.

Interesting.  So I tried from outside the chroot.  Same results:

sh-3.2# exit
sh-3.2# e2label /dev/sda2
sh-3.2# e2label /dev/sda3
e2label: Filesystem has unsupported feature(s) while trying to open
Couldn't find valid filesystem superblock.

I thought maybe the filesystem was corrupted, so I tried a manual

sh-3.2# umount /mnt/sysimage/boot
sh-3.2# fsck /dev/sda3
fsck 1.40.4 (31-Dec-2007)
WARNING: couldn't open /etc/fstab: No such file or directory
e2fsck 1.40.4 (31-Dec-2007)
fsck.ext3: Filesystem has unsupported feature(s) while trying to open

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the
superblock is corrupt, and you might try running e2fsck with an
alternate superblock:
    e2fsck -b 8193 <device>

Expected results:

ext4 features shouldn't spontaneously appear on ext3 filesystems.

Additional info:
Comment 1 Charles R. Anderson 2008-01-22 18:10:24 EST
Created attachment 292571 [details]
debugfs output showing filesystem flags and superblock stats
Comment 2 Eric Sandeen 2008-01-23 16:34:19 EST
This appears to be only happening when we probe for root; if ext4 is first in
line, it takes it.

I added a temporary check to ext4_fill_super:

+       if (silent &&
+               goto cantfind_ext4;

so that if we are probing (silent) and there are no extents on the fs,
don't claim it as ext4dev...

if we explicitly mount as -t ext4dev, it'll still mount.  So as long as anaconda
isn't explicitly trying ext4dev before ext3, it should fix things.

committed in : kernel-2_6_24-0_172_rc8_git6_fc9

Comment 3 Eric Sandeen 2008-01-23 16:35:13 EST
putting it into needinfo... if there's a chance for you to test it again :)
Comment 4 Joachim Frieben 2008-01-24 05:07:24 EST
I tried the ext4dev driver 2 days ago, I can confirm that and in contrast
with earlier driver versions like from 1 year ago, this triggered an
irreversible file system change making it impossible to revert from
"rawhide" to F8 which wouldn't be able to mount any volume without prior
formatting. Ok, I should have informed myself better about this, but I
wonder if mounting ext3 partitions as ext4dev ones should be allowed at
all [at least for the time being], restricting its use to volumes which
have actually been -formatted- as such.
This is especially important for the /home volume which one might be
unable to simply reformat in order to get rid of the ext4dev attributes.
Currently, I -must- use a "rawhide" kernel in order to preserve access
my /home volume.
Comment 5 Eric Sandeen 2008-01-24 08:32:52 EST
Very sorry about that; this was unexpected.  Before you use it too much I would
suggest mounting it from now on with -o noextents, so it doesn't create more
"ext4-ish" files.  Then we can do some copy; rm; mv tricks to more extent-files
back to bitmap-format, and I'll get an e2fsprogs in rawhide which can remove the
extents flag, so hopefully you can get back to ext3, unless you want to be an
ext4 tester! :)
Comment 6 Joachim Frieben 2008-01-24 08:51:00 EST
I don't mind at all using ext4dev, so there is no need for me to spend any
effort on reverting to ext3. The problem actually became apparent after
having set all volumes to ext4dev. Then, after the next kernel upgrade
[retrieved from koji] all of a sudden, my "rawhide" system wouldn't boot
anymore but instead I was dropped to the grub command line. This seems to
be the more important issue. I will try to investigate this a bit more.
Comment 7 Eric Sandeen 2008-01-24 09:13:28 EST
Well, grub can't grok ext4 at *all* and that's fairly low on the list...

hopefully you have a separate /boot?

If so I'd boot via rescue, mount the system, copy out /boot, mkfs.ext3 /boot,
copy stuff back, reinstall grub, etc.

Although, I only expected / to get "claimed" as ext4 (well, initially I didn't
expect this at all; now I only expect / under rescue to have this happen...)

Also be aware that there isn't really currently any e2fsprogs which supports
ext4; it should come to rawhide soon-ish.

If you have further trouble please let me know...
Comment 8 Eric Sandeen 2008-01-24 09:45:06 EST
One other note; we didn't ship ext4dev when f8 shipped, although it was in
rawhide.  Upgrading easily from ext3 to ext4 *is* intended, but only if you
explicitly ask it to be mounted as ext4 (which I think you did?)

If it happens that ext4 is not deemed ready for prime time for f9, we will also
remove it there, so that it doesn't trip up the hordes of unwary users.  :)
Comment 9 Joachim Frieben 2008-01-24 13:04:42 EST
The issue occurred on a "rawhide" system after deliberately changing ext3
to ext4dev in /etc/fstab. I have to use CD/DVD install media, and the
last existing to date is F8. I suppose that upcoming F9 alpha will feature
ext4 to be selected at install time - hopefully except for a /boot
partition or a / volume containing /boot.
I have already reinstalled my system from an F8 DVD performing a minimum
install + dhclient + yum. After installing a recent "rawhide" kernel, I
have been able to mount my /home volume which remains converted to ex4dev
but I have a running system back. However, if I understand you correctly,
the latest koji kernel build includes a safety measure to prevent the
root system from being mounted as ext4dev.
Comment 10 Jesse Keating 2008-01-28 17:12:54 EST
Fixed in kernel-2.6.24-2.fc9

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