Re: Destroy GPT partition scheme absolutely, how?

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Tue, 27 Sep 2016 06:36:29 +0200
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
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

Thank you very much.
Received on Tue Sep 27 2016 - 02:36:37 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC