From owner-freebsd-geom@FreeBSD.ORG Mon May 5 00:27:00 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1278A98A for ; Mon, 5 May 2014 00:27:00 +0000 (UTC) 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 A17C61280 for ; Mon, 5 May 2014 00:26:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s450QvGx009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 May 2014 18:26:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s450Qv21009697; Sun, 4 May 2014 18:26:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 4 May 2014 18:26:57 -0600 (MDT) From: Warren Block To: Andrew Berg Subject: Re: Recreating a GPT In-Reply-To: <5366DD86.8050005@my.hennepintech.edu> Message-ID: References: <5366CC63.4000001@my.hennepintech.edu> <5366DD86.8050005@my.hennepintech.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) 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]); Sun, 04 May 2014 18:26:58 -0600 (MDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:27:00 -0000 On Sun, 4 May 2014, Andrew Berg wrote: > On 2014.05.04 18:21, Warren Block wrote: >> It will take a while to copy the disk with dd(1), but that's really the >> only safe way. Make a copy, and write the partition tables to that. >> >> gpart(8) only writes to the partition tables or bootcode, and should be >> safe for the data in the partitions, but the only way to guarantee that >> is on a copy, not the original. > I've already cloned the entire thing to the scratch drive. I'd just rather > not rewrite it in its entirety again. How much of the disk will I need to > rewrite to get the partition table back to its original state if my attempts > are unsuccessful? IIRC, bits are written to the end of the disk as well, > so I'm not sure how to do it with dd(1), though I'm sure it can be done. One copy of the disk should be enough. Different partition offsets can be tried without having to copy the whole disk again. The backup GPT table at the end of the disk will be vacant after "gpart destroy", so rewriting it won't harm any actual data. GPT partition1 partition2 partition3 ... partitionN GPT-Backup 'gpart destroy -F' overwrote the GPT and the backup GPT. 'gpart create' and 'gpart add' only modify those also. Data in the partitions is not modified. >> gpart backup produces plain text that can be manually created. I'd >> still rather let gpart deal with the disk directly by using gpart create >> and add commands. > I'm under the assumption that 'gpart create' will do more than > 'gpart restore'; is that not correct? 'gpart restore' is just a single-step version of 'gpart create' and 'gpart add' for as many partitions as were on the original.