2

I accidentally removed all my Logical Volumes with lvremove. After reboot the lvm backups were lost (live CD) so I can’t use vgcfgrestore. testdisk can find the partitions by analysis so they are still there. Is there a way to restore the logical volumes?

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/Manjaro - 999 GB / 931 GiB - 1952782336 sectors
     Partition               Start        End    Size in sectors
>  MS Data                   264190   82675709   82411520 [ManjaroRoot]
   MS Data                 61442046 1739163645 1677721600 [ManjaroHome]
 P MS Data               1762396158 1844807677   82411520 [ManjaroRoot]
 P Linux Swap            1936631800 1936631815         16

dmsetup ls

Manjaro (254:0)

[root@manjaro ~]# dmsetup table Manjaro
0 1952782336 crypt aes-xts-plain 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:4 4096

pvdisplay -v

    Scanning for physical volume names
  --- Physical volume ---
  PV Name               /dev/mapper/Manjaro
  VG Name               ManjaroVG
  PV Size               931.16 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              238376
  Free PE               238376
  Allocated PE          0
  PV UUID               3Vv8c2-O0fr-jOgd-QIBR-WBMY-RGBf-rujHnF

vgdisplay -v

    Finding all volume groups
    Finding volume group "ManjaroVG"
  --- Volume group ---
  VG Name               ManjaroVG
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  16
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               931.16 GiB
  PE Size               4.00 MiB
  Total PE              238376
  Alloc PE / Size       0 / 0   
  Free  PE / Size       238376 / 931.16 GiB
  VG UUID               VWNJNN-iaBv-cLuu-1AAb-nS00-SogZ-z6qDU0

  --- Physical volumes ---
  PV Name               /dev/mapper/Manjaro     
  PV UUID               3Vv8c2-O0fr-jOgd-QIBR-WBMY-RGBf-rujHnF
  PV Status             allocatable
  Total PE / Free PE    238376 / 238376

lvdisplay -v

    Finding all logical volumes

trying to create LV

[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 82411520 linear 8:4 4096"
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 82411520 linear 8:4 4096" --readonly
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "264190 100 linear 8:4 4096" --readonly
device-mapper: reload ioctl on ManjaroRoot failed: Invalid argument
Command failed
[root@manjaro ~]# dmsetup create ManjaroRoot --table "0 100 linear 8:4 4096" --readonly
[root@manjaro ~]# lvscan 
[root@manjaro ~]# dumpe2fs -h /dev/mapper/ManjaroRoot 
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/ManjaroRoot
Couldn't find valid filesystem superblock.

Getting closer

[root@manjaro ~]# dmsetup create ManjaroRoot --table "0 82411520 linear /dev/mapper/Manjaro 264190" --readonly
[root@manjaro ~]# dumpe2fs -h /dev/mapper/ManjaroRoot 
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   ManjaroRoot
Last mounted on:          /
Filesystem UUID:          b5cbe2bf-54cf-46c3-96ed-047ad7e77bcf
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2575440
Block count:              10301440
Reserved block count:     488035
Free blocks:              2771298
Free inodes:              2140018
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Mon Nov 17 06:33:51 2014
Last mount time:          Wed Jan  7 15:40:24 2015
Last write time:          Wed Jan  7 15:40:24 2015
Mount count:              37
Maximum mount count:      -1
Last checked:             Mon Nov 17 06:33:51 2014
Check interval:           0 (<none>)
Lifetime writes:          62 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      bf1a643c-f34a-456d-bb88-4ea72a94239c
Journal backup:           inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode

mounting

[root@manjaro ~]# mount "/dev/mapper/ManjaroHome" "/run/media/manjaro/ManjaroHome"
mount: /dev/mapper/ManjaroHome is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/ManjaroHome,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

… nothing new in dmesg

Thunar tried the following – which also errored but at least there is something in dmesg:

[root@manjaro ~]# mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/mapper/ManjaroHome" "/run/media/manjaro/ManjaroHome"
mount: /dev/mapper/ManjaroHome is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/ManjaroHome,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

dmesg

[Wed Jan 21 06:10:04 2015] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
  • Which filesystem(s) are on the LVs? – Hauke Laging Jan 20 '15 at 3:31
  • Strange. Looks like ManjaroHome and ManjaroRoot are overlapping... Seems to be a detection error. – Hauke Laging Jan 20 '15 at 8:22
  • Might be a remainder of manipulation I did last week. I extended the first ManjaroRoot. It didn’t cause any trouble though. – Jan Tojnar Jan 20 '15 at 8:28
  • Extending LVs is not a problem in general. But it can make restoring much harder it it causes fragmentation. – Hauke Laging Jan 20 '15 at 8:52
  • 1
    You have not paid attention to what the table values mean. "0 82411520 linear /dev/mapper/Manjaro 264190" – Hauke Laging Jan 20 '15 at 9:11
4

It should be easy to restore the LVs if they were not fragmented (on LVM level) and if they were simple (linear) volumes; it may work with thin provisioning, too, but I am not familiar with that. You just have to create them in the same order and with the same size as before.

I am not familiar with testdisk. If it tells you the size of the volumes it has found then you need not find out yourself.

It helps to understand how dmsetup works. An example from my system:

> dmsetup ls
[...]
linux2-test   (254:4)

> dmsetup table linux2-test
0 106496 linear 8:8 384

The first 384 sectors contain the LVM metadata. If this volume was deleted then testdisk should show an ext4 volume beginning at sector 384. Then you can set up a temporary device mapper device:

> dmsetup create restore-lv-1 --table "0 100 linear 8:8 384" --readonly

The number of sectors (100 in this example) is not known first so you can choose nearly any value but it must not exceed the size of the underlying block device. You can use a small value like 100 as you just need the superblock. Then you read the filesystem size from the temp device:

> dumpe2fs -h /dev/mapper/restore-lv-1
dumpe2fs 1.41.14 (22-Dec-2010)
[...]
Block count:              53248
[...]
Block size:               1024
[...]

The size of the volume is 53248*1024=54525952 which is 106496 512-byte sectors. If the filesystem had covered the whole LV (which is usually the case) then this is the device size, too. The offset of the next LV should be 106496+384=106880. With this offset you can repeat this process.

If you create a new LV you should check with dmsetup table whether is has the expected offset and length.

  • According to dmsetup man page, the 8:8 (or 8:4 in my case) means destination_device. Will that be the same for all LVs? – Jan Tojnar Jan 20 '15 at 6:09
  • Also testdisk says the partition starts on sector 264190 should the first table start at zero or this number? – Jan Tojnar Jan 20 '15 at 6:17
  • @JanTojnar The destination_device is the PV i.e. the drive partition on which the LVs reside. Whether that is the same for all LVs depends on it whether you have one or more PVs. Usually there is only one. 264190 is the offset you need (the last value in the table definition). – Hauke Laging Jan 20 '15 at 7:06
  • Also is it possible to use linear when dmsetup ls target_type is crypt? – Jan Tojnar Jan 20 '15 at 7:27
  • @JanTojnar crypt cannot be replaced by linear, of course. Is your PV a LUKS volume? Have you entered a password in TestDisk? – Hauke Laging Jan 20 '15 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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