No subject

the copy had been interrupted for some reason.
Fortunately it wasn't.

>> I edited the target's fstab.
>> LABEL=sata400-17        /    ext3    defaults        1 1

Here I made a big booboo.
I'd forgotten I'd had a separate /var .
The result was that the two shared a /var .

>>>  the fstab&  Grub menu post-cloning steps would almost surely result in 
> damage
>>>  to the F15 source, if not complete destruction, once is upgrade is begun.
>
>> My first F15 install includes four partitions,
>> one for / , one for /boot and two for swap.
>> The copy uses the same /boot and swap partitions.

Oops. See above.

> I suppose someone with a lot of experience could get away with sharing a 
> /boot partition, but based upon your experiences of the past month I wouldn't 
> expect that group to include you. I would have merged the content of the 
> /boot partition into the /boot directory on the new /.
>
>> Here are my grub stanzas:
>> title Fedora 15 (2.6.42.12-1.fc15.i686.PAE)  sdb17
>>   	root (hd1,1)
>>   	kernel /vmlinuz-2.6.42.12-1.fc15.i686.PAE ro root=/dev/sdb17
>>   	initrd /initramfs-2.6.42.12-1.fc15.i686.PAE.img
>
> Leaving off some of those cmdline options could be a problem. I'm not 
> familiar with all of them, and so would have included all I don't understand.

Me too.  I just edited poorly.

>> title Fedora 15 (2.6.42.12-1.fc15.i686.PAE)  sdb3
>>   	root (hd1,1)
>>   	kernel /vmlinuz-2.6.42.12-1.fc15.i686.PAE ro 
> root=UUID=ce978949-d044-4020-8001-02454648a64e rd_NO_LUKS rd_NO_LVM rd_NO_MD 
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet
>>   	initrd /initramfs-2.6.42.12-1.fc15.i686.PAE.img
>
>> I can boot sdb3.
>> sdb17 fails.

Here is what I did:
Established that I could still boot my first F15, sdb3.
Added the options mistakenly removed from kernel line in menu.lst .
Made a filesystem in new partition, sdb18, for the new /var .
Booted F15 under sdb17, yaaaay.
Tried and failed to login.
Established that I could still login to my first F15.
Tried for a gnome session under the new F15, still no go.
Trying to login from a text console gave me permission errors, even for root.
Added enforcing=0 to the kernel line.
Booted and logged in to the new F15, yaaaay.

My next trick should be to fix the need for enforcing=0.
Should triggering an automatic relabeling do that?
Why does SELinux need fixing?
Do its rules reference sectors, absolute or relative?

>> Any ideas?
>
> 1-Do it again with rsync or a program designed specifically for cloning.
> 2-Merge /boot partition into the new /.
> 3-Either find out if any of those cmdline options can play a part in the 
> problem and put back the ones you don't know you don't need, or add them all 
> back except rhgb & quiet
> 4-Add option enforcing=0 to cmdline to ensure SELinux isn't in the way
> 5-Use the Grub on hd1,1 to start both, but for the clone include a hd1,16 
> configfile stanza until you get it booted, then install Grub on sdb17 and 
> afterward chainload from hd1,1 to hd1,16, where updates will ultimately be 
> applied to grub.conf only for the clone on account of new kernels.

I'll definitely need to fix /boot .
The best case scenario is that it gets really cluttered
when I start updating kernels on multiple OSs.

-- 
Michael   hennebry at web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword."  --  Lily