Red Hat Bugzilla – Bug 434844
e2fsprogs-1.40.4-1.fc8.i386.rpm is not backwards compatible
Last modified: 2008-02-28 10:27:29 EST
Description of problem: I image disks, which run earlier versions of Redhat and
Fedora. Overtime e2fs features have changed. I have been able to turn off
unsupported features for older versions of Redhat and Fedora when building their
filesystems using Fedora 8. Since I upgraded my Fedora 8 system, via a yum
upgrade on 02/19/2008, I can no longer build backward compatible e2fs file
systems. Yum upgraded my system from e2fsprogs-1.40.2-12.fc8 to
e2fsprogs-1.40.4-1.fc8. (yum also upgrade tar to tar-1.17-7.fc8.i386.rpm, which
is also used by my disk imaging system.)
I have reverted to my Fedora 7 system disk that I keep on standby for
emergencies. It still works, and it uses e2fsprogs-1.40.2-2.fc7 with
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. mkfs -t ext2 -L /boot -O has_journal,^dir_index,^resize_inode /dev/sdc1
2. mount /dev/sdc1 /seti/p1
3. tar -xzpf 2b37c_ios_xx330a.tar.gz
image is for Redhat 8.0. Redhat 8.0 enters kernel panic when it encounters the
filesystem. Cannot load init.
Redhat 8.0 should BOOT-UP without any problems
The latest release of e2fsprogs for Fedora 8 is NOT backward compatible!
What is the panic?
Odds are you just need to turn off some new feature that is getting set.
Can you run the mkfs with both old & new e2fsprogs, and after each do "dumpe2fs
-h /dev/whatever" and attach both here? or at least tell me how big /dev/sdc1
is and I can probably replicate.
Created attachment 295848 [details]
This is a dump of filesystem created with e2fsprogs-1.40.4-1.fc8
This is a dump of a filesystem created with e2fsprogs-1.40.4-1.fc8. The
filesystem was created for a Redhat 8.0 system disk. The disk will not boot.
(Bootable disk for Redhat 8.0 can be created with prior versions of e2fsprogs
in Fedora 8.)
Created attachment 295849 [details]
This is a dump of filesystem created with e2fsprogs-1.40.2-2.fc7
This is a dump of filesystem created with e2fsprogs-1.40.2-2.fc7. The
filesystem is for a Redhat 8.0 system disk. The Redhat 8.0 System disk boots
and functions perfectly created under e2fsprogs-1.40.2-2.fc7
I am still working on "rolling back" e2fsprogs in Fedora 8 to the prior
e2fsprogs-1.40.2-12.fc8, which worked. For now I am attaching the filesystem
dump produced with my backup imaging system, which still runs Fedora 7.
the only real difference appears to be that the 1.40.2-2.fc7 e2fsprogs
filesystem had the "signed directory hash" filesystem flag set, while the 1.40.4
filesystem did not.
How did the RHL 8.0 box fail, what were the messages at boot?
I noticed that difference also.
I dropped back to e2fsprogs-1.40.2-12.fc8 ... same thing
I then upgraded my Fedora 8 Imaging System with e2fsprogs-1.40.6.tar.gz
... same thing.
Could the problem be with the tar utility? I write the files via tar,
although I do not have problems restoring system images of Fedora 3 and up.
I do not think Fedora 8 could every build a Redhat 8.0 compatible e2fs. I
have used my Fedora 8 system to build only Fedora 3, 5, and 7 system disk, but
NOT Redhat 7.2 and Redhat 8.0 system disk as I reported earlier.
My Fedora 7 Imaging System can build ALL. I just turn off non-supported
features for older e2fs filesystems.
I am having to abandon Fedora 8.
If you could *please* tell me how the RHL8 boot failed it would offer a clue,
and perhaps we'd know what went wrong, and could fix it.
I SOLVED MY PROBLEM!!!
The problem is NOT with e2fsprogs, but with TAR!!!
I clobbered the Fedora 8 tar, tar-1.17-7.fc8.i386.rpm, on my Fedora 8
Imaging System with the Fedora 7 tar, tar-1.15.1-28.fc7.i386.rpm using:
rpm -Uvh --force --nodeps tar-1.15.1-28.fc7.i386.rpm
NOW MY FEDORA 8 IMAGING SYSTEM IS BACKWARD COMPATABLE!!!
The problem is either with the GNU tar-1.17 or with Fedora 8's patches to
it. In either case, older e2fs filesystems are not being supported with the
current tar utility.
tar really should not have any interoperability problems with any version of the
For now I'll close as NOTABUG since you report that it is not an e2fsprogs issue.
If you do any more investigation to find out *details* of what is wrong, feel
free to (re)open a bug against the proper component.