Bug 434844 - e2fsprogs-1.40.4-1.fc8.i386.rpm is not backwards compatible
e2fsprogs-1.40.4-1.fc8.i386.rpm is not backwards compatible
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-25 15:01 EST by Shaun Andrew
Modified: 2008-02-28 10:27 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-28 10:27:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is a dump of filesystem created with e2fsprogs-1.40.4-1.fc8 (1.50 KB, text/plain)
2008-02-25 16:53 EST, Shaun Andrew
no flags Details
This is a dump of filesystem created with e2fsprogs-1.40.2-2.fc7 (1.54 KB, text/plain)
2008-02-25 17:01 EST, Shaun Andrew
no flags Details

  None (edit)
Description Shaun Andrew 2008-02-25 15:01:16 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):

How reproducible:

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!
Comment 1 Eric Sandeen 2008-02-25 15:14:10 EST
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.
Comment 2 Shaun Andrew 2008-02-25 16:53:07 EST
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.)
Comment 3 Shaun Andrew 2008-02-25 17:01:53 EST
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.
Comment 4 Eric Sandeen 2008-02-25 17:12:39 EST
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?

Comment 5 Shaun Andrew 2008-02-26 14:29:36 EST

     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.

Comment 6 Eric Sandeen 2008-02-26 14:47:57 EST
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.
Comment 7 Shaun Andrew 2008-02-27 12:18:02 EST


     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


     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. 
Comment 8 Eric Sandeen 2008-02-28 10:27:29 EST
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.

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