On Mon, 9 Apr 2012, Felix Miata wrote:
On 2012/04/08 17:08 (GMT-0500) Michael Hennebry composed:
Felix Miata wrote:
On 2012/04/06 15:24 (GMT-0500) Michael Hennebry composed:
On Fri, 6 Apr 2012, Felix Miata wrote:
How about "cloning" your F15, and upgrading that to F16 with latest
fixes
with Yum?
I made a filesystem in a new partition and copied to it as follows:
Booted to what? File copy can't be expected to work satisfactorily if source
is running.
Source wasn't running.
I'm still running F14.
F15 was installed primarily to establish that I could.
from /media as root:
cp -a sata400-3-slash/* sata-400-17
You have far more confidence in the competency of cp than I. Until last week,
I'd never cloned a partition except by one of two ways: 1-DFSee (sector by
sector); 2-MC, however it manages. Last time I tried MC I ran into trouble
that probably was little different from what you just did, so last week I
switched to doing file copies via rsync.
I was under the impression that rsync was just a convenient version of cp.
Is there something that rsync gets right that cp gets wrong?
I've read cp vs. rsync theads.
From those, rsync would have been much better if
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@xxxxxxxxxxxxxxxxxxxxx
"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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
