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 doneReceived on Mon Sep 26 2016 - 11:48:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC