Bug 145307 - news ext3 not compatible with ghost
news ext3 not compatible with ghost
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-17 04:46 EST by Remi COLLET
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-17 07:42:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Remi COLLET 2005-01-17 04:46:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
Can't use ghost on FC3 partition.

I know bug #138866 and bug #138419 but it's not a partition table
problem. Seems to be a problem with new ext3 features (online resize).

Ghost crash when i try to "logical" dump a FC3 partition (ok with
"physical" dump).

1st test
- booting from FC2 CD in rescue mode
- saving the partition (tar cf ...)
- mke2fs -j -L /boot /dev/hda2
- restoring the partition (tar xf ...)
- ghost works well

2nd test
- booting from FC3 CD in rescue mode
- mke2fs -j -L /boot /dev/hda2
- restoring the partition
- ghost crash

3rd test
- booting from FC3 CD in rescue mode
- mke2fs -j -L /boot -O ^resize_inode /dev/hda2
- restoring the partition
- ghost crash

Ok, it's probably a "ghost" problem (and symantec says "fedora" is not
supported) but i'm searching for a "simple" workaround (at install time)

Cordialy

Version-Release number of selected component (if applicable):
e2fsprogs-1.35-11.2

How reproducible:
Always

Steps to Reproduce:
1. install FC3
2. try to ghost a partition
3.
    

Actual Results:  ghost crash

Expected Results:  success

Additional info:
Comment 1 Thomas Woerner 2005-01-17 07:42:49 EST
I'd say ghost is not compatible with ext3. Indeed, this is a ghost bug.

It might be a solution to drop the journal and to use these partitions as ext2
partitions.

Closing as not a bug.
Comment 2 Stephen Tweedie 2005-01-17 09:39:31 EST
It's not an ext3 bug, but the incompatibility is ineed likely to be
due to the addition of the online resize inode.  That addition has
already been made upstream --- ghost needs to be modified to
understand it if it is going to work on newer filesystems, and RHEL-4
will have the same feature so it's something they might want to work
on now.

Disabling online resize by deleting the resize inode manually,
clearing the feature flag and running fsck may be a workaround for now.
Comment 3 Remi COLLET 2005-01-18 12:32:14 EST
Can you tell us how to "delete the resize inode manually" as the
"tune2fs -O ^resize_inode ..." didn't work.

Thanks.
Comment 4 Denis Charland 2005-01-20 16:34:58 EST
I downloaded e2progs-1.36-rc3 from Sourceforge, compiled and 
installed the new utilities. On all filesystems, I used debugfs to 
remove "resize-inode" feature and ran e2fsck. Everything was done in 
single-user mode with all filesystems unmounted, including /. Still 
unabled to ghost partitions.
Comment 5 Denis Charland 2005-01-21 10:33:26 EST
Added myself to the CC list.
Comment 6 Stephen Tweedie 2005-01-21 12:37:37 EST
re comment #4:

I've just been checking the latest e2fsprogs from bitkeeper, and using
debugfs to remove the resize_inode feature then fscking does seem to
correctly remove all traces of the resize inode from the superblock.  

After that, there's basically only one sign left that there was ever a
resize inode: the bitmaps and inode blocks won't be 100% at the start
of the block group for any block group with a superblock.

But that's legal for ext2/3, and can happen for other reasons such as
the presence of bad blocks, or if the mke2fs -R stride=$N option is
used.  If ghost cannot cope with that, it's a ghost bug.
Comment 7 Stephen Tweedie 2005-01-21 12:44:31 EST
re comment #3:

The way to delete the resize inode using FC3 e2fsprogs is:

  # debugfs -w /dev/$foo
  debugfs 1.35 (28-Feb-2004)
  debugfs:  feature ^resize_inode
  Filesystem features: has_journal filetype sparse_super
  debugfs:  kill_file <7>
   
  debugfs:  quit
  # e2fsck -fy /dev/$foo

This clears the feature flag, kills the resize inode (which is always
inode number 7), then forces a fsck to cleanup the disk blocks that
were previously owned by the resize inode.
Comment 8 Remi COLLET 2005-01-22 05:55:02 EST
re comment #7

The debugfs solution works (it clears the feature flag).

But after, ghost 7.5 is still unable to logical dump the partition.
Ghost 9.0 automaticaly do a physical dump.

So i will continue to tar/mke2fs/untar the partitions before using
ghost and wait for a patch from symantec.

