0

I have a VMware ESXi virtual machine running Ubuntu 18.04 with LVM configured partitions. I was trying to extend one of the logical volumes mount as / but mistakenly and foolishly deleted the LVM partition using cfdisk (the partition was formatted as ext4). Here is what I did which caused the problem:

  1. Increased the VM disk size in vSphere ESXi
  2. Performed a rescan on SCSI device to make it recognize the disk resize without reboot
  3. Confirmed the new disk disk using fdisk -l
  4. Foolishly deleting the LVM partition (sda2) using cfdisk and recreating it with the new size (actually don't remember whether I changed the new partition type to LVM or not)
  5. Tried to increase the PV size using pvresize /dev/sda2 Tried running partprobe to check why the PV was not resized where I got a message indicating that partition where in use by system
  6. Performed a reboot and the OS did not boot as it was not able to mount the partitions This is where the issue began. What I tried:
  7. I did boot the system using GParted bootable disk, restored the LVM partitions using pvcreate with the same UUID and vgcfgrestore (I recovered the old lvm backups using testdisk tool) with no success as the volume containing root partition was not mountable (unknown filesystem)
  8. I tried running testdisk to recover important directories and files, but some restored files (I did check some text files, e.g. config and php files) have scrambled contents.

1 Answer 1

0

The resolution was easy but took time for me to figure it out:

  1. Ran testdisk /dev/sda (the whole disk)
  2. Did a quick search and found two partitions (one 500 MB ext2 /boot partition and one 60 GB LVM2 partition)
  3. Wrote the found partition table on disk
  4. Performed a pvscan, vgscan and vgchange -ay (encountered an error indicating that the VG size was larger than the PV an therefore lvs shows the root lv with suspended flag).
  5. Extended the /dev/sda2 (LVM partition) to consume the remaining free space on disk using cfdisk
  6. Performed vgchange -ay one again and voila the system was able to reboot normally.

You must log in to answer this question.

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