Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am new to LVM and partitioning in general, and so, am in a situation here.

The Situation:

I accidentally overwrote MBR of a Fedora 16-created LVM disk.

Now, everything else on this disk is intact; only the MBR has been corrupted (and that too, only the first 446 of its 512 bytes). I had corrupted the MBR by accidentally issuing:

$ dd if=/the/wrong/446-byte-file.txt of=/dev/sda

This disk (with corrupt MBR), which was initially /dev/sda in System A, is now plugged into my current system, System B, as a secondary disk, /dev/sdb, for the purpose of file-system/data recovery. It is currently unmountable in System B.

Here's the fdisk -l output on System B:

$ fdisk -l
Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x8e678e67

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   475813887   237905920   83  Linux
/dev/sda2       475813888   488396799     6291456   82  Linux swap / Solaris

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048     1026047      512000   83  Linux
/dev/sdb2         1026048   156301311    77637632   8e  Linux LVM

Question: With /dev/sda running a healthy, non-LVM setup of Fedora 16, how do I manually mount /dev/sdb (with corrupt MBR) somewhere inside System B so as to be able to recover all the data from it? (The data, by the way, is stored on an ext4 file system inside.)

What I have tried so far:

a) I issued pvs and got this:

(Notice how the VG column is empty!)

$ pvs
  PV         VG   Fmt  Attr PSize  PFree 
  /dev/sdb2       lvm2 a--  74.04g 74.04g

b) I issued pvscan, I got this:

$ pvscan
  PV /dev/sdb2                      lvm2 [74.04 GiB]
  Total: 1 [74.04 GiB] / in use: 0 [0   ] / in no VG: 1 [74.04 GiB]

c) I have the contents of /etc/lvm/backup/vg_XYZ available with me from an earlier backup. But I don't know how to infer/construct Volume Name and Volume Paths from this file (Note that, in this file, /dev/sda2 is the partition of interest which has now become /dev/sdb2 in present system, System B):

# Generated by LVM2 version 2.02.84(2) (2011-02-09): Tue Oct 25 22:10:55 2011

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgchange -a y --sysinit'"

creation_host = "XYZ"   # Linux XYZ 2.6.38.6-26.rc1.fc15.i686.PAE #1 SMP Mon May 9 20:36:50 UTC 2011 i686
creation_time = 1319560855      # Tue Oct 25 22:10:55 2011

vg_XYZ {
        id = "WN8593-xRnx-dn29-rcpb-tRAm-Bs5R-93DGWw"
        seqno = 3
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 65536             # 32 Megabytes
        max_lv = 0
        max_pv = 0
        metadata_copies = 0

        physical_volumes {

                pv0 {
                        id = "voQHGq-9m5t-u39a-UBWP-1qKM-sS4M-t3EPYG"
                        device = "/dev/sda2"    # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 155275264    # 74.041 Gigabytes
                        pe_start = 2048
                        pe_count = 2369 # 74.0312 Gigabytes
                }
        }

        logical_volumes {

                lv_swap {
                        id = "Osi18q-409G-iG1s-Mdb2-00Lt-wtQV-WpF2mN"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 126      # 3.9375 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 0
                                ]
                        }
                }

                lv_root {
                        id = "Wc8qdx-sYKi-qFeM-Bv48-YvZC-ClGU-VrYl4W"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 2243     # 70.0938 Gigabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv0", 126
                                ]
                        }
                }
        }
}

Your prompt help would be greatly appreciated, otherwise I'm in real trouble!

Many thanks in advance...

/HS

share|improve this question
    
Couldn't you just dd if=/the/right/446bytefile of=/dev/sdb, or is it lost in /dev/sdb and you can't access it? –  Rob Apr 12 '12 at 16:48
    
@Rob Don't have the right file. :-( I wish I did. –  Harry Apr 12 '12 at 17:11

3 Answers 3

up vote 2 down vote accepted

Try the following steps in order.


EDIT (by Harry)

  1. Had to do a vgcfgrestore for the rest of commands listed below (starting with vgscan) to take effect.

    vgcfgrestore vg_XYZ

  2. Also had to an e2fsck -y /dev/vg_XYZ/lv_root for the mount to succeed.

Details described at this comp.os.linux.setup post here.


Since you've already done a pvscan, proceed to a vgscan:

vgscan --partial --mknodes --verbose

With luck, that should discover the volume group vg_XYZ on /dev/sdb2, and create any necessary device nodes in /dev.

Next, make the volume group available:

vgchange -a y vg_XYZ

Follow that up with an lvscan:

lvscan --verbose

And finally, make the logical volume available:

lvchange -a y vg_XYZ/lv_root

You should now be able to mount lv_root somewhere to access its data, e.g.

mkdir -p /mnt/rescue
mount -t ext4 -o ro /dev/vg_XYZ/lv_root /mnt/rescue

Good luck!

share|improve this answer
    
The vgscan --partial --mknodes --verbose gave a 'No volume groups found'. –  Harry Apr 12 '12 at 17:37
1  
Dang. Does vgimport --verbose vg_XYZ do anything? –  Steven Monday Apr 12 '12 at 17:44
    
It gives: Volume group "vg_XYZ" not found –  Harry Apr 12 '12 at 17:57

You may be able to create the device manually using the numbers found in the backup file.

dmsetup create foo --table "0 146997248 linear /dev/sdb2 8259584"
mount -o ro /dev/mapper/foo /mnt

The numbers are calculated as:

146997248 = extent_count * extent_size = 2243 * 65536
8259584 = pe_start + 126 * extent_size = 2048 + 126 * 65536

This is UNTESTED. If the backup doesn’t provide an accurate picture of the current configuration (or if I’ve got the calculations wrong - I’ve reproduced them by analogy to local configuration rather than a sufficiently deep understanding of LVM) then it won’t work.

share|improve this answer
    
The dmsetup command fails saying, "Incorrect number of arguments". I'm using Fedora 16. I tried the table_file version of the command (by putting '0 146997248 linear /dev/sdb2 8259584' in table.txt and specifying dmsetup create foo --table table.txt), and I got "Invalid format on line 1 of table. Command failed". –  Harry Apr 12 '12 at 18:45
1  
Oh, sorry, the table argument should be quoted. I’ve updated it. –  Richard Kettlewell Apr 12 '12 at 18:59
    
The mount command gives, "mount: you must specify the filesystem type". –  Harry Apr 12 '12 at 19:23
1  
That’s not a very encouraging sign, since if there’s actually a filesystem there mount can usually figure out the type automatically. The syntax to use to tell it explicitly is given in Steven’s answer, anyway. –  Richard Kettlewell Apr 12 '12 at 19:29
    
When I had tried that, it said, "mount: wrong fs type, bad option, bad superblock on /dev/mapper/foo, missing codepage or helper program, or other error In some cases useful info is found in syslog - trydmesg | tail or so" What to do, now? –  Harry Apr 12 '12 at 19:34

the PartedMagic liveCD/USB has all kinds of tools that might be able to recover the MBR from that disk. testdisk is one, and I know there are others. It's saved my skin a few times from badly typed commands, there's a reason dd is nicknamed disk destroyer.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.