Thanks for the time used on this problem.
Comment 9 Denis Charland 2005-01-24 13:52:52 EST
I think that the resize_inode feature is not the only one that Ghost 
does not recognize. There's also the ext_attr feature that is new in 
FC3 ext2/ext3 filesystems and it's not and easy job to remove it.

I tried to remove this feature from the root filesystem using debugfs 
and e2fsck in single-user mode. It took a long time for e2fsck to 
completly check the filesystem because it had to fix the i_blocks and 
the i_file_acl of every inode on the filesystem. The result was an 
unusable filesystem.

Stephen, do you have any idea how to safely remove the ext_attr 
feature from an ext3 filesystem so I can try to Ghost it?
Comment 10 Stephen Tweedie 2005-01-24 14:22:43 EST
e2fsck ought to do it.

But FC3 includes SELinux, and installs a minimal, targetted SELinux
policy by default.  That simply won't work if you have deleted all the
extended attributes, as you'll have destroyed all of the filesystem
labels that SELinux requires.  To recover you'd need to disable
SELinux entirely (boot from a rescue disk and set SELINUX=disabled in 
/etc/sysconfig/selinux.)

If e2fsck's xattr clearing renders a box unbootable due to SELinux,
that's not a bug --- you don't expect an SELinux box to survive the
loss of its security labels.  

But if e2fsck was doing something else that actually corrupted the
filesystem, then please open that as a separate bug.
Comment 11 Denis Charland 2005-01-24 14:36:37 EST
I already tried to perform a fresh install of FC3 with SELinux option 
disabled but the ext_attr feature is still present on the root 
filesystem. Then I tried to remove the feature following the same 
procedure that I described in comment #9. The result was also an 
unusable filesystem.
Comment 12 Stephen Tweedie 2005-01-24 14:49:45 EST
What do you mean by an "unusable filesystem"?  What was the failure mode?
Comment 13 Denis Charland 2005-01-24 15:32:32 EST
After booting in single-user mode and umounting / (still mounted but 
read-only) so I can run e2fsck, I run the following commands:

sh-3.00# debugfs -w /dev/sda2 -R "features ^ext_attr"

sh-3.00# e2fsck -y -f /dev/sda2

.
.
.
.

/: ***** FILE SYSTEM WAS MODIFIED *****
/: ***** REBOOT LINUX *****
/: 133033/1310720 files(0.5% non-contiguous...

sh-3.00# reboot
sh: reboot: command not found
sh-3.00# ls
ls: error loading shared librairies: librt.so.1: cannot open shared 
object 
file: no such file or directory
sh-3.00# init 0

After a few INIT messages, system hangs

Then I poweroff and poweron the system:

After the kernel is uncompressed and booted, I get the following 
messages:

exec of init (/sbin/init) failed!!!: 2
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!

The system hangs.
Comment 14 Stephen Tweedie 2005-01-24 15:50:33 EST
It is extremely dangerous to do this --- you should always boot from a
rescue CD when attempting such surgery on a root filesystem.  Does the
same occur if you do that?
Comment 15 Denis Charland 2005-01-24 16:29:13 EST
Yes it does and e2fsck tells you that you should not run e2fsck on a 
mounted filesystem, even if I selected the read-only option when I 
booted from the rescue CD. It is not possible to umounted it because 
it's busy.

If a run e2fsck anyway, it takes about two hours to complete and the 
result is the same.

In single-user mode, you can umount / and in stays mounted in read-
only mode so you can run e2fsck on it. That's the reaseon why I ran 
debugfs and e2fsck in single-user mode.
Comment 16 Stephen Tweedie 2005-01-24 16:46:45 EST
You should avoid mounting it at all from the rescue CD.  The rescue CD
should give you a minimal environment including fsck within which you
can remove the xattrs, without ever mounting it in the first place.
Comment 17 Denis Charland 2005-01-25 10:27:38 EST
You're right, it's the skip option when you boot from the rescue CD. 
Selecting this option does not mount any filesystem on your disk. 
Unfortunately, it didn't change anything. I still get a corrupted 
root filesystem after running e2fsck.

This morning, I will try with e2progs-1.36-rc3 to see if the problem 
has been fixed. I know there's a lot of bugs in version 1.35. But I 
will have to build my own rescue CD to include the updated version of 
e2progs.
Comment 18 Denis Charland 2005-01-25 14:12:44 EST
I didn't find a way to create a rescue disk which would include. I 
did everything in single-user mode with e2progs-1.36-rc3.

This should not be a problem considering the fact that, when you 
answer Y when you are asked to run a consistency check after booting 
a system that was not properly shutdowned and there are too many 
errors on the filesystem, you are asked to run fsck manually. You are 
then brought to a shell in single-user mode with the root filesystem 
mounted read-only.

I still get a corrupted root filesystem with e2progs-1.36-rc3. I 
submitted a bug report to Theodore Ts'o.
Comment 19 Denis Charland 2005-01-25 17:22:32 EST
Good news.

I tried to ghost only the /boot partition on a fresh FC3 installation 
with SELinux disabled. I got the same error message from Ghost. Then 
I removed the ext_attr feature from /boot using the procedure 
described above. Unlike the root filesystem, /boot didn't get 
corrupted. I was then able to Ghost /boot succesfully.

Conclusion: Ghost does not like the ext_attr feature of FC3 ext2/ext3 
filesystems. The resize_inode feature does not affect Ghost. This 
applies to / and /boot only; /home is not affected even if the 
ext_attr feature is present.

The only question that remains is "why does the root filesystem gets 
corrupted after removing the ext_attr feature". If we can find an 
answer to this question, then we will have a workaround for the Ghost 
problem.
Comment 20 Stephen Tweedie 2005-01-26 11:48:42 EST
Can you please open a separate bug report for the xattr corruptions on
e2fsck?  I'm currently trying to reproduce that (using Xen
virtualisation from rawhide, wish me luck.)
Comment 21 Remi COLLET 2005-01-26 12:49:22 EST
After doing
- fresh FC3 installation (SElinux disable)
- boot on FC2 rescue CD
- tar cf xxx /
- mke2fs -j -L / -O dir_index /dev/hda
- tar xf xxx
nb ; ext_attr not set
- boot FC3 cause an fsck ( only on / ) which set the ext_attr feature on.

