[lug] help needed with LVM situation

[Dan Ferris]

LVM should be machine agnostic.  If you have the hard disks, you should 
be able to plug them in and start the volumes.

There are two different metadata formats.  LVM version 1 which works 
with the 2.4 kernels and LVM version 2 which is 2.6 and up.  They might 
be trying to start an LVM version 1 volume with LVM version 2 utilities, 
which would complain.  You can convert LVM version 1 to LVM version 2, 
but not 2 to version 1.

If I was you I would put the disks into a system with no LVM that has 
the same OS or kernel rev and then see if you can start the volumes.  I 
don't know much about Debian, but I do know that Red Hat makes LVM very 
easy.  It will deal with LVM for you at boot time as long as you have 
physical volumes.

Dan


Nate Duehr wrote:
> A friend of mine recently passed away, and another friend has been 
> painstakingly working on recovering some important data from one of his 
> machines.
> 
> A short re-cap:
> 
> He had two systems online at his home.  We'll call them system A and 
> system B.
> 
> The folks trying to recover data from them had numerous problems facing 
> them:
> 1. No one had any of the passwords.
> 2. One machine NFS mounted the other.
> 3. Calling them, machine A and machine B... Machine B had a motherboard 
> failure within a day or two of our mutual friend's passing.
> 4. Both machines were (thankfully) set up with non-LVM root filesystems.
> 
> So they've been working on it for a while now, they're not Linux admins, 
> but they work on Unix at work as Engineers for a living.  They got 
> Machine A online and figured out how to get into it by mucking around 
> with the root password since they had physical access.  No problem.  
> Just a learning curve.
> 
> Then they found that Machine A had a bunch of hard-coded NFS mounts to 
> Machine B which was off-line, and contained the CVS repository and other 
> things they were struggling to recover.
> 
> They placed the hard disk from Machine B into Machine A and attempted to 
> figure out how to mount it, thinking they could just grab a quick 
> backup... and they found... LVM.  Actually, as I talked to one of my 
> friends about this on the phone tonight, they found both machines were 
> set up with LVM.  None of them had ever used LVM before, or had to deal 
> with it.  Again, a learning curve, but not insurmountable (no pun 
> intended).
> 
> We also attempted this evening, simply mounting up /etc off Machine B 
> and wiping out the root password, and then booting from that disk.  What 
> we found was that the LVM tools are complaining that they're "not the 
> right version" for the LVM currently on the disk.  I *think*, but 
> haven't had a chance to prove (hard to do this on the phone) is that 
> Machine A's LVM version is higher than Machine B's, and it "did 
> something" to the LVM VG it found suddenly on /dev/hdb3 when the disk 
> was added.
> 
> Current status:
> 
> We figured out that both machines had single hard disks, and apparently 
> both had some version of Debian LVM on them.  They may not have been on 
> the same release of Debian, nor using the same version of LVM, but 
> initial digging didn't turn up much.  We can get the LVM version (lvm10 
> package is installed on Machine A) from Machine A.
> 
> We also figured out, and here's the annoying part... both VG's are named 
> the same.  If you use the LVM tools to look at things (trying not to 
> trash the only copy of this data), you see there's a PV in /dev/hdb3 
> (when Machine B's disk is physically in Machine A as /dev/hdb), and the 
> VG is named the same as the currently active VG on Machine A... vg00.
> 
> (There's a case to be made here for never accepting default names for 
> VG's, I think... if one machine had machineA_vg00 as it's VG name, and 
> the other machineB_vg00, this wouldn't be a problem.)
> 
> To add insult to injury, it would appear that both machines are using 
> ReiserFS for their filesystems in their VG's.
> 
> With the recent Linux RAID discussions, I have this gut feeling that 
> tells me there are some real LVM gurus lurking on this list.  What say 
> you?  How would you get this silly thing mounted?
> 
> One thought we've had, but it was getting late and messing with disks 
> and LVM late at night when everyone's tired and it's the only known copy 
> of the data, is a bad idea...  was to rename the VG that's currently 
> active on the working Machine A.   Then there would be no namespace 
> clash between the two.
> 
> The other thought that seemed saner, and slightly safer, would be to 
> load a completely clean copy of Debian Sarge up on another machine, 
> install the disk from Machine B into it, and then just activate the VG 
> there.  Personally I like that idea better, but it is more difficult 
> (since no one has any "extra" machines lying around at the moment -- or 
> if we do, we're all separated by at least 50 miles at our homes or more).
> 
> So I'm appealing to the LVM gurus here... any thoughts?
> 
> Of course, for all of us, this is a good example of why to keep 
> known-good onsite and offsite backups that are easily readable by 
> anything... CD/DVD comes to mind here.
> 
> What it makes more clear even than that, is if there's someone elses 
> important data on any of your machines, a good document kept with your 
> will or whatever... somewhere someone would find it... that explains 
> your backup scheme, perhaps has your root passwords or instructions 
> about how to break into your machines, etc... is probably not a bad idea 
> for anyone who has to struggle through losing a friend, and at the same 
> time has to try to retrieve any of your "digital life".
> 
> A Digital Systems Will, if you like.  Who gets the drives, how do they 
> recover the data and who's responsible to distribute the data if 
> multiple people need copies for themselves, if your machines ever go 
> silent... because you did.  The named executor of your "Digital Estate"?
> 
> -- 
> Nate Duehr
> nate at natetech.com
> 
> 
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
> 
>