Cloning workstation to slightly different hardware
 

Hello all. The goal is to clone an existing workstation to another piece of hardware for the purpose of testing updates, patches and vulnerability fixes so that the original piece of hardware doesn't break application functionality. The workstation to be cloned is a Dell T7500 with two hard drives. The partition is setup as follows:
/dev/sda1 /boot
/dev/mapper/vg_vol00-lv_root /
/dev/mapper/vg_vol00-lv_home /home
/dev/sdb1 /root/backup

/dev/sda is a 500GB hard drive
/dev/sdb is a 1TB hard drive

The version of Red Hat is 64-bit Red Hat Enterprise Linux Workstation Release 6.0 (Santiago)

What I've done thus far.

I rebooted into Knoppix on this machine and attached a 1TB external hard drive (via USB) and ran the following command:
dd if=/dev/sda of=/dev/sdc bs=100MB conv=notrunc,noerror

I then plugged up a second hard drive upon completion of the first step and ran the following command:
dd if=/dev/sda of=/dev/sdc bs=4096 conv=notrunc,noerror

After both hard drives completed the dd operation (each of them errored saying no space left on device, but, as I understand it, this isn't something to be concerned about per se), I placed the cloned drives into a Dell T7600 workstation which has newer hardware. When I booted it up, I see the Red Hat progress meter at the bottom of the screen, and, as the progress meter got to about half way across the bottom of the screen, I get the following message:
"No root device found.
Boot has failed, sleeping forever"

So, some things to point out here:
* Newer hardware
* bs was different than the first dd command, but I didn't think that mattered. I was just messing with bs to see if I could get it to go faster

Would it be possible to boot from a Red Hat disk into linux rescue and somehow inject parameters to allow the machine to boot? I can see the data after having mounted to /mnt/sysimage via Knoppix, but obviously something isn't liked by the new hardware.

Additionally, I've gone through the BIOS settings to match parameters as identical as I could from the original hardware.

Is what I'm attempting futile? If I have to completely give up on cloning, is there an easy way to get a machine to act exactly like another one? I've been looking at Clonezilla and FOG, but I'm thinking they won't cater to my specific needs here.

Any/all ideas would be greatly appreciated.

The second command is supposed to refer to /dev/sdb, right?
That is very much something to be concerned about, because it means dd ran out of space on the destination device. Your drive images are incomplete.

AFAIK, Red Hat boots using an inird, and my guess is your current initrd doesn't contain the necessary modules (drivers) for your new disk controller. That, or vital parts of the file system is missing due to the truncated image.

You should rebuild the initrd on the old system (if at all possible), adding the relevant module(s). The alternative is to manually edit the existing initrd or add a new initrd using Knoppix a similar Live CD, or perhaps see if the Red Hat installer has a "rescue" or "repair" function (disclaimer: I know nothing about RHEL).

You should be able to see which modules are needed from within Knoppix. lspci (on the new system, obviously) would be a good start.

You're right, of course. The second should've been /dev/sdb. Thanks for catching that.

So, if the hard drives in the system to be cloned are 1TB and the external hard drives that are to go in the new system to act as the test box with identical configuration from the first are ALSO 1TB HDD's, what am I missing here? A flag/switch in the dd command or something? Is there a better way to copy the data over bit for bit?

The initrd option is an entirely new concept to me and I really don't think I'll be able to rebuild on the original machine because of how mission critical it is. Perhaps I just need to focus on obtaining an accurate clone of the hard drives and go from there?

By the way, I get the same exact error message (upon dd's completion) for both hard drive clones.

cloning a linux install doesn't necessarily require DD, simply partitioning, formatting, copying the files and setting up the new system using a live cd
make sure the new drive is in the position it's going to be, and the old data is available either via attaching the drive in a secondary position or via a network share (preferably the former)

boot to a live cd
replacing sda1 with the volume of your new system and sdb1 with the volume of your old system
at this point the terminal would be as if you had booted the system on /newsys
re-build the initramfs and install grub (or whatever bootloader you use) on the new drive
assuming everything went ok you should be able to shut down, remove the old drive, and have a bootable system on the new drive next time you poweron the machine

note, sub partitions would be mounted AFTER the initial partitions

The initrd is just a file containing a small file system to serve temporarily as root during the boot process. It makes it possible to keep the kernel small and lean; you just add the necessary modules to the initrd to make the kernel detect your disk controller or whatever device connects to the root file system. If one doesn't use an initrd, the required disk controller driver must be compiled into the kernel.

Rebuilding an initrd isn't a big deal at all. Usually, every distribution has a script to do the job for you, and anyway you don't have to delete or replace the existing initrd, just create a new one and add a new boot option to GRUB.

Check the size of both drives with fdisk -l. If the number of sectors on the destination drive is smaller than that of the source drive, a straight dd clone won't work. frieza's method would work, though.

If the destination drives are the same size or bigger, the issue is probably your choice of block size for dd. In that case, the error message is indeed purely cosmetic (and your boot problems are guaranteed to be driver/module related).

I've found block sizes larger than 8192 to have very little effect on performance, and since most drives have a sector number divisible by 16 (for older drives with 512 byte sectors) or 2 (newer drives with 4096 byte sectors), you won't get an error message as dd tries to write past the end of the device.

Thanks so much for all the words of wisdom. Is extremely appreciated. I'll try first thing in the morning.

It ended up that this wouldn't work because there was a bit or two less seen by the clone tool (Clonezilla) which was causing it to fail. Although I haven't tried it, the suggested fix was to use a tool such as gparted and resize the origin disk to slighly smaller size so that the clone operation would move on.