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.