I'm having a hard time trying to wrap my head around a problem that I'm having here. I have 20 laptops that are all the same make/model and hardware configuration. I'm not cloning these drives but I'm building them all up on one particular laptop and taking the drives to the field computers. My problem is that when I build up at machine on one laptop and put the drive into another, it can't find the VolGroup00. But if I put it back in the original machine it comes up just fine.

Could something that I don't know about in the hardware configuration (like different memory manufactures) cause a drive to not boot up? I've even tried cloning the drives with Ghost and dd and I still get the same issue. Someone please point me in the right direction. Thanks!

The LVM control files in /etc/lvm contain the UUID information of each physical volume in every volume group. You need to make sure that the drive's UUID is not reset when the drive is swapped, and/or that it matches the information in the various files in /etc/lvm and it's sub-directories.

Ok, that makes sense PTrenholme. Thank you! I wonder what could be happening to cause my hostid to change. Is that created from a MAC address or something? This is going to make it hard to come up with an field replaceable unit for remote sites not having the ability to just throw in another drive by someone no technical.

Ok, doesn't seem to be an LVM problem. I just build up a disk without LVM and it did the same thing. There has got to be a way to clone a disk that you don't have to worry about something like this happening.

You don't mean it can't find the VolGroup00" or do you?! What was the actual error? Is there only one HDD in each system? What does /etc/fstab look like?

Well, in my original post it couldn't find the VolGroup00, but now I've rebuild the machine without LVM and when I move the drive to another machine it crashes at the same spot. Below is the error I'm seeing:

When I put the drive back into the machine I installed it on, it comes up just fine. I don't see anything strange in the fstab file. I'll get that booted up and post that as well.

I know this might seem like useful information that I should have put in the beginning, but these computers are dual boot WindowsXP/RHEL5 systems.

bump

fstab?

And fdisk -l output and a few lines that come before "Mount: could not find filesystem '/dev/root'"

Ah! Some distributions hard-code file/disk access information in the initial RAM file system. You may need to edit the boot script in the initrd.img to get things to work. You might want to look at the mkinitrd command to see if you can create a "generic" initrd image file or investigate the kickstart stuff to creating portable installations, although that's usually used for making installation DVDs.

These messages suggest that the initrd.img file in /boot may not always cause the correct things to happen. Remember, that during boot the devices (aka, /dev/* ) are now dynamically discovered and created. It seems to me that you may have too much of physical-laptop-A identity in your kit so that /dev does not get built correctly on physical-laptop-B.

The boot sequence will load GRUB as it shakes and stirs the physical drive master boot record (MBR). Typically, the GRUB configuration details appear in /boot/grub -- specifically the menu.lst file where drives and partitions use a notation like 'hd(0,1)' to refer to drives and partitions for each bootable configuration. /boot will provide the typically compressed kernel and the initial ram disk (initrd.img) for an in-memory getting started root file system. When the kernel is finally loaded, it creates the ram-disk, loads it, and starts things running over there. Once there enough parts are running, the physical root file system ... and all the other file systems ... get mounted and full-blown system initialization is under way. Your messages tell me that something is wrong where your duplicated drive meets the alternate hardware.

ALTERNATIVE: With everything dynamic these days, drive mounting uses file system UUID instead of device names. Doing that lets us use the file system for the same functions in spite of the device name it gets when all of the dynamic parts stop moving. Perhaps your boot-time configuration relies on a name that is changing from one laptop to the next instead of a specific filesystem regardless of its device name.

Please (1) report back on your progress, and (2) indicate when and if you have a solution. I suspect others may have the same issues when they move to a larger drive in the same laptop.

~~~ 0;-Dan