So I'm trying to migrate a Centos install using LVM to some new hardware. I can't just move the disk because the old hardware is using /dev/hda and the new is /dev/sda.

I've been down this road before years ago but forget the solution. I am using LVM labels, so there is nothing useful in grub.conf or fstab to simply change.

I can access everything from the old hardware before moving the disk over..



--- Physical volume ---
PV Name /dev/hda2
VG Name VolGroup01
PV Size 1.77 GB / not usable 25.16 MB
Allocatable yes (but full)
PE Size (KByte) 32768
Total PE 56
Free PE 0
Allocated PE 56
PV UUID OZaZh5-DZ19-W2AA-5a3G-lijO-mmip-Lz1hm2

--- Physical volume ---
PV Name /dev/hda3
VG Name VolGroup01
PV Size 1.61 GB / not usable 21.00 MB
Allocatable yes (but full)
PE Size (KByte) 32768
Total PE 51
Free PE 0
Allocated PE 51
PV UUID 9fXQDX-3Zod-mZHX-5AYv-05bE-Je6G-thzjY9[root@redirector etc]# pvs
PV VG Fmt Attr PSize PFree
/dev/hda2 VolGroup01 lvm2 a- 1.75G 0
/dev/hda3 VolGroup01 lvm2 a- 1.59G 0

[root@redirector etc]# vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup01 2 1 0 wz--n- 3.34G 0

[root@redirector etc]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
LogVol00 VolGroup01 -wi-ao 3.34G

You might need to delete /etc/lvm/cache/.cache to force a rescan of the devices. The default filter rule in /etc/lvm/lvm.conf accepts every block device, so you shouldn't need to do anything there unless you've changed that filter rule.

I got my hopes up it would be that simple, but no dice. Judging by this, it did rescan since I rm'ed .cache...


Scanning logical volumes
Reading all physical volumes. This may take a while...
No volume groups found
Activating logical volumes
Volume group "VolGroup01" not found
Creating root device.
Mounting root filesystem.
mount: could not find filesystem '/dev/root'

Not sure exactly what you are trying to accomplish.

What is the version of the old install? The latest kernels use the SCSI subsystem for everything so all drives are sdx even IDE (PATA). If you configure the BIOS for SATA legacy support (PATA emulation) the old kernel should assign the drives as hdx.

However, if there isn't legacy software you are trying to maintain then you should really think about installing the current version of CentOS (6.5). As always, make sure you have good backups.

I run a couple embedded systems that run off a CF card here, had a piece of hardware fail and replaced it with slightly newer hardware.

Even with my rescue media, the old hardware detects the CF card as hdx, and the new hardware as sdx. As I've been digging a little deeper it seems I may need to remake a new initrd with scsi/ata modules built in..

Here's what I was looking at:
http://www.pantz.org/software/mkinit...amkinitrd.html

Attempting it now

Looks like you are on the right path.

So I feel like I took a step backwards on that ones. I made a new initrd like the above link discussed, using the same module options. Added a grub entry for it and rm'ed /etc/lvm/cache/.cache again and tried it..

Here's a few lines from the bootup that caught my eye. Did I miss some sort of option with mkinitrd perhaps?


checking if image is initramfs...it isn't (invalid compressed format (err=2)); looks like an initrd


RAMDISK: Compressed image found at block 0
invalid compressed format (err=2)
VFS: Cannot open root device "VolGroup01/LogVol00" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Hi there,

I'm sorry this post of mine isn't helpful - but I'll hang in here because there's a detail that makes me wonder.
It's about the naming convention of HDDs.

Actually, I know that HDDs used to be named /dev/hdX in the past, but all systems I used myself had them as /dev/sdX. Some years ago, a friend of mine told me that this changed from kernel 2.4 to 2.6 - in other words: Kernels up to 2.4 named the HDDs as hdX, while later kernels named them sdX.

I don't know if this explanation is accurate, but if it is, it would mean that you're migrating from a pretty old system.

Could somebody shed some light on this particular issue?
Thanks for any clarification to come.

[X] Doc CPU

What version of CentOS is this?

At this stage of booting, /etc/lvm/cache/.cache in the not-yet-mounted root filesystem is irrelevant. (Sorry, but in your original post it wasn't apparent that this was a boot failure looking for the root filesystem.)

Doc CPU, This install is using a 2.6 kernel. I'm still feeling like this had to do with what hardware was present when we did the original install. IDE vs SATA devices, etc.

rknichols, It's running Centos 5

Libata was merged around 2.6.15 - and that may explain why the posted link didn't solve the issue (completely).
In that link, the kernel is 2.6.18 - so that (initial) initrd was built using /dev/sda - hence the inclusion of the module(s) solved the issue.
I think the OP may have to unroll the initrd and look to see if /dev/hda is used explicitly - and modify to suit. Link here will give an idea of what's required to do that.

Makes sense..

I just unrolled both initrds. The "stock" one and the one that I made with extra modules. The "stock" one is indeed missing the libata and scsi stuff.

I grepped the contents of them both and can't find any matches to hda.


I'm going to try a fresh install on the new hardware and start fresh, but I'd still like to figure this out for my own piece of mind. I always seem to have issues when it comes to LVM.

Okay, so update. I'm thinking the naming convention of hda and sda isn't my problem.

I built a fresh Centos 5.1 image in vmware, copied the image over to my embedded device and back to the same no-boot situation. Hangs soon as it tries to mount / but cannot find it. Seems like the kernel doesn't have the module needed to access the storage device.

Perhaps if I could install directly to the embedded device all modules needed would get installed. But is it possible to do a full install without a monitor? (All I have is a console port).

If anyone is curious, this is the hardware:
http://www.pcengines.ch/apu1c4.htm

I realize at this point I better start a new thread in the proper forum.