This is driving me nuts. I have 3 Dell M6400s configured with 2 160GB drives in a RAID0 configuration using the onboard raid controller. I have created dumps from one of the machines and want to use that to build out the other 2 machines. The operating system I am using is CentOS 5.3 64bit. I'm tantalizingly close to getting it working, but I'm sure what I am doing is extremely convoluted.

What I've had to do is:

1. Boot from disc 1 and go through the setup procedure to create the partitions and labels. Once it has done the format and creation of the partitions, I turn the computer off.

2. Reboot from disc 1 again using the linux rescue command and to restores from the dumps I have on an external usb drive.

3. Attempt to change the appropriate files that contain any reference to the old hard drive. In this case, the hard drive name on the original computer was /dev/mapper/isw_biabaibdhj_Volume0 and the new name is /dev/mapper/isw_bcjggdgejc_Volume0.

I got close by doing the following
1. chroot /mnt/sysimage
2. grub
3. device (hd0) /dev/mapper/isw_bcjggdgejc_Volume0
4. root (hd0,0)
5. setup (hd0) *output looks to be correct from this.
6. edit /mnt/sysimage/boot/grub.conf and change the drive name to
reflect the new name
7. edit /mnt/sysimage/boot/grub/device.map and change the drive name
to reflect the new name

4. Reboot system. It attempts to come up but then complains about not being to find the old drive name.

Debug:
Here is the error I am getting once the boot process starts after the "Red Hat nash version 5.1.19.6 starting" message

[Either the required RAID set not found or more options required. no raid sets with name
/dev/mapper/isw_biabaibdhj_Volume0
failed to stat() /dev/mapper/isw_biabaibdhj_Volume0
unable to access resume device (dev/mapper/isw_biabaibdhj_Volume0)
...
I rebooted into linux rescue and there is another file /etc/blkid/blkid.tab that has the old drive name which I deleted on one try which made things worse.

Just a bit after 12am here in Hawaii... tired and pissed I've spent this much time (couple days now) on something that should be very simple.

I'd really appreciate any ideas the smart guys here may have.

Mahalo,
Mike

An easier way to go about this:

1.) Use "dd" to capture a complete image of the machine you wish to duplicate, i.e., from a live CD "dd if=/dev/source_drive of=/dev/larger_temporary_media"
2.) Setup your hardware raid0 on the other two systems.
3.) Boot the systems you wish to image with a live CD.
4.) use "dd" to pull a bit-by-bit serial copy of your original image to the new systems, i.e., "dd if=/dev/larger_temporary_medai of=/dev/sda"
5.) profit!

You can also get tricky and do this on the wire via | to netcat. A good resource is below if you wish to go that route:
http://infosanity.blogspot.com/2009/...-recovery.html

Forrest, thanks for the reply. I'll definitely look into that.

However. That bit by bit copy won't fix the fact that there are files in the original backup that point to the original raid0 device: dev/mapper/isw_biabaibdhj_Volume0. I found 2, but when the machine boots back up, I get the following error:

[Either the required RAID set not found or more options required. no raid sets with name
/dev/mapper/isw_biabaibdhj_Volume0
failed to stat() /dev/mapper/isw_biabaibdhj_Volume0
unable to access resume device (dev/mapper/isw_biabaibdhj_Volume0)

That message is referring to the original raid0 device. Does anyone know what else I need to do to have the new install recognize the new raid0 device: /dev/mapper/isw_bcjggdgejc_Volume0 ?

Thanks again forrest.

Mike

ok, just to keep anyone who might be following this informed, I am now a step closer. Here is what I did:

boot the linux rescue cd and go to /mnt/sysimage/boot

mkdir /tmp/initrd
cd /tmp/initrd
gzip -cd /mnt/sysimage/boot/initrd-xxxxxxxxx.img | cpio -imd --quiet



then edit the init file at /tmp/initrd/init to change all entries referencing the the old drive, then pack it up again with:

cd /tmp/initrd
find . | cpio -co | gzip -9 > /boot/initrd-xxxxxxxxx.img

That has gotten me past that error and the machine boots up to where it is checking filesystems.

Now I have the following problem to deal with:

fsck.ext3: Unable to resolve 'LABEL=/opt'
fsck.ext3: Unable to resolve 'LABEL-/boot'

kernel alive [FAILED]

Chime in with any ideas while I continue to research.

I'll be able to duplicate this, but this is very very convoluted. Would be nice to streamline it, so if you see any steps that can be done more efficiently, please post.

Mahalo,
Mike

ok, have the label thing fixed:

e2label /dev/mapper/isw_bcjggdgejc_Volume0p1 /boot
e2label /dev/mapper/isw_bcjggdgejc_Volume0p3 /opt

Machine now boots all the way up, but there was an error about /boot already mounted that I need to track down.


So.... SMART GUYS. How can I streamline this? I should be able to do all of this with one script once I have booted into linux rescue as opposed to going through the install cd to get things set up.

Also, I don't think I should have to manually unzip the initrd image and make edits. I'll look into mkinitrd.

Mahalo,
Mike

LMFAO!!!

Mike, Mike, Mike... Dude, what are you doing? Please for the love of god, read the following and take heed. You're making this REALLY REALLY hard on yourself ;-)

First of all, the partition you keep referring to as a "raid0 device" is in fact a volume group with "logical volumes" hidden within (pretty much your whole Linux box is stuffed away in that neat little "/dev/mapper partition"). So again, just to be clear, this has absolutly nothing to do with the hardware raid0 on your machine (hardware raid is invisible to the operating system).

Let me explain a little more about Logical Volumes, Volume Groups, and Logical Volume Managment (LVM2). A Volume Group is a virtual container which aggregates "Physical Volumes" (hard disks or LUN'S) for use with the Linux LVM2 disk virtualization toolkit. LVM2 is very cool as it allows for the dynamic growing and shrinkage of partitions, the dynamic addition of hard disks that can be added to the "Volume Group", so as to create a larger pool of disk space with wich to grow your filesystems, and do all sorts of other usefull things... This should begin to make sense if you look closely at what you've been seeing as you've been struggling with this. Remeber /dev/mapper/*volume0/opt from you previous post? The "/dev/mapper/*volume0/opt you were seeing is a logical volume within the "/dev/mapper/*volume0" volume group.

It pretty much breaks down like this; a hard disk or LUN is used to create a "physical volume". In our case, you're hardware raid0 is the SINGLE logical disk that's housing the volume group (again hardware raid is transparent to the operating system). Once a "physical volume" is created, one or more "physical volumes" are aggregated to make a "volume group". Here it is "/dev/mapper/isw_biabaibdhj_Volume0". Within "/dev/mapper/isw_biabaibdhj_Volume0", you have your "opt" filesystem, which is in fact a "logical volume" called "/dev/mapper/isw_biabaibdhj_Volume0/opt"

So, getting to the point. You are wen't waaayyyy off course when you began mistaking the "/dev/mapper/isw_biabaibdhj_Volume0" partition as being part of your underlying hardware raid0. Believe it or not, you were totally screwing the whole process up in trying to address/fix an imaginary problem with an imaginary duplicate/broken raid (again that doesn't exist). In fact, you underlying raid0 is perfectly healthy, otherwise you wouldn't be able wo read any data, or use the disk at all. Remember, Raid0 is a striped configuration, and if you loose so much as a single stripe from either of the disks in the RAID set, it's GAME OVER. So don't worrry about the underlying raid.

That said, Let's get on with it and finish this job.

As long as you've already set up the raid0 on both systems, this should be cake. In fact, you'll laugh you ass off when you realize how frigging easy what you're trying to do is. The steps are identical to the directions I gave you last night.

Step 1.) Boot from a live CD, and perform a bit-by-bit copy from the original hard disk via "dd". Grab the whole disk, not the individual partitions, i.e., "/dev/sda" NOT "/dev/sda1", etc... It should look something like below (you don't even have to specify the block size as that's already a part of the origianl image, and we're making an exact bit-by-bit copy.

dd if=/dev/sda of=/dev/sdb


Step 2.) Repeat the process on the machine you wish to image by reversing the process, i.e., "dd" the image from your usb disk to the hardware RAID0 on your other two machines.

dd if=/dev/sdb of=/dev/sda



Step 3.) Reboot. That's it, DONE!




After your done copying, you should have a perfectly functioning set of three identical systems. There may be a very far-off chance that you'd have to reconfigure grub, but that's a FAR-OFF CHANCE, and I'm willing to bet money that won't be necessary. I have to do this as a regular part of my job, and it's really as easy as I'm making it out to be. If by chance the systems won't boot after the steps I gave you above, I'll walk you through the grub setup.

As for all that other stuff you're doing (changing drive names, labeling disks, etc...) It's all completly unnecessary, and a complete waste of time and energy. You're only serving to confuse yourself further if you look at anything you've done the past two nights outside of the steps I gave you, and the lesson on RAID and LVM.

