Cannot read LVM Partition from SATA Drive
 

Okay, so here's what appears to be a strange problem.

I am running CentOS 5.3 on a server in my room. It has a 40GB hard drive, which is located at /dev/hda.

I was previously running CenOS 5.2 on a desktop with a 750GB Sata drive.

I installed the 750 GB SATA drive into the server, and I need to pull the data off of the one of the files in the root filesystem. CentOS does not recognize the LVM partition on the SATA drive. I found a tutorial on how to mount LVM partitions using the Logical Volume number, however when I try to do that, CentOS gets upset because there are two devices with VolGroup00 (hda2 and sda2).

Also, I can mount sda1, as it is formatted in ext2 or ext3 (not sure which). Unfortunately it only contains kernel files and other stuff I don't need.

How do you recommend getting the data out of the root file system on my 750GB SATA drive so that I can re-format it as a storage drive with FAT.

Kernel: 2.6.18-164.el5


/sbin/lspci:

00:00.0 Host bridge: Intel Corporation E7500 Memory Controller Hub (rev 02)
00:00.1 Class ff00: Intel Corporation E7500/E7501 Host RASUM Controller (rev 02)
00:02.0 PCI bridge: Intel Corporation E7500/E7501 Hub Interface B PCI-to-PCI Bri dge (rev 02)
00:03.0 PCI bridge: Intel Corporation E7500/E7501 Hub Interface C PCI-to-PCI Bri dge (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB Controller #3 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corporation 82801CA LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801CA Ultra ATA Storage Controller (r ev 02)
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02)
01:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 03)
01:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 03)
01:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 03)
01:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 03)
03:01.0 SATA controller: Initio Corporation INI-1623 PCI SATA-II Controller (rev 02)
04:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 03)
04:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 03)
04:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 03)
04:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 03)
07:01.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
07:02.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (r ev 0d)
07:03.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (r ev 0d)

A LVM volume group may be spread across many LVM physical volumes (PVs) such as partitions like hda2 and sda2. Were both those partitions-and-PVs assigned to the same VolGroup00 or have you made them strange bedfellows by installing PVs on one system that came from different VGs that happen to have the same name?

I'm not exactly sure what you are asking. I believe both hda2 and sda2 are assigned to the same VolGroup00.


The output of pvs tells me this:

WARNING: Duplicate VG name VolGroup00: Existing G8e6MT-jV4W-7Eh7-12Q9-bgpp-b1Jg-7KpXSI (created here) takes precedence over DLdrOS-IcP0-D3PS-6Ute-iQ1e-rfPF-63JouQ
WARNING: Duplicate VG name VolGroup00: Existing G8e6MT-jV4W-7Eh7-12Q9-bgpp-b1Jg-7KpXSI (created here) takes precedence over DLdrOS-IcP0-D3PS-6Ute-iQ1e-rfPF-63JouQ
WARNING: Duplicate VG name VolGroup00: Existing DLdrOS-IcP0-D3PS-6Ute-iQ1e-rfPF-63JouQ (created here) takes precedence over G8e6MT-jV4W-7Eh7-12Q9-bgpp-b1Jg-7KpXSI
WARNING: Duplicate VG name VolGroup00: Existing G8e6MT-jV4W-7Eh7-12Q9-bgpp-b1Jg-7KpXSI (created here) takes precedence over DLdrOS-IcP0-D3PS-6Ute-iQ1e-rfPF-63JouQ
PV VG Fmt Attr PSize PFree
/dev/hda2 VolGroup00 lvm2 a- 37.16G 0
/dev/sda2 VolGroup00 lvm2 a- 698.53G 0

I meant have you taken a HDD with an LVM partition assigned to VolGroup00 out of a computer and put it in another computer that already had a VolGroup00?

Aha, yes, yes I have. Was that a bad idea? And is there any way to fix that, or a better way to get the data off of that drive?

You will have to rename the volume group. You can find lots of info on the web but this link appears to be a decent step by step method.

http://www.whoopis.com/howtos/linux_lvm_recovery.html

Thanks so much for your help.

Well, it's an unusual thing to do so there isn't going to be much experience on the Internet about how to deal with it. I guess that makes it a bad idea!

The vgrename man page says you can rename a VG giving the original ID by UUID and the new VG by name.

Caution, caution, possible data loss ... vgrename should (TM) be OK if the "foreign" HDD's LVM partition is a complete VG, that is if there weren't any other partitions in VolGroup00 on the computer it came from. It would be prudent to have some proven backups before trying it!

I guess coming from Windows world, it's not that unusual of a thing to do. I have done this many times with ntfs and fat32 formatted drives, and it's very easy to do. I didn't really realize that linux would have such a problem with it. I guess that's just part of the learning experience....

NTFS and FAT32 are file systems so comparable to Linux's file systems such as ext2, reiserfs, xfs etc. A HDD containing partition(s) containing Linux file systems can be moved to another Linux computer and those file systems can be accessed. This is equivalent to your Windows experience.

LVM is different; it is a way of constructing partitions (LVM logical volumes, LVs) from HDD blocks taken from one or more pools of HDD blocks (LVM physical volumes, PVs, typically HDD partitions). AFAIK Windows does not have anything equivalent.

Windows implementation is called Logical Disk Manager (LDM) which uses dynamic disks.

So I just decided to put the drive back in the other box and pull the data to a USB drive. Took me freaking forever, but now I have my data. I will keep in mind the whole LVM thing next time I need to do this. When did linux distros start using the LVM by default, and what are the advantages to using it?

Thanks :) Just curious ... do you know if you pulled an HDD including LDM data out of one computer and put it in another, would you be able to access files on it in a way equivalent to what asuderma tried with the HDD containing LVM data?

Never used LDM personally so I will refer that to others.

In a nutshell it allows you to dynamically change storage i.e. If /home for example runs out of space you can add an addition hard drive and expand it without having to change your existing setup. Besides Fedora and CentOS I am not sure how many distributions use it as a default.

google?
http://en.wikipedia.org/wiki/Logical_volume_management

IDK that any of them use it by default but most of them make it available.

LVM is most useful for 24x7x365 systems, where it can be used:

• to replace (hot-swappable) HDDs.
• to re-size mounted file systems (that are designed for this -- not ext3).
• to take snapshots of partitions (for backups, especially useful for databases that do not have on-line backup facilities so must be dropped before the backup begins. Without LVM snapshots they cannot be restarted until the backup is finished; with LVM snapshots the can be brought back up as soon as the snapshot is made -- almost instantaneously).

Regards the first and last, LVM has to be considered alonside NAS which offers similar functionality.

For workstations that can be taken off-line for disk and file system reorganisation the first two benefits are not not important (but they may be convenient -- it's easier to expand a LVM logical volume than a real partition) but the snapshot facility is really useful, allowing:

• a backup to be verified against the backed up files. Without snapshotting, verification may produce several reports of changed files which are usually ignored but may indicate that the files in the backup are not exact copies of originals.
• a set of files that need to be consistent (such as database indexes and data or program executables and configuration files) to be backed up as they were at the instant the snapshot was taken.

LVM does not increase performance (it makes it very slightly worse) or availability (especially if the LVM data is spread across multiple HDDs, when failure of any one HDD may take out several logical volumes, each containing a file system). It is, of course, possible to RAID the LVM data to mitigate the danger). LVM is primarily an administrative convenience.

There's a bit more discussion of the pros and cons of LVM on LQ here and here.

LVM Advantages
 

LVM is good because if you need more space on an LVM, you just add a drive to the LVM. LVM can be any combination of drives, even spanning machines, or ATA over ethernet. You could add a flash drive to a LVM. I don't believe optical drives work with LVM, but they might.

LVM has special tools you need to do simple operations. Once a person learns to use the tools, LVM is a piece of cake. But in this instance it can be a pain. Once a LVM is made, it isn't meant to be pulled apart in pieces, and mixed and matched on another LVM.

For most users discrete file systems are more flexible. But if someone is running an enterprise system, with no idea of how much storage space might be needed in the future, or if storage needs change wildy, LVM makes sense.

For instance, you want to make a storage device out of 3 raid arrays, with the option to add more. You just make a LVM out of the 3 external arrays. In the future you can add more arrays as needed.

What I don't like is that some distros make LVM the install default. Most people cannot benefit from LVM, so this default just drives support calls. That gets more people to pay for support, but it's really just a pain for everyone.

Thanks
 

Thanks for the great information and all of your help here. You guys are the reason I joined this site.