[lug] help needed with LVM situation

[Lee Woodworth]

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.
I wouldn't physically install a second LVM physical volume (PV) unless
you know the volume groups (VG) in the existing PVs and the other drive
don't have the same volume group names. It might not be fatal, but LVM
is unlikely to successfully start a duplicate VG.

> 
> 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?
As was mentioned previously, the LVM10 (version 1) and LVM2 metadata formats
differ. I've only been using LVM2 on gentoo, so can't tell you whether the
2.6 dm_mod driver recognizes both formats.

I would physically install the disk in a clean system. Make sure the dm_mod
module is present. Look for the device /dev/mapper/control. If you don't have
udev-like device management, you may have to create the device manually:
    crw-rw---- 1 root root  10, 63 Jun 13 07:57 control
For completely manual configuration of the LVM2 stuff (kernel 2.6):
    # vgscan --makenodes                         : this gets LVM to recogine the PVs
    # pvs                                        : this displays the PVs
    # vgchange -ay                               : this makes the VGs known to the kernel
    # vgs                                        : this shows the VGs
    # ls /dev/mapper/*                           : the VGs should show up here
> 
> 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