Clone a FBSD system with something in the likes of ghost
wblock at wonkity.com
Mon Oct 3 22:41:24 UTC 2016
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
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:
>> 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).
What you showed above wasn't one step, either. :)
Sometimes brute-force is fine. I prefer to save that as a last resort
>> [...] 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
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.
More information about the freebsd-questions