Re: Destroy GPT partition scheme absolutely, how?

On 09/26/2016 11:08, Gary Jennejohn wrote:
> On Mon, 26 Sep 2016 09:48:22 -0400
> Ernie Luzar <luzar722_at_gmail.com> 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