3

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

2
  • 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, 2012 at 16:48
  • @Rob Don't have the right file. :-( I wish I did.
    – Harry
    Apr 12, 2012 at 17:11

3 Answers 3

3

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!

3
  • The vgscan --partial --mknodes --verbose gave a 'No volume groups found'.
    – Harry
    Apr 12, 2012 at 17:37
  • 1
    Dang. Does vgimport --verbose vg_XYZ do anything? Apr 12, 2012 at 17:44
  • It gives: Volume group "vg_XYZ" not found
    – Harry
    Apr 12, 2012 at 17:57
2

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.

1

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.

6
  • 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, 2012 at 18:45
  • 1
    Oh, sorry, the table argument should be quoted. I’ve updated it. Apr 12, 2012 at 18:59
  • The mount command gives, "mount: you must specify the filesystem type".
    – Harry
    Apr 12, 2012 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. Apr 12, 2012 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, 2012 at 19:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .