On Sunday October 16, 2005 at 10:51pm "Matthew Saltzman" <mjs@xxxxxxxxxxxxxxx> wrote: > On Sun, 16 Oct 2005, Mike Pepe wrote: > >> >> >> dsavage@xxxxxxxxxxx wrote: >>> The 48G hard drive in my Thinkpad is throwing smartd errors, so I'm >>> trying >>> to migrate my existing FC4 installation to one of those new 120G >>> Seagate >>> Momentus drives. The difference between their sizes is giving me fits. >>> I >>> tried prepping the new drive with LVM2 before running rsync, but I >>> couldn't mount its partitions with a temp USB2 connect because FC4 >>> apparently can't handle two drives using identical lvm names. > > Not surprising, if you think about it. So give the new volgroup a > different name for now. Then you can change it back after you remove the > old drive. > > I just went through this, and it worked fine for me. The LVM HOWTO is > extremely helpful in this regard. > >>> >>> Since all I need are the /boot, / and swap partitions I gave up on lvm >>> and >>> tried the old fashioned way: /dev/hda1-3. The trouble is, when I rsync >>> everything over from the old to the new drive, some lvm contamination >>> seems to migrate along with my files. > > I doubt it's LVM "migrating". rsync knows nothing of LVMs. > >>> >>> While booted with the Rescue CD I've: >>> (1) Re-labeled the / and /boot partitions >>> (2) Edited /etc/fstab to match the new disk's LABLELs >>> (3) Run mkinitrd with "--omit-lvm-modules" >>> (4) Re-run grub-install >>> >>> Now the new disk boots thru grub, then panics after: >>> Red Hat nash version 4.2.15 starting >>> ERROR opening /dev/console!!!!: 2 >>> error dup2'ing fd of 0 to 0 >>> error dup2'ing fd of 0 to 1 >>> error dup2'ing fd of 0 to 2 >>> WARNING: can't access (null) >>> exec of init ((nul)) failed!!!: 14 >>> Kernel panic - not syncing: Attempted to kill init! >>> >>> Can anyone offer any insights into what is causing this and what needs >>> fixing? Thanks. >>> >>> --Doc Savage >>> Fairview Heights, IL >>> > > Mike Pepe could be right. If you didn't leave out the pseudo-file systems > (dev, proc, selinux (I think), sys, when you copied, you might see odd > behavior. > > Also, check to see that you preserved symlinks when you copied. > /etc/grub.conf, e.g., should be a symlink to /boot/grub/grub.conf. > >> >> I'm not sure this is the root cause of your issue, but if I were doing >> what >> you are doing, I'd be using dump/restore or tar, not rsync. >> >> Maybe it's not copying your data correctly... dump and restore would >> probably >> be my first choice, as they read and restore on the filesystem level >> where >> the other solutions can cross mountpoints. >> >> just a thought... > > There are other ways to avoid crossing filesystem boundaries. The LVM > HOWTO suggests using find (which can be told not to cross filesystems) and > cpio. That worked fine for me. Mike, >From the old drive root (/) to the new drive root mounted at /media/usbdisk, my rsync command line was: # rsync -avxvtzHP ./ /media/usbdisk The "z" parameter is supposed to confine source files to the current filesystem and ignore any that are mounted. These would include /proc, /sys, and so on. Strictly speaking, /dev isn't a mounted filesystem but I suppose it's possible that some of its entries might not be precisely the same on a LVM disk as a plain partitions disk. Is there a preferred way to regenerate the /dev directory from scratch using MAKEDEV when booted to the Rescue CD? --Doc Savage Fairview Heights, IL
