Date: Mon, 3 Oct 2016 16:41:17 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Polytropon <freebsd@edvax.de> Cc: "lokadamus@gmx.de" <lokadamus@gmx.de>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Clone a FBSD system with something in the likes of ghost Message-ID: <alpine.BSF.2.20.1610031632530.59114@wonkity.com> In-Reply-To: <20161003192218.51a7f402.freebsd@edvax.de> References: <CAHieY7TSESodQXBLoZkkBGWZaCbEZessqiMvzp9dR8Y1CoAZtw@mail.gmail.com> <57EC9527.7020202@rcn.com> <alpine.BSF.2.20.1609282305130.7457@wonkity.com> <CAHieY7QV3xYPsNxXdZrYCGO7SA37Mxn_yy2njByR2EBd9DzX9A@mail.gmail.com> <CAN2YBg6qUBXd8qy25zT5FNe9LkyY=x3po1H3UoD1Y2fDxrBvQw@mail.gmail.com> <c0c912ce-e859-4afb-76fc-cf06da97d848@gmx.de> <alpine.BSF.2.20.1610031043260.59114@wonkity.com> <20161003192218.51a7f402.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1610031632530.59114>