[CentOS] SOLVED: hard disk move to another server

dan1

dan1 at edenpics.com
Mon Apr 9 18:21:40 UTC 2007


>You can at least try to prepare a new initrd (name it differently and
>create a different entry in grub.conf) with mkinitrd.
>mkinitrd has a nice feature called --with=module so you can try to
>mkinitrd --with=sata_via to include this module even if not 'already'
>specified in /etc/modprobe.conf (don't forget also to change this after
>the machine has correctly booted : 'alias scsi_hostadapter=')
>I've never tested such hdd migration but it should work ...

Hello, Fabian.

Sorry for the very late answer.
You are right, this did the trick. However, there was a thing to add to make 
it work, we need to mount the /proc filesystem on the destination root 
directory for the mkinitrd to work properly. Else, thank you very much for 
the help you provided!

The quick fix is to simply copy the /boot/initrd-xx.img file from a working 
installated drive on the destination server to the old drive partition, and 
it will work (you must update the grub entry of course).
However, if you don't have such a working hard drive, you will need to 
recompile this initrd file. Therefore I post the complete procedure below to 
move a hard disk drive with a working CentOS 4 system from one server to 
another one, not having the same SATA chips, or from a PATA to an SATA or 
vice/versa.
If you don't do this, then you might receive this kind of error:

Uncompressing Linux... Ok, booting the kernel.
Red Hat nash version 4.2.1.8 starting
mount: error 6 mounting ext3
mount: error 2 mounting none
switchroot: mount failed: 22
Kernel panic - not syncing: Attempted to kill init!


Here is my procedure for those who would need it:

1. To recreate the initrd file, we will do it by booting from a successful 
boot partition on the destination server, like the CentOS live CD for 
example,
or any other hard drive a hard drive which has been installed with the 
CentOS installer on the destination server.

We will mount the destination (failing) boot filesystem to /mnt/boot, and 
also its associated destination root filesystem, with these commands:
mkdir /mnt/boot
mkdir /mnt/root
mount /dev/sda1 /mnt/boot
mount /dev/sda3 /mnt/root

2. We must now change the root directory so that we can have access to the 
latest kernel sources which is always in /lib/modules. However, we must
first create the /proc filesystem on the chrooted partition, else the 
compilation won't work properly:
mount -t proc none /mnt/root/proc

3. Then, we can chroot to that partition like this:
chroot /mnt/root

4. We then rebuild an initrd file by typing the following:
mkinitrd --with=sata_via /initrd-new.img 2.6.9-42.0.10.EL

To know the proper kernel version to use (last number of the command line), 
you need to use an existing directory
listed in the /lib/modules directory. Normally you should take the last one.
the --with=sata_via is to force specifying the right hard  disk module to 
use, but it can normally be omitted. Else make sure that you specify the
proper driver for your motherboard SATA hardware chip.
We do not create the initrd file in the boot directory, because we can 
sometimes not access it at this time (especially with md partitions), but we 
will
simply copy the resulting file to the proper destination afterwards.
If you receive an error message saying 'unable to stat /dev/md2: 2', just 
forget about it, the resulting file should still be there.

5. Make sure that the /etc/modprobe.conf file contains the driver you have 
added to this line:
alias scsi_hostadapter sata_via

6. Now, let's come out of the chroot:
exit

7. Then, copy the resulting file to the proper destination:
cp /mnt/root/initrd-new.img /boot

8. Finally, we need to add the entry in the /boot/grub/grub.conf file, by 
keeping the last kernel file, but changing the initrd file to the new one.

9. Make sure that the following files have been properly changed accordingly 
to your new server setup:
/boot/grub/grub.conf
/boot/grub/device.map
/etc/fstab
/etc/modprobe.conf

All should be done now. You can reboot and try the result...


Thanks to all the others who also helped me with this problem.

Kind regards,
Daniel





More information about the CentOS mailing list