Bug 434844 - e2fsprogs-1.40.4-1.fc8.i386.rpm is not backwards compatible
Summary: e2fsprogs-1.40.4-1.fc8.i386.rpm is not backwards compatible
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 8
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-25 20:01 UTC by Shaun Andrew
Modified: 2008-02-28 15:27 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-02-28 15:27:29 UTC
Type: ---
Embargoed:


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 21:53 UTC, 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 22:01 UTC, Shaun Andrew
no flags Details

Description Shaun Andrew 2008-02-25 20:01:16 UTC
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!

Comment 1 Eric Sandeen 2008-02-25 20:14:10 UTC
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 21:53:07 UTC
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 22:01:53 UTC
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 22:12:39 UTC
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

Comment 5 Shaun Andrew 2008-02-26 19:29:36 UTC
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.



Comment 6 Eric Sandeen 2008-02-26 19:47:57 UTC
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 17:18:02 UTC
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. 

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