Ghost 7.5 works well for this partition, so i think it's only a
"resize_inode" problem. (and ext_attr was already present on FC2)
Comment 22 Denis Charland 2005-01-26 14:39:31 EST
Remi, the fact that ext_attr feature is on does not necessarily means 
that Ghost will not work. Try to Ghost by partition instead and 
select /home and you will see that it works even if both ext_attr and 
resize_inode are set.

On / and /boot filesystems, all the files also have their extended 
ACL entries set (extended attributes), which is not the case 
on /home. That's the reason why /home can be Ghosted even if ext_attr 
is set.

When you remove the ext_attr with debugfs and the run e2fsck, e2fsck 
clears the extended ACL entries on all files. The filesystem can then 
be Ghosted even if resize_inode is still set. Moreover, if you use 
debugfs to set the ext_attr on again, you're still able to Ghost the 
filesystem because the extented ACL entries are not set on the files.

In your procedure, when you boot FC3, fsck sets the ext_attr feature 
on but does not set the extended ACL entries on the files. That 
explains why you're able to Ghost the partition.

In FC2, ext_attr was already present but the extented ACL entries on 
the files were not set. FC3 installation sets the extended ACL 
entries of the files on / and /boot. The extended ACL entries are 
necessary for the implementation of SELinux which was nonfunctional 
in FC2 due to kernel and policy incompatibilities.

If you want to see the extended attributes of a file on a fresh FC3 
installation, say /etc/passwd, type the following command:

getfattr -m . -d /etc/passwd
Comment 23 Denis Charland 2005-01-27 09:30:32 EST
I opened a separate bug report for the xattr corruptions on
e2fsck. Bug report #146284.
Comment 24 Denis Charland 2005-01-27 09:35:56 EST
Adding a link to bug report #146284:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146284
Comment 25 Denis Charland 2005-01-31 15:27:59 EST
Here's the procedure to remove resize_inode and ext_attr features 
from filesystems on an FC3 installation. Everything must be done from 
the root account.

Step 1

If you installed FC3 with SELinux enabled, which is the default, it 
you must disabled. Log on the system and edit /etc/selinux/config. 
Replace SELINUX=enforced by SELINUX=disabled. If you don't disable 
SELinux, the ext_attr will be set again on the root filesystem the 
next time you boot and every file created or modified will have its 
extended ACL entries set.

Step 2

Download e2fsprogs-1.36-rc5 from SourceForge. Click on the following 
link:

    http://sourceforge.net/projects/e2fsprogs

Step 3

Untar, compile and install the new utilities:

   tar -zxf e2fsprogs-1.36-rc5.tar.gz
   cd e2fsprogs-1.36-rc5
   ./configure
   make
   make install

Step 4

Reboot the system in single-user mode:

   type reboot

   at the GRUB splash screen, press enter then press the 'a' and
   add the word single at the end of the command line (there's a space
   between quiet and single)

Step 5

Unmount all filesystems, including /, and remove both resize_inode 
and ext_attr features. Run the following commands on all filesystems:

   debugfs -w /dev/XXXX -R "features ^resize_inode ^ext_attr"
   e2fsck -y -f /dev/XXXX

Example:

   /dev/sda1 is mounted on /boot
   /dev/sda2 is mounted on /
   /dev/sda5 is mounted on /home

   umount /boot
   umount /
   umount /home

   debugfs -w /dev/sda1 -R "features ^resize_inode ^ext_attr"
   debugfs -w /dev/sda2 -R "features ^resize_inode ^ext_attr"
   debugfs -w /dev/sda5 -R "features ^resize_inode ^ext_attr"

   e2fsck -y -f /dev/sda1
   e2fsck -y -f /dev/sda2
   e2fsck -y -f /dev/sda5

Running e2fsck on the root filesystem takes a while.

Step 6

Reboot the system.

During shutdown, you will get error messages telling you that the 
root filesystem cannot be written. That's normal because the root 
filesystem is still mounted read-only. It must remain mounted read-
only during shutdown.

During boot, you will get a message telling you that the system was 
not properly shutdown and ask you if you want to verify the 
filesystem integrity. You can skip this step. It didn't find anything 
wrong on my system.

Your system is now ready to be Ghosted.
Comment 26 Denis Charland 2005-02-02 12:07:36 EST
For people who want to keep the online resizing capability and have 
SELinux enabled after Ghosting a system or after restoring FC3 on an 
another system (cloning), the features can be readded to the 
filesystems and the extended ACL entries can be restored from a 
backup file. You must create the backup file just before step 4 in 
the above procedure. Here's how to create it:

   find / -exec getfattr -d -h -m . --absolute-names {} \; 
> /home/attr.backup

The filename and it's location can be anything you want.

Here's the procedure to restore the filesystem features and the 
extended ACL entries:

Step1

Reboot the system in single-user mode:

   type reboot

   at the GRUB splash screen, press enter then press the 'a' and
   add the word single at the end of the command line (there's a space
   between quiet and single)

Step 2

Unmount all filesystems, including /, and add both resize_inode 
and ext_attr features. Run the following commands on all filesystems:

   debugfs -w /dev/XXXX -R "features resize_inode ext_attr"
   e2fsck -y -f /dev/XXXX

Example:

   /dev/sda1 is mounted on /boot
   /dev/sda2 is mounted on /
   /dev/sda5 is mounted on /home

   umount /boot
   umount /
   umount /home

   debugfs -w /dev/sda1 -R "features resize_inode ext_attr"
   debugfs -w /dev/sda2 -R "features resize_inode ext_attr"
   debugfs -w /dev/sda5 -R "features resize_inode ext_attr"

   e2fsck -y -f /dev/sda1
   e2fsck -y -f /dev/sda2
   e2fsck -y -f /dev/sda5

Step3

Reboot the system, logon as root, restore the extended ACL entries 
from the backup file and enable SELinux:

   setfattr -h --restore=/home/attr.backup

Replace SELINUX=disabled by SELINUX=enforced in /etc/selinux/config.

Reboot system.
Comment 27 gadfium 2005-08-15 18:36:37 EDT
I'm the developer of Symantec Ghost support for Linux. Ghost is unable to
intelligently clone the default ext2 and ext3 filesystems configured by Fedora
Core 3 for three reasons: it doesn't understand resize_inode, acls or LVM. This
is a Ghost problem, not a Fedora problem.

The next version of Ghost (which will be part of Ghost Solution Suite 1.x) will
support ACLs as implemented in FC3, and will partially support the resize_inode
by disabling this feature in any filesystem it creates. It's too early to say
whether it will support drives in logical volumes.

A suggested workaround at present is to use the -IAL (Image All Linux) switch to
Ghost, which will make a sector copy of Linux partitions while still
intelligently cloning FAT and NTFS partitions. This will result in much larger
image files, longer cloning times, inability to resize Linux partitions, and on
some systems (those that have a diagnostic partition before any Linux partition,
for example), may leave GRUB or LILO unable to boot.
Comment 28 Stephen Tweedie 2005-08-16 06:44:13 EDT
Thanks for the update.  If there's any information we can provide to help with
this work, please feel free to ask me.

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