From owner-freebsd-current@freebsd.org Mon Sep 26 15:28:18 2016 Return-Path: Delivered-To: freebsd-current@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 351C8BE3B04 for ; Mon, 26 Sep 2016 15:28:18 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 15BDFE96 for ; Mon, 26 Sep 2016 15:28:17 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from [127.0.0.1] (unknown [107.15.73.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 76AFB23941F for ; Mon, 26 Sep 2016 11:19:34 -0400 (EDT) Subject: Re: Destroy GPT partition scheme absolutely, how? To: freebsd-current@freebsd.org References: <20160926150109.0d0d793e@hermann> <57E92726.2020605@gmail.com> <20160926170803.698e5166@ernst.home> From: Nikolai Lifanov Message-ID: Date: Mon, 26 Sep 2016 11:19:24 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160926170803.698e5166@ernst.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:28:18 -0000 On 09/26/2016 11:08, Gary Jennejohn wrote: > On Mon, 26 Sep 2016 09:48:22 -0400 > Ernie Luzar wrote: > >> Hartmann, O. wrote: >>> I ran into a very nasty and time consuming problem. Creating a NanoBSD >>> image with a modified script framework creating GPT partitions, I put >>> the imaes via "dd(1)" on USB flash or SD flash. Because the images are >>> usually much smaller than the overall capacity of the USB or SD, the OS >>> (FreeBSD CURRENT, recently built as of this morning) complains about >>> the second GPT header isn't in the last LBA. Sometimes, my PCengines >>> APU2 doesn't boot then, a relief is to issue the command > > gpart recover da1 >>>> (in that case, the USB flash drive or SD flash is recognized >>> as /dev/da1). >>>> But I run into a nasty situation, if the image put to the flash is >>> somehow corrupted. Then I tried to write a second, repaired image over >>> the first one using dd(1) again and do a recovering as mentioned above >>> - but this is fatal in two ways. First, the corrupted/broken GPT seems >>> to be "recovered" and put in replacement of the correct one - so I >>> guess. Performing no recover leaves the image on flash corrupted >>> anyway. >>>> Well, to be honest, I didn't exactly know what is going on here. The >>> phenomenon is that I had a problem creating a NANO_DATASIZE= DATA >>> partition with an empty NANO_DATASIZE which somehow corrupted the >>> whole image. The image then never booted, complaining, >>> that /foo/bar/_.mnt was unmounted unleanly. >>>> This happened multiple times, even if I tried to overwrite the SD or >>> USB flash with /dev/zero or /dev/random data, but I do stop such a dd >>> after a couple f minutes, since the SD is 32GB in size and the USB >>> flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want >>> to write via USB 2.0. But even with overwriting with a good image then >>> results in a corrupt image on flash drive, complaining about the GPT >>> second header not in last LBA and the issue with the uncleanly >>> unmount _.mnt (from the creation process of the NanoBSD image)! > > So I guess there is something magic happening. Some informations are >>> not lost and I suspect the "recovery" moving those foul data into >>> active places. >>>> Using a fresh/new SD or USB resolves the problem. But the question >>> remains: how can I destroy any relevant GPT information on a Flash >>> drive (or even harddisk) to avoid unwanted remains of an foul image >>> installation? > > First guess was to write the last couple of bytes on such a flash drive >>> by letting dd(1) counting backwards, but I couldn't figure out how to >>> let dd(1) do such a procedure. The nightmare didn't end, while trying, >>> the SD flash card died :-( >>>> thank you very much for your help and thoughts. >>>> Kind regards, thanks in advance, >>>> >> This little script has been posted before. Maybe it will be what your looking for. Called gpart.nuke >> >> #! /bin/sh >> echo "What disk do you want" >> echo "to wipe? For example - da1 :" >> read disk >> echo "OK, in 10 seconds I will destroy all data on $disk!" >> echo "Press CTRL+C to abort!" >> sleep 10 >> diskinfo ${disk} | while read disk sectorsize size sectors other >> do >> # Delete MBR and partition table. >> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1 >> # Delete GEOM metadata. >> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` count=2 >> done >> > > I'm surprised that this script works without > sysctl kern.geom.debugflags=16 > You could just gpart destroy/create/destroy instead of doing arithmetic. - Nikolai Lifanov