Red Hat Bugzilla – Bug 149159
ext3 partitions from Fedora cannot be checked by other distros e2fsprogs
Last modified: 2007-11-30 17:11:00 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041110 Firefox/1.0 Description of problem: I was using Fedora Core 3 for AMD64 to create ext3 partitions. I installed Gentoo on it. When trying to boot, I get error messages from the filesystem check fsck.ext3: Filesystem has unsupported feature(s) (/) e2fsck: Get a newer version of e2fsck! and bail out into the maintenance console. It's no problem to mount the partition, but you cannot run e2fsck on it. You'll always get that message shown above. After re-formatting the ext3 partitions under Gentoo and Knoppix there were no more problems. A second thing I wondered about was a log-file in Fedora's /var/log-directory, that was shown with a size of 1.2TByte from out of Gentoo. I only have a 160Gb harddrive, so it's impossible. It's not only me who was affected by this behaviour. So a defect of my harddrive cannot be the cause. Version-Release number of selected component (if applicable): e2fsprogs-1.35-11.2 How reproducible: Always Steps to Reproduce: 1. Format a partition with ext3 under Fedora Core 3 for AMD64. 2. Boot Gentoo Linux. 3. Gentoo will bailout before mounting local filesystems during the initial check. Actual Results: ext3 partitions formatted with Fedora are not useable for other distros. Expected Results: ext3 partitions should be useable from every distro, regardless which distro was used to create them. If everything goes bad, a loss of data can be caused by this behaviour. Additional info:
First of all, every new feature of ext3 requires an e2fsprogs upgrade. That has applied in the past to features like large file support, EA/ACLs, htree directories and sparse superblocks. It now applies to the online resize functionality. This is not a bug. Use a newer e2fsck, or format without the new feature. As for the 1.2TB file in /var/log/, I guess that's the lastlog file. That's a sparse file which contains one entry for each user, and if you have a large uid (typically the nobody or nfsnobody user), that creates a block near the end of the file. So the file's size as reported by ls -l looks large; but the amount of space it occupies, as shown by "du", will be small. This, too, is not a bug.