panic after rsync

[dsavage at peaknet.net]

On Sunday October 16, 2005 at 10:51pm "Matthew Saltzman"
<mjs at ces.clemson.edu> wrote:
> On Sun, 16 Oct 2005, Mike Pepe wrote:
>
>>
>>
>> dsavage at peaknet.net 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