Date: Mon, 26 Sep 2016 15:01:09 +0200 From: "Hartmann, O." <ohartman@mail.zedat.fu-berlin.de> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Destroy GPT partition scheme absolutely, how? Message-ID: <20160926150109.0d0d793e@hermann>
next in thread | raw e-mail | index | archive | help
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, oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160926150109.0d0d793e>