Problems resizing root filesystem with extended-partition, lvm, and snapshots on vm disk

Question

I set the disk size of my root drive too low, and need to expand it. Default install of Ubuntu 16lts server.

I've searched and the answers/solutions found do not address the issue. (the problems appear identical, but the steps didn't work or the options were not available on my system).

• no How do I resize root partition?
• no https://help.ubuntu.com/community/HowtoPartition/ResizingPartition
• no https://superuser.com/questions/917988/gparted-cannot-resize-extended-or-lvm-partition
• I wasn't able to make any progress with several other answers lvm (lvchange manually, as well as system-config-lvm) from inside a separate booted ubuntu box.

I'm booting a gparted live-cd (latest/just downloaed), but i also tried this by plugging the disk into a different ubuntu system (another VM). As you can see in the gparted screenshot below, i have

• booted a liveCD (gparted)
• one disk (sda) incidentally, it's a VDI in Virtualbox. I have already enlarged the disk (as shown in the 'unallocated space`
• of interest is /dev/sda5 lvm volume which is contained in /dev/sda2 extended

I've tried:

• From the gparted live iso, I can right-click /dev/sda5 to deactivate. Also, the lvdisplay output below is AFTER this deactivate.
  • however this doesn't remove the Lock (but does think for some time while, and re-scans the disk)
  • and resize remains greyed out on /dev/sda2
  • lvdisplay doesn't seem to show a change
• from the command line, run lvchange -an,
  • does seem to change the available status on /dev/sda5
  • but closing/re-opening gparted still shows locked

Thank you, I appreciate your help!

mount | grep sd --> nothing (not shown). From the gparted live-iso i have also dumped fdisk -l

and lvdisplay

and vgdisplay

Solution

After a lot of consternation :) I discovered my issue was related at least in part to snapshots (as mentioned, this is all in a VM).

• the disk i'm attempting to modify is from a machine with snapshots
• i mounted / attempted to resize the base/original .vdi, didn't do anything with the snapshots
• the contents of that were literally a fresh install, so it wasn't apparent to me initially that the GUID i saw was actually the right disk but an old 'snapshot'.

to prove this out, i cloned the VM from virtualbox's snapshot UI, which gives the option to flatten it at the current state.

This appears to work (including no observed data corruption) so I'm back booted in the original svr vm, with the resized disk!

1. power down & clone the vm from whatever state/snapshot - including only 'current state` (which will flatten all snapshots)
   • I'm sure this is all possible on top of the snapshots; for me this was acceptable and took some variables out of the mix
   • note i have a dynamic disk. Not sure if there are any differences for static (should be NO, but i haven't tested)
2. resize the resultant cloned & flattened vdi (eg no snapshots)
   • VboxManage.exe modifyhd <vdi> --resize 50000 #~50gb
3. connect that resized disk to a separate linux VM and boot up
4. unmount and remove the vg
   • the root fs I'm trying to resize is at /dev/mm-ubuntu16-svr-vg/root
     • call this /dev/MY_VG/root below
   • mount | grep 'VG' then sudo umount <mountpoint> if it was mounted
   • sudo lvchange -an /dev/MY_VG # remove the logical volume
   • sudo vgchange -an MY_VG # remove the volume group
5. resize the partition/volumn/and fs
   • sudo gparted & # proceed with normal resize
     • mine was an extended partition grow, then a grow on the lv
     • all the 'normal' instructions work here, in my quetions picture this is a resize (grow) /dev/sda2 followed by a resize (grow) on /dev/sda5
   • lvresize -l +100%FREE /dev/MY_VG/root
   • e2fsk -f /dev/MY_VG/root # resize2fs prompted me to run this cleanup
   • resize2fs /dev/MY_VG/root

Done! while still in the other VM, mount and check capacity:

• sudo vgchange -ay MY_VG && sudo lvchange -ay /dev/MY_VG # eg reverse of the remove
• sudo mkdir <mountpoint> && sudo mount /dev/MY_VG/root <mountpoint>
• df -h # YAY shows ~50gb total !

And then shutting down, and booting into the original (well, the Cloned & flattened) vm, it boots and has the expected free space / 50gb root drive & filesystem.

hope this helps someone!

Comments

[George Udosen]

Please place your cursor (to the left of the image, somehow that matters) on the area with the padlock and try it there on the /dev/sda2 If that doesn't work try the /dev/sda5 but make sure its under the partition column

[some bits flipped]

Hi @George - for either row, i get the same context menu no matter where i click in the row. For /dev/sda2 row, all choices are greyed out except "manage flags". For /dev/sda5 it additionally does show 'resize' and deactivate, but deactivate doesn't seem to have any effect.

[George Udosen]

Let me check that on my VM...

[George Udosen]

It should work with /dev/sda5, right click and do a check

[some bits flipped]

@George - on /dev/sda5 i DO have a Deactivate option. I click that, then in the lower-left status bar in gparted: something flashes quickly (too quick to read), then it spends ~20 seconds "searching for lvm volumes". Running lvdisplay before and after, both volumes in /dev/sda5 (root and swap) remain available. I believe it is intended to switch to "not-available"?

[George Udosen]

Please if you could post an image after doing the deactivation that would help

[some bits flipped]

@George there is no change in the output of the commands above before and after running gparted-->deactivate on /dev/sda5 (captured the output > and diff'd the text files)

[some bits flipped]

another strange thing i've isolated: from withing the gparted liveCd, gparted loads and says both sda5 and sda2 are 'locked'. If i close gparted, run lvchange -an /dev/<vol> && vgchange -an <vol>, then re-open gparted, they DO show unlocked. But then closing gparted again, re-opening, both say 'locked' again.

[some bits flipped]

Hi @George - i upvoted a couple of your comments; despite not fixing my issue your re-assurance this should work helped me keep going (rather than starting over from a fresh VM, which would have set me back several days).

[George Udosen]

Great work glad it all worked out. Cheers