Seriously, You weren't kidding with our original post. That's about as convoluted as I've ever seen!


I hope this "stream lines" it for you....

Forrest, I finally understand where you are coming from. Here's my problem and why I'm screwed. I deleted all those LVMs on initial install. I read about them and figured I didn't need them, so why not have a setup that I always had :-) That's why all the RAID ids are located in all those files I mentioned. So, regardless on whether or not I do a dd, those files will still have RAID specific ids in them.. not generic LVM names.

I'll get it unscrewed (rebuild or whatever), then perform the dd. Let you know how it goes.

Thanks for taking the time to read all that and provide the explanations Forrest.

ok Forrest, here is my dilemma.

I can't do a dd from /dev/sda /dev/sdb because there is no /dev/sdb. What I mean is both slots in the m6400 are taken up by the RAID0 configuration.

I have an external usb on which I have a EXT3 partition (The first partition is NTFS with some needed files). These are where I was storing my dumps. I'm getting a "file size limit exceeded" on the dd command when I try and dump it to a file which I'm currently trying to find out how to get around. (My dumps were previously compressed dumps and tar on separate partitions, which managed to get around the space problem.. ulimit on the partition shows unlimited)

I'm also going to attempt to do a very basic install on a new machine with the LVMs in place then restore using my dumps and change any files having the old raid id's as names. (I suppose I could just do a whole new rebuild, but this shouldn't take that long)

Assuming that works, I'm going to reformat that whole external USB drive I mentioned above (Moving files from the ntfs partition as I write) as one full ext3 partion then do a dd from /dev/sda to /dev/sdb.

Does that sound reasonable?

Thanks again.
Mike

Ok, help me out here, because I am totally confused. I just did a new/basic install on one of the machines. I went in and unpacked the /boot/initrd-2.6.18-128.el5.img file so I could look at the initrd file. Here are some lines in that file that concern me:

echo "Scanning and configuring dmraid supported devices"
dmraid -ay -i -p "isw_bcjggdgejc_Volume0
kpartx -s -p p "/dev/mapper/isw_bcjggdgejc_Volume0
...
...

So, once I back this up to a new machine, this won't work because those to "dmraid" and "kpartx" lines above will have the wrong name.
yes???

Finally got it.

I had actually tried to do a dd a few days days back, but the file was too big. That is what prompted me to go the route I did with the separate and compressed backup of / and /opt. Since I was now out of options, I had to address that issue.

Here's what I had to do.

1. Create a dd image backup of the entire drive onto my external 750GB USB. The problem was that the ext3 partition was created with a block size of 1024, so the maximum filesize was limited to 16GB. I had to recreate it with a blocksize of 2048 which will give me a maximum filesize of 256 GB.

2. Booted into my linux rescue and restored the dd image to /dev/sdb (/dev/sda was assigned to my external USB drive). Wait 2 to 3 hours (guessing here... I had waited an hour and a half, before leaving last night).

3. Unlike what Forrest says, it was not done at this point. Not sure if he had a hardware raid configuration or just a single drive. For me, I had to edit my /boot/initrd-xxxxxxxxx.img and change all the references to the original drive id (isw_biabaibdhj_Volume0) to (isw_bcjggdgejc_Volume0) by doing the following. I also changed the /boot/grub/devices.map entry as well.

mkdir /tmp/initrd
cd /tmp/initrd
gzip -cd /mnt/sysimage/boot/initrd-xxxxxxxxx.img | cpio -imd --quiet

then edit the init file at /tmp/initrd/init to change all entries referencing the the old drive, then pack it up again with:

cd /tmp/initrd
find . | cpio -co | gzip -9 > /mnt/sysimage/initrd-xxxxxxxxx.img

THEN... It's Done :-) Booted right up with no issues.

Still a few other things to do, like reset the networking and tweak my VMWARE install which had Oracle running. But that is all working now.

OK, so my feeling is that this is an acceptable way to backup and restore my hard drive. However, It could go a lot faster if this process was scripted to where you could create all partitions and setup the MBR, etc. Then install everything from dumps or tars. Doesn't really matter when speed isn't important, but these laptops will be used in an environment where if one failed, we would be ok, but you would want it back up fairly quickly. That'll be something I'll work on when I have more time, but for now, this works, so I'm happy.

Thanks for your help Forrest, it was helpful.

Mike

Sorry, shoulda mentioned that the default block size for ext3 is 4096, so you probable woulda wanted to tack on "bs=4096" to the dd command, otherwise, glad you got it figured out... Please thank, or "solve" would be even better