From owner-freebsd-hackers@freebsd.org Fri Dec 30 19:02:48 2016 Return-Path: Delivered-To: freebsd-hackers@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 17B9FC97C00 for ; Fri, 30 Dec 2016 19:02:48 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB2B914A8 for ; Fri, 30 Dec 2016 19:02:47 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 94ecd58e-cec2-11e6-8c89-112185c90658 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 94ecd58e-cec2-11e6-8c89-112185c90658; Fri, 30 Dec 2016 19:03:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBUJ2i5g001602; Fri, 30 Dec 2016 12:02:44 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1483124564.16152.85.camel@freebsd.org> Subject: Re: How to safely remove rest of GTP? From: Ian Lepore To: "Andrey V. Elsukov" , Slawa Olhovchenkov Cc: freebsd-hackers@freebsd.org Date: Fri, 30 Dec 2016 12:02:44 -0700 In-Reply-To: <071295b5-f7d8-d09b-13f9-416524a1f654@FreeBSD.org> References: <20161230124407.GN37118@zxy.spb.ru> <20161230164652.GO37118@zxy.spb.ru> <22d5dece-f14b-3bef-b3dd-8bb6226e0d28@FreeBSD.org> <1483119430.16152.83.camel@freebsd.org> <071295b5-f7d8-d09b-13f9-416524a1f654@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 19:02:48 -0000 On Fri, 2016-12-30 at 20:48 +0300, Andrey V. Elsukov wrote: > On 30.12.2016 20:37, Ian Lepore wrote: > > > > > > > > In case when you have not valid primary header, `gpart destroy` > > > will > > > not > > > touch first two sectors. In you case you can wipe only last > > > sector, > > > like > > > Ian suggested, but use 'gpart destroy -F da6' instead of dd. > > > > > If you gpart destroy -F da6 won't that also clear the valid MBR at > > the > > start of the disk?  I think Slawa needs to preserve that. > As I said, it will not touch first two sectors, where PMBR and > primary  > GPT headers are. > > > > > I think it would be really useful if gpart recover could help with > > this > > somehow.  There is a valid mbr, and a partially-valid gpt (only the > > backup is valid).  So gpart recover should provide a way to recover > > the > > gpt by refreshing the primary gpt and the pbmr, > `gpart recover` will restore GPT using information from backup > header  > and table and construct new PMBR. After that you need to write > bootcode  > if needed. > > > > > or recover the mbr by > > wiping the backup gpt. > This is what the patch does. You need to use `gpart destroy -F` to  > CORRUPTED GPT, this command will wipe last sector where GPT backup  > header is located. Since GPT is in CORRUPT state, the primary header  > will not be overwrited by this command. > > When both primary and backup headers and tables are valid, `gpart  > destroy` overwites PMBR, primary and backup headers. > > > > > I'm not sure what the syntax would be to > > specify that, though. > > > > This didn't used to be a problem until the changes that made the > > backup > > gpt get used automatically without any sysadmin intervention. > For some users the problem was that they could not find their GPT, > that  > declares its reliability. > Do you seriously believe that people are going to just do a gpart destroy -F on a device with a valid MBR as a method of preserving that mbr?  If that's the kind of thinking behind the gpart interface, I guess that helps explain why it's so nearly impossible to understand and use already. -- Ian