Re: Resizing a GPT disk, for the record

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Wed, 17 Jun 2015, John Nemeth wrote:
> On Jun 17,  1:49pm, Stephen Borrill wrote:
> }
> } For the record, I'm presenting a transcript of dealing with a
> } resized virtual disk with a GPT table. The disk has been resized
> } from 10G to 20G. Note the secondary GPT table cannot be located
> } because it is no longer at the end of the disk.
>
>     If you resize the media, you should use "gpt resizedisk".
> That will either relocate the secondary GPT, or create a new one.
> It will also update all size fields for the new media size, and
> adjust the pointer to the secondary GPT.  "gpt recover" does not
> do these steps, it simply copies whichever GPT exists to the other
> one.

I think my NetBSD 7 install just predated the big gpt pullup by a matter 
of hours. I downloaded it from the autobuild cluster on 2nd June from 
the latest build which was the same day the pullup happened... So I did 
not have gpt resizedisk.

> } (aside: when I first did this, after the recover step the free space was
> } no longer listed. I could not repeat this, but I expect a gpt resize -s
>
>     Likely due to incorrect data in the GPT header.
>
> } <existing size> -i 1 xbd1 would have brought it back).
>
>     Uh, why?  "gpt resize" doesn't touch anything except the
> partition that's being resized, and update CRCs.  Your suggested
> command does nothing, except print a message saying that nothing
> needs to be done.

The reason I suggested is that it worked on the one time the free space 
disappeared, but as I couldn't repeat it, I could not be certain.

Anyway, thanks for the heads up about gpt resizedisk.

--
Stephen