Good Things To Know When Imaging Linux To Different Hardware

* Note: This should work with OpenSUSE 10.1 and later

Yesterday was the first time I came across a situation where I wanted to image an older relay server from a small desktop to a VMWare ESX server. Making and restoring the image was no problem but after restoring and editing the fstab, mtab and menu.1st I thought I was on a roll until at boot up I was getting the message ' waiting for /dev/sda3 to appear ...'.
Until now I had apparently been lucky enough to have a similar chipsets when imaging to other systems, and for those that might hit the same issue, here's my two cents for ya...

After some searching I gathered the configuration files where fine but I was missing the driver for VMWare's LSI scsi device, thus the drive was there but could not be accessed.
After more searching I found some good info on what needed modifying; the initrd file. This site was a great help : http://www.communecation.net/pages/rescueramdisk.html

Plainly said the initrd is one of the first things to get loaded , before anything else is mounted, and has your basic drivers and file system support and gets things started.

I'm also thinking this could also be a way to include the needed drivers to deploy one image to multiple systems with different hardware - a little in the lines of sysprep. So any usefull comments and suggestions are very welcome!

~

To cut to the case, what we need:
The installation CD with the same version installed on the imaged system (in this case the OpenSUSE 10.2 cd or DVD)
If you don't have this, you can try with another CD that has a similar kernel version.

Files to keep in mind:
/boot/initrd (symbolic link) & /boot/initrd-<kernel version>-default
/boot/grub/menu.1st
/boot/grub/device.map
/boot/grub
/etc/fstab
/etc/mtab
/etc/sysconfig/kernel

---Preperation

Make an image of the original system (in my case it was using ide disks)
Restore your image to the new disk/system (in my case VMWare esx which offers a lsi scsi device), I would recommend keeping the same partition layout as on the original system, but it's not a must if you know how to handle that.

Now that you have your image on the new machine its time to boot with the OpenSUSE install CD using the rescue mode

---Making your new initrd

1) Boot with rescue mode of the install CD and log in with root rights

2) at the command line use ' fdisk -l' to determain your partition layout
in my situation there are 3 partitions , sda1=/boot sda2=swap sda3=/

3) Now mount the partitions

mount /dev/sda3 /mnt (this is my root / mount point)
mount /dev/sda1 /mnt/boot (this is my boot mount, and not needed if you root partition is also the boot partition)

(the next mount points are recommended to include)
mount -t proc none /mnt/proc
mount -t sysfd none /mnt/sys

4) Change the apparent disk root directory for the current running process to /mnt, so /mnt is now the /
chroot /mnt

5) Edit the files fstab, mtab, menu.1st & device.map to reflect the correct mount points and boot partitions.

6) Include the nessesary drivers in /etc/sysconfig/kernel
to do this edit the section ' INITRD_MODULES="..." '

In my case I added mptspi to add support for VMWare lsi scsi > INITRD_MODULES="processor thermal ata_piix fan reiserfs edd mptspi"

7) Now change to the boot directory, do this before running mkinitrd
cd /boot

8) Rename the current initrd file for safekeeping
mv initrd-<kernelversion> initrd-<kernelversion>.old

9) Run the make process to create your new initrd

mkinitrd -d /dev/sda3 (sda3 points to /)

extra modules can also be added with the -m switch (e.g: mkinitrd -d /dev/sda3 -m mptspi )
more help on options : mkinitrd -h

10) Make sure the name of the created initrd is the same as stated in the menu.1st or that the initrd link points to the new initrd file.


You can now reboot the system and if all went as planned the system now boots up and you can modify other needed components like networking and so on.


Hope you find it useful..

Cheers,

Wj

Added as can be found here : http://www.suseforums.net/index.php?s=&amp...st&p=231607

For those using LVM...

Just a post-mortem, with a little info for anyone searching on this issue in the future.

I was successful after rebuilding an initrd using the procedure mentioned by WJM. However, I had to add a couple of steps ... procedure I followed was:

• Boot from 10.1 install CD #1 (as it turns out, for this procedure, disk #1 was all that was needed, 2 - 5 weren't used)
• Choose System Rescue to get to a prompt, login as root
• Executed "/sbin/vgscan", then "/sbin/vgchange -ay" to make my LVM volume/logical groups available
• Mounted my LVM-managed root dir via "mount /dev/mastervol/Suse10.1 /mnt"
• Changed to that new root via "chroot /mnt"

So far, pretty much as detailed in WJM's reference -- but after unsuccessfully trying new initrd's, I had to add the next 4 steps (which I found referenced in a Novell technote):

• "exit" to get out of the chrooted environment
• mount -t proc none /mnt/proc
• mount -o bind /dev /mnt/dev
• chroot /mnt

This, all to restore the target environment (/dev, /proc) -- so something subtle in that target environment was affecting the initrd.

Then I proceeded to mount everything expected in the environment I was restoring via "mount -a", saved a copy of the old initrd via "cp /boot/initrd /boot/initrd.pre-messing-around.save", and made the new initrd "mkinitrd".

Then, on rebooting, everything was golden. I never did figure out what module difference was in play -- both old and new boot were using ide-generic, so I don't think it was anything as basic as disk drivers. But I'm not going to argue with results.

Thanks for the help, guys. And ... Linux rocks -- doubt this would have been anywhere as smooth with Windows.
[/b]

Many thanks for this good information.
I changed the harddisk in my older notebook (backup and restore with image for linux) and i must only make some of these steps. See below.

Everythink works fine. :lol:

Best regards
Ralf

1) Boot with rescue mode of the install CD and log in with root rights

2) at the command line use ' fdisk -l' to determain your partition layout
in my situation there are 3 partitions , sda1=/boot sda2=swap sda3=/

3) Now mount the partitions

mount /dev/sda3 /mnt (this is my root / mount point)
mount /dev/sda1 /mnt/boot (this is my boot mount, and not needed if you root partition is also the boot partition)

(the next mount points are recommended to include)
mount -t proc none /mnt/proc

4) Change the apparent disk root directory for the current running process to /mnt, so /mnt is now the /
chroot /mnt

5) Edit the files fstab, mtab, menu.1st & device.map to reflect the correct mount points and boot partitions.

You can now reboot the system and if all went as planned the system now boots up and you can modify other needed components like networking and so on.
[/b]