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 tar-1.15.1-28.fc7.i386.rpm.) Version-Release number of selected component (if applicable): e2fsprogs-1.40.4-1.fc8 How reproducible: always 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 Actual results: image is for Redhat 8.0. Redhat 8.0 enters kernel panic when it encounters the filesystem. Cannot load init. Expected results: Redhat 8.0 should BOOT-UP without any problems Additional info: 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? Thanks, -Eric
Eric, 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.
Eric, 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 ext2/3 filessytems... 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.