> ----- Original Message ----- > From: "Matt McCutchen" <[EMAIL PROTECTED]> > To: "martin aa" <[EMAIL PROTECTED]> > Subject: Re: Rsync - does it really do an *exact* copy? > Date: Mon, 29 May 2006 15:50:35 -0400 > > > 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" > > unix. > > 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 /". > > Matt
Fixed! Thanks very much Paul and Matt - very good advice! It was SE-Linux that was the culprit as you suggested. And you were right Matt that the extended attributes were not copied across. I don't think I would have had this problem if the man page was correct. With the FC5 distro, the man page for rsync doesn't match the version (which is 2.6.6). That is, if I 'man rsync' there is no information at all in regards to the -X (--xattrs) option. (Nor does the man page say anything about the -A (--acls) option.) However, the usage information (running rsync --help) shows both these options. A lot of time would have been saved if that inconsistancy hadn't existed - oh well, as they say: "rsync comes with ABSOLUTELY NO WARRANTY" (!) Also, the man page (and usage info) says for the -a option: -a, --archive archive mode; equivalent to -rlptgoD (no -H) which, IMHO, I think should actually say: -a, --archive archive mode; equivalent to -rlptgoD (no -H, -X, -A) Thanks again for your insightful advice. Regards, Martin Ps. What about a supercharged archive option (like -aa) which does -rlptgoDHXA ?? -- _______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
