I had (paying attention to the past time here) a Centos 6.7 host who was migrated using Vmware conversion tool from a HyperV cluster. Therefore, the final configuration of its disks was:

/ dev / sda1 -> BOOT
/ dev / sdb1 -> Physical Volume
VG on / dev / sdb1
6 LVs on VG, root included

Time came and a logical volume was filled and VG did not have any free PEs to extend. So I made a ninja move and I extended /dev/sdb and went (wrongly) to rewrite the partition table to grow the PV. After that, the VM did not boot again because the LVM metadata was overwritten.

I tried several scenarios, the most successful was strings / dev / sdb | head -n 1000 where I found copies of the LVM information (from the auto backups it makes to each modification), created a file from what seemed to be the latest configuration, created a PV with uuid same as the original and --restorefile the specified file. I continued with vgcfgrestore and vgchange -ay and all logical volumes became visible, but mount fails and I get the bad superblock or wrong fs type error. I have the feeling that the boundaries of LVs are not correct and I have overlaps with the old structure, hence the problem with the filesystem during mount.

Has any of you seen anything like that? Can anybody suggest any solution?

  • Possible help: superuser.com/questions/411697/… – Broco Oct 26 '18 at 8:06
  • What was wrong about writing the partition table? What file system type are the volumes ? – John Mahowald Oct 26 '18 at 12:44
  • Filesystem was ext4 on all logical volumes. – vidas Oct 26 '18 at 14:21

If you have backups of the host configuration and data, it will be faster to reinstall the OS and restore.

Make a backup image of the LVs, such as with dd to a regular file, or perhaps a LVM snapshot. Run a file system repair tool on the backup, such as xfs_repair -f /backup/lv. This helps indicate if there is a recoverable file system.

Edit: you indicated ext4. Try all the superblocks as described over on UNIX Stack Exchange: Recovering ext4 superblocks. The linked data recovery page from the Ubuntu wiki has some file extraction utilities if you really need files that don't have a backup.

Personally, I prefer to create PVs on entire disks without a partition table, such as /dev/sdb. Resized disks can be added immediately.

  • Filesystem was ext4 and I run a "fsck.ext4 /dev/vg_name/lv_name" but it still responds with "Bad magic number in super-block while trying to open..." – vidas Oct 26 '18 at 14:23
  • I don't think it is likely you will recover the file system intact. Try examining the superblocks using examples like one I linked in my edit. Then extract any valuable files from the image. – John Mahowald Oct 27 '18 at 11:52

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.