Yes I had thought along these lines as I originally
had the source partition mounted.
The case shown below was with the source unmounted
and hence I believe the errors are present in source partition.
I have seen this suggestion but I don't know enough
about SELinux to feel confident about using it.
Disable selinux; reboot and then
find . -exec setfattr -h -x security.selinux '{}' \;
John
On Wed, 3 Mar 2010, John Austin wrote:
> Date: Wed, 03 Mar 2010 13:06:11 +0000
> From: John Austin <ja(a)jaa.org.uk>
> Reply-To: ja(a)ee.port.ac.uk,
> Community support for Fedora users <users(a)lists.fedoraproject.org>
> To: users(a)lists.fedoraproject.org
> Subject: Dump/Restore Errors
>
> Hi
>
> I have been following recent threads about the best way to clone/backup
> disks.
>
> "Risks of backing up live mounted filesystems using dump(8)"
>
> I have just tested dump/restore using a System Rescue CD
> using dump 0.4b42
>
> The source /dev/sda7 is a fully working updated F12 / partition
> (including /boot)
>
> The destination is a similar partition on the same disk /dev/sda9
>
> mkfs -t ext3 /dev/sda9
> mkdir /mnt/out
> mount /dev/sda9 /mnt/out
> dump 0f - /dev/sda7 | (cd /mnt/out; restore -rf -)
> 40GB dump/restore took 46 minutes
>
> I received 9 errors of the type
>
> resync restore, skipped 1 blocks
> error in EA block 1
> magic = 0
>
> Google tells me that dump saves as is
> and that restore is finding an error in an Attribute Block
> (maybe/sometimes associated with NFS)
>
> I have not been able to find definitive answers to some obvious
> questions.
>
> 1. Are these fatal for the file concerned hence invalidating the clone/backup?
> I am unsure how to interpret the error message
>
> 2. Why are they present in the first place?
>
> 3. How can I find which files they are caused by?
>
> 4. Can I correct the errors, do I need to?
>
> Grateful for any help
>
> Regards
> John
On Wed, 2010-03-03 at 18:56 -0600, Paul Thompson wrote:
I believe these generally fall on files which were deleted between when
the index was created and the file is reached in the backup.
Hi Paul
Yes I had thought along those lines as I originally
had the source partition mounted.
However I repeated the dump/restore and the case shown above was
with the source unmounted and hence I believe the errors are
present in the source partition/file system.
I assume something is wrong in the SElinux extended attributes?
I have seen this suggestion for "processing" the source file system
before executing the dump/restore.
However I don't know enough about SELinux to feel confident about using it.
Disable selinux; reboot and then
find . -exec setfattr -h -x security.selinux '{}' \;
Is it a good idea to zap all SELinux attributes in the first place?
a. When the partition/file system is / for the operating system
b. When the partition/file system is mounted from a rescue CD boot?
John