Bug 429782
Summary: | "extents" flag appeared on ext3 filesystem, can't mount filesystem | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Charles R. Anderson <cra> | ||||
Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | CC: | jfrieben, kernel-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | kernel-2.6.24-2.fc9 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-01-28 22:12:54 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 428703 | ||||||
Attachments: |
|
Description
Charles R. Anderson
2008-01-22 23:10:24 UTC
Created attachment 292571 [details]
debugfs output showing filesystem flags and superblock stats
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 && + !EXT4_HAS_INCOMPAT_FEATURE(sb,EXT4_FEATURE_INCOMPAT_EXTENTS)) + 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 putting it into needinfo... if there's a chance for you to test it again :) Thanks, -Eric 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. 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! :) 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. 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... 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. :) 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. Fixed in kernel-2.6.24-2.fc9 |