Re: SOLVED? - Re: Command line for creating partitions
thanks. I will study this a bit.
On 08/11/2014 09:41 PM, Chris Murphy wrote:
On Aug 10, 2014, at 5:47 PM, Robert Moskowitz
<rgm(a)htt-consult.com> wrote:
> Thanks for all the help. And I figured out another way when you want a real clean
card for dd of an image then xz for a compressed form for distribution. I did:
>
> dd if=/dev/zero of=/dev/sdb bs=1M
>
> and everything is gone.
Three critiques :-)
1. This doesn't remove the backup GPT, if present, which is at the end of the drive
in the last ~34 sectors.
2. It's definitely not reversible, so if you make a mistake (which you shouldn't
anyway of course), maybe one of your boots flips drive designations (which does happen and
is expected), you've just obliterated the wrong drive.
3. It doesn't remove filesystem signatures beyond 1MB, so they could remotely be
trouble down the road.
So I still like wipefs -a for each partition, then for the whole device, better.
> Built the partition table, the partitions, laid down the files, booted up clean,
then dd the image, xz compressed it and I now have a ice compressed image I can restore to
start at a clean point and can distribute to others.
Oooooh. Well, you will have latent sectors that previously had data on them that will be
vacuumed up with this dd image because it's a sector copy. So even unused sectors that
have latent data will find their data in your dd image and xz will be thwarted making it
as small (and private) as possible. Who knows what data is on those old latent sectors. So
now you can ignore everything else I suggested prior to this.
If SD card reacts to TRIM, which many do, you can:
a.) mkfs.btrfs /dev/sdX
b.) wipefs -a /dev/sdX
The default mkfs.btrfs behavior is a whole device TRIM, then it writes out a tiny amount
of metadata, much less than other filesystems. Using wipefs removes that btrfs signature,
and now you can build your media. On thing though is that SD card garbage collection might
take a while and depends a lot on its firmware. So in the short term the dd read of the
sdcard might still return latent data, until the firmware actually goes about erasing it.
Another option, is ATA security erase, but I don't know if SD cards support this. I
know the above will work because I've been doing it the past few days for other
testing.
Either way, the result is that there will be essentially no latent sector data, and your
dd image will contain piles of zeros that xz will then compress away.
Chris Murphy