GPT resizing on virtualbox client

Can anyone help with guidance on how to resize GPT on a virtualBox client? I have resized the virtual disk in vBox from the host, and resized the client appliance virtual disk from a livedisk instance using gpart, but du is obdurate and insists that the new "capacity" is unknown, (geom also) and that my available space is as it was. Am I missing something here?

Thanks for any help - this is one of those rare virtual machines which I really do not want to trash, and I underprovided at first build :r
 
Increasing the size of a partition does not resize the filesystem on it. growfs(8) does that. Before you do that, back it up. In fact, it should have been backed up before resizing the partitions. I prefer to back up, resize partitions, newfs(8) them, and restore to make sure all the filesystem structures are in the expected places. growfs(8) does not do that, and some things are surprised when the structures are not where expected.
 
I had to resize a Xen image and got it working with these steps inside FreeBSD domU.

# gpart show will show a corrupted table after resizing your disk image.
To recover secondary table issue:
# gpart recover ada0

If your disk is in use (you've booted from it) enable foot-shooting:
# sysctl kern.geom.debugflags=0x10

Then resize your partition (i.e. partition 3)
# gpart resize -i 3 ada0

Now grow your filesystem:
# zpool online -e poolname vdev
 
GPT partition resizing on virtualBox

wblock@ said:
...growfs() does that. Before you do that, back it up. In fact, it should have been backed up before resizing the partitions. I prefer to back up, resize partitions, newfs(8) them...

Many thanks. I'll back up and may try both out of interest if I have time and report back. Newfs(8) makes a lot of sense though I'd need to check that I can see a samba share from a livedisk session as I have / on this partition, and as I believe you mentioned in a previous thread, vBox shared files are not yet in place on freeBSD hence samba.
 
GPT partition resizing on virtualBox

Nukama said:
If your disk is in use (you've booted from it) enable foot-shooting:
# sysctl kern.geom.debugflags=0x10

I did not know of this - and nicely put too! Thanks.
 
Status report: I woke up, hearing the words "virtual appliance" over and over... so I did the obvious: cloned the vbox so now I can play - no need to wait on samba transfers and so on. If I am still feeling bold then I'll attach the other drive, newfs, then rebuild / from the clone.
 
bozzy said:
I did not know of this - and nicely put too! Thanks.

That sysctl allows changes to mounted devices, which is almost always a mistake. Boot from an alternate, like mfsBSD, and the sysctl override is not needed and disk changes are more likely to work.
 
wblock@ said:
...Boot from an alternate, like mfsBSD, and the sysctl override is not needed...

Dunnit as you suggested - very straightforward, fsck reads "clean", headroom abounds, clone destroyed, peace reigns.
 
Back
Top