Clone a FBSD system with something in the likes of ghost

Polytropon freebsd at
Mon Oct 3 17:22:29 UTC 2016

On Mon, 3 Oct 2016 10:49:06 -0600 (MDT), Warren Block wrote:
> In the old MBR days, there was no serious problem with partition tables, 
> because there was only one partition table at the start of the disk. 
> GPT puts one at the start of the disk and the end of the disk, so binary 
> copying a smaller disk to a larger one puts the secondary partition 
> table somewhere before the end of the larger disk.  It's not really 
> possible to copy a larger disk to a smaller one with dd(1), so that 
> problem does not come up.

Isn't it _technically_ possible to capture the 2nd GPT table (at the
end of the source disk) and calculate its proper position in relation
to the size of the target disk, and then put it there?

Initial state: empty disk:

	/dev/da0	--------------------

Image smaller than this disk, including two GPT tables (1 and 2):

	source.img	1#######2

Copy the image:

	# dd if=source.img of=/dev/da0

	/dev/da0	1#######2-----------

Get the 2nd GPT table

	# dd if=source.img of=gpt2.img skip=1000 bs=1M count=1

	gpt2.img	2

Put it at the end of the disk (the skip= value has to be calculated
from the disk size):

	# dd if=gpt2.img of=/dev/da0 skip=1000

	/dev/da0	1#######2----------2

Optional step: remove (useless or confusing) 2nd GPT table left
behind by the image:

	# dd if=/dev/zero of=/dev/da0 skip=1000 bs=1M count=1

	/dev/da0	1#######-----------2


I assume that a 2nd GPT table somewhere inside the free space is
not a problem (otherwise I'd suggest to add the additional step to
overwrite it with zero bytes).

However, even if this might work, it's a very ugly thing. Putting
things "at the end of the disk" in the age of virtualized and easily
resizable disks doesn't look very clever...

> I recommend backing up first, then setting up the target disk partitions 
> and bootcode: 
> Then use dump/restore to copy from the original:

That's the easier approach, as it makes sure that all GPT data is
going to be located at where it belings, but it involves more steps
than the desired "clone" (in _one_ step). 

> [...] or that it is one of the earlier FreeBSD versions 
> that did not boot at all if the secondary GPT table was not correct.

And _this_ is exactly where the oh so modern and comfortable GPT
is going to shoot users in the foot. ;-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list