Clone a FBSD system with something in the likes of ghost

[Warren Block]

On Mon, 3 Oct 2016, Polytropon wrote:

> 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?

Sure.  'gpart recover' does that, although it rebuilds the secondary 
table from the primary table rather than copying it.

> 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
>
> Tadaa!

It looks like a lot of work to do to use a tool that is not well suited 
for copying modern disks, though.

> 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...

Think about it for a bit, and you realize there are only two places on a 
disk that are known for any size of disk, the start and end.  If you put 
a partition table somewhere aribtrary between those, it breaks up the 
space for the user.  A backup copy of the partition table could be put 
next to the main one, but then both could get wiped out easily.

>> I recommend backing up first, then setting up the target disk partitions
>> and bootcode:
>> http://www.wonkity.com/~wblock/docs/html/disksetup.html
>>
>> Then use dump/restore to copy from the original:
>> http://www.wonkity.com/~wblock/docs/html/backup.html
>
> 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).

What you showed above wasn't one step, either. :)

Sometimes brute-force is fine.  I prefer to save that as a last resort 
for disks.

>> [...] 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. ;-)

There are BIOS implementations that will not boot unless the MBR is just 
right, either.

All of this is kind of implying there is sort of a fixed cost to doing 
many things, a "pay me now or pay me later" thing.