Clone a FBSD system with something in the likes of ghost

[Jack L.]

have you tried gpart backup src|gpart restore target?

That's usually how I clone my partitions

On Mon, Oct 3, 2016 at 3:41 PM, Warren Block <wblock at wonkity.com> wrote:

> 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.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe
> @freebsd.org"
>