From owner-freebsd-questions@freebsd.org Mon Oct 3 22:41:24 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD2C8AF3D2A for ; Mon, 3 Oct 2016 22:41:24 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98EA2E95 for ; Mon, 3 Oct 2016 22:41:24 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u93MfIFH062145 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Oct 2016 16:41:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u93MfHO6062142; Mon, 3 Oct 2016 16:41:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 3 Oct 2016 16:41:17 -0600 (MDT) From: Warren Block To: Polytropon cc: "lokadamus@gmx.de" , FreeBSD Questions Subject: Re: Clone a FBSD system with something in the likes of ghost In-Reply-To: <20161003192218.51a7f402.freebsd@edvax.de> Message-ID: References: <57EC9527.7020202@rcn.com> <20161003192218.51a7f402.freebsd@edvax.de> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 03 Oct 2016 16:41:18 -0600 (MDT) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 22:41:24 -0000 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.