From owner-freebsd-questions@freebsd.org Wed Oct 5 00:27:26 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 9BF09AF6153 for ; Wed, 5 Oct 2016 00:27:26 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 602C9860 for ; Wed, 5 Oct 2016 00:27:26 +0000 (UTC) (envelope-from xxjack12xx@gmail.com) Received: by mail-it0-x230.google.com with SMTP id j69so166222608itb.0 for ; Tue, 04 Oct 2016 17:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q10NCAczhYaHNS/hsNvNcNTyUgOUwKtVpuPbIB/lncU=; b=RSWXNlcnmXN/uNlTGQMG+9sIhaH4jFbPai7wmj0g+IREZcGkx+BZxC4Sb31GLiVTkL 0JWKdxC++xoJkVchJNZfIonjKhBCvCzFgSOqpDT+WBXdaAcFpzCpCkADETMtEfsI+3Ah doXg+xbLRGaPPRab7UxYk12RwCiH503d1re+0kGPTxbSdD7P7QyT/s8XUMKn8o0fqJxV /ge0ZisUHIrg7/IVXJWiOgevOahrttinSOSJQGpg+KAAYrB2OK86oYwY90bbm9teSnjN IqLgntZFfgHXSiuQpAeW1TJ/j1bq2H0Lk0LdUUU8HuSArwxkBCFIqMYUj7jL/pCHjYO0 r7dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q10NCAczhYaHNS/hsNvNcNTyUgOUwKtVpuPbIB/lncU=; b=K4Ql8vOtKDq3+6/3hUI7WqmYLm03jEcPJP0XpLsnrNbkdZ5VNQIE8YgfhuTjcILHbK UdZh7GvPbftD8qAHuBPzp06f9U+r4EDsIhQu/B5E9sGuqLYM5m5TOxwoNaolAE7Qxbbk 21tXFbjtKu/WDmPTAHsbd012Nnu+T4KuY4YQSATUyAc3mIyiVD5TFftDyKdQQVUQIdKL K5VyCJLNLR3aZlgzwmvYVYNQerzSZ4GUHQ6ozaiLIxykjEK02KNJCkBZBE8wVI4qH1oh IZ4yp46RokpnxKpf39iwUqmNDn74Wpe/TF5kBT6O/Sc9UH80wV4Tx7Dmw+9bl1vOu813 tyqg== X-Gm-Message-State: AA6/9RmmzbmYePxhK6CLADSGoAw2/o1vWuiwPKUL9/Hsqrzf6LvOCdbMWBK/UeIowKyYjnIs5rb8e+WLY/1Hew== X-Received: by 10.36.142.196 with SMTP id h187mr6919695ite.108.1475627245688; Tue, 04 Oct 2016 17:27:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.87.140 with HTTP; Tue, 4 Oct 2016 17:26:45 -0700 (PDT) In-Reply-To: References: <57EC9527.7020202@rcn.com> <20161003192218.51a7f402.freebsd@edvax.de> From: "Jack L." Date: Tue, 4 Oct 2016 17:26:45 -0700 Message-ID: Subject: Re: Clone a FBSD system with something in the likes of ghost To: Warren Block Cc: Polytropon , "lokadamus@gmx.de" , FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Wed, 05 Oct 2016 00:27:26 -0000 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 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe > @freebsd.org" >