Date: Mon, 3 Oct 2016 19:22:18 +0200 From: Polytropon <freebsd@edvax.de> To: Warren Block <wblock@wonkity.com> 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: <20161003192218.51a7f402.freebsd@edvax.de> In-Reply-To: <alpine.BSF.2.20.1610031043260.59114@wonkity.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Tadaa! 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: > 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). > [...] 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. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161003192218.51a7f402.freebsd>