Recover partition table for lvm

Question

I managed to run fdisk on the wrong disk. However I was able to save a log of the terminal session.

Fdisk before the accident:

~$ sudo fdisk -l /dev/sda

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x72fc82e8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       36473   292969341   8e  Linux LVM
/dev/sda2           36474       38913    19599300    b  W95 FAT32

Later in the log I found:

$ sudo fdisk -u /dev/sda

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c').

Command (m for help): p

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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: 0x72fc82e8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              64   550000000   274999968+  83  Linux
/dev/sda2       550000001   625142447    37571223+  83  Linux

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 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: 0x72fc82e8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              64   550000000   274999968+  8e  Linux LVM
/dev/sda2       550000001   625142447    37571223+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Das Gerät oder die Ressource ist belegt.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

The system kept on running fine. I partioned /dev/sdb as I wanted correctly and finally run kpartx on /dev/sdb. I suppose this is why the volumes on sda behaved correctly until reboot.

I noticed the error and tried to recover the partition table on /dev/sda

However I did not manage to recover the original partition table. The number of blocks displayed for /dev/sda1 is always 292969348, thus +7 compared to the original. I remember upgrading fdisk before partitioning sdb, maybe it's because of the newer version?

Nevertheless I considered the system safe as I did not mind the fat32 partition which is unused. After a reboot lvm finds the physical volume but no volume groups. I had defined a single volume group consisting only of sda1 and some logical volumes on this group.

Current system status:

~# fdisk -c -l /dev/sda

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x72fc82e8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       36473   292968348+  8e  Linux LVM
/dev/sda2           36474       38913    19599300    b  W95 FAT32

~# pvdisplay 
  "/dev/sda1" is a new physical volume of "279,40 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda1
  VG Name               
  PV Size               279,40 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               ur3J4Y-cwvC-lji2-RPk0-39xb-ltzW-ogN4Sd

~# vgscan 
  Reading all physical volumes.  This may take a while...
  No volume groups found

~# pvck -v /dev/sda1
    Scanning /dev/sda1
  Found label on /dev/sda1, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=192512
    Found LVM2 metadata record at offset=168448, size=28160, offset2=0 size2=0
    Found LVM2 metadata record at offset=67584, size=100864, offset2=0 size2=0

Why can't I restore the original partition table with the exact blocks count? Why doesn't lvm find any volume groups? What are my options now? Can the multiple lvm metadata be the rescue? How would I use them?

score 1 · Answer 1 · answered Jul 21 '11 at 21:44

1

You should break out the backup of your partition table and dd it back into place. Or run a partition recovery tool (The first hit on Google for "recover partitions Linux" looks interesting). But I'd stick with the partition table backup.

answered Jul 21 '11 at 21:44

womble

96,255
29
175
230

mdpc · Answer 2 · 2011-07-22T00:02:21.530

I'll not guarantee that all your data will come back but you can try to remake the LVM metadata. On HPUX anyway, this does not touch the data area at all but you need to have the information on how the LVM was created.

I'd first get rid of the old VG information (vgexport oldvg).
run the pvcreate on the /dev/sda1
vgcreate a newvg using /dev/sda1 using the same parameters as you originally had
run the lvcreate's using the exact same parameters as you originally had
do an fsck on the /dev/newvg/newlv (not real names) and see if it recognizes your data.

Again, I have used this type of process on HP/UX LVM systems with success and it might work in your case.

You may need to re-grub your disk as well if this is a startup/boot disk.

BUT if you don't want any data loss, be sure to backup the disk before you try my suggestions.

score 0 · Answer 3 · answered Jul 27 '11 at 11:49

Restoring the partition table from the output was the key to success. Please note the fine difference in above terminal dumps between the original and the restored partition table: although the cylinder values match, the actual sector counts would not.

Additional help came from testdisk which finally detected and restored the partition information correctly. During the recovery procedure I noticed the following white spots in my backups:

Backup of partition table, e.g. using fdisk -u -l /dev/disk/by-id/example and know the different units as cylinders and sectors.
Backup of lvm configuration in /etc/lvm. (I actually had this backupped but did not was awary of this)

Recover partition table for lvm

3 Answers3