I have two servers running FC3. The first machine (called Orca) has died due to what is likely a problem on the logic board or power supply. Unfortunately there are some critical files that I need to rescue from the lone drive on Orca. I retrieved the hd and threw it into an external casing, and hooked it up to my Mac.. Only to find that the drive is formatted with an "Linux LVM partition". I started doing a little homework and now have a basic understanding of what this exactly means. So, after running through a couple different ideas, I decided the easiest solution probably lies with connecting Orca's hd up to the second server (called Beluga). This time I could use the various lvm commands to see which logical volumes, volume groups, and physical volumes existed on the machine. Because both machines contained a single harddrive, each with FC3 installed (and thus a large root partition and a smaller swap partition), I would expect to see something along the lines of two logical groups, each containing two logical volumes and one physical volume. Oddly enough, only a single volume group appeared (VolGroup00). The reason for this turns out to be because on their 'home' machines, the two hard drives have a single volume group.. The problem being that both are named VolGroup00 and so when both drives are mounted, only VolGroup00 from Beluga is present. I found some old threads where people had similar problems, and discovered that one solution is to somehow deactivate the 'home' volume and rename its volume group (to something like VolGroup01) before connecting the second drive.. Which should then appear as VolGroup00 and thus allow you to mount its logical volume via mount /dev/VolGroup00/LogVol01 (which would roughly correspond to /dev/sbd2.. The root partition on the second drive). I went about attempting this with little success. It then occurred to me I could just go into the boot sequence and boot off the second drive (it didn't really occur to me that this slightly older machine supported booting off a usb device). Doh! Unfortunately I mucked up the volume groups and logical volumes on the second drive, but I don't think the damage is irreparable (after all, it's just the LVM info that is muddled, not the actual physical data). So, I'm hoping that if I post the output of vgscan, lvscan, and pvscan, maybe someone out there savvy with LVM commands can help me put things in the right order. I don't much care whether I go with renaming one of the volume groups to allow both to coexist (let's call it plan B), or whether I just put the external drive from Orca back into order so that I might boot off of it as the sole drive (plan A)... Though I feel that plan A is the safer option in order to leave Beluga's home drive alone. [root@beluga ~]# pvscan PV /dev/sdb2 VG VolGroup01 lvm2 [74.40 GB / 74.40 GB free] PV /dev/sda2 VG VolGroup00 lvm2 [279.34 GB / 160.00 MB free] Total: 2 [353.74 GB] / in use: 2 [353.74 GB] / in no VG: 0 [0 ] [root@beluga ~]# vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 [root@beluga ~]# lvscan ACTIVE '/dev/VolGroup00/LogVol00' [277.25 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit As you can see, a VolGroup01 does exist... With a physical volume /dev/sdb2 associated with it ...as a result of my experimenting. I'm just not sure how to get the corresponding logical volumes for that volume group. Lvscan would then look something like... [root@beluga ~]# lvscan ACTIVE '/dev/VolGroup00/LogVol00' [277.25 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit ACTIVE '/dev/VolGroup01/LogVol00' [74.40 GB] inherit ACTIVE '/dev/VolGroup01/LogVol01' [probably 1.94 GB] inherit I think I ran either a vgreduce at some point, so I might have to do an lvcreate or something like that? Unfortunately I don't understand LVM as much as I'd like to, and am slightly confused with how it works. Can anyone out there lend me a hand? Thanks in advance, Andrew
