Rsync - does it really do an *exact* copy?
hashproduct+rsync at gmail.com
Mon May 29 19:50:35 GMT 2006
On Mon, 2006-05-29 at 17:55 +0200, Paul Slootman wrote:
> On Mon 29 May 2006, martin aa wrote:
> > >
> > > I've just been busy with a new system, and I've been copying over the
> > > root filesystem multiple times with rsync, without any such problems
> > > whatsoever, so at least for me rsync works just fine for that task.
> > Well, that is interesting. I'm using FC5 and, by the looks of your domain name, you're using a debian-based distro. So, I really can't work out what is happening here. As I said in my original post, I can't see how it could be anything other than rsync doing this, but I just can't see how. My understanding is that by using -aH you preserve absolutely everything. Is there some type of file that rsync just can't accurately copy?
> Perhaps extended attributes, if they're used in FC5? If so, I'd expect
> the FC5 version of rsync to support those (although maybe you need an
> extra option for that?) Alternatively, some SE-Linux complications?
> In other words, something's probably involved that's not "old school"
If SE-Linux is enabled, there's a very good chance that it is causing
the problem. SE-Linux expects each file on the system to carry a
security context in the extended attribute "security.selinux". The
kernel assigns contexts to newly created files automatically based on
the system's policy. If a file carries the wrong context, the kernel
may prevent users, even root, from accessing it.
I'm guessing that, when you ran rsync, the system was running on the old
partitions and had the new ones mounted somewhere in /mnt or /media. If
you did not ask rsync to preserve extended attributes (-X or --xattrs),
the files created on the mounted partitions probably got generic "file
on removable device" contexts, not the contexts that they would need for
a system to run on them.
Boot your system once with SE-Linux disabled by passing the argument
"selinux=0" to the kernel. If you use Grub, just press the appropriate
key to "edit the kernel arguments before booting". If the system then
lets you log in, SE-Linux was the problem, and you should either disable
it permanently by putting "selinux=0" in your grub.conf or fix all the
file contexts by running "restorecon -r /".
More information about the rsync