A friend of mine used my USB stick to install a new version of OS X on his mac. Now that I got it back, I wanted to wipe it (I use Linux myself). However, I'm having a bit of trouble doing so. The first thing I did was write a Fedora LiveCD to it, using dd:
# dd if=Fedora.iso of=/dev/sdb
This, I thought, would overwrite the partition table which lies at the beginning of the device and consequently delete the partitions the OS X installer had created. However, I was wrong, the partitions were still there. So I looked up GUID partition tables and realized they add headers not only at the beginning of the device, but at the end, too. So I did:
$ sudo dd if=/dev/zero of=/dev/sdb
dd: writing to `/dev/sdb': No space left on device
15687681+0 records in
15687680+0 records out
8032092160 bytes (8.0 GB) copied, 1354.82 s, 5.9 MB/s
After this I removed the USB stick from the computer and plugged it back in. Running blkid now would yield no partitions on the device. However, after writing the Fedora image again, the OS X partitions are back:
$ sudo blkid
/dev/sdb1: LABEL="Fedora-17-x86_64-Live-Desktop.is" TYPE="iso9660"
/dev/sdb2: SEC_TYPE="msdos" LABEL="EFI" UUID="B368-CE08" TYPE="vfat"
/dev/sdb3: UUID="f92ff3eb-0250-303f-8030-7d063e302ccf" LABEL="Fedora 17" TYPE="hfsplus"
I suspect this has something to do with that Protective MBR bit in the wikipedia page above. How can I get rid of it?
Update
I ultimately ran parted and deleted the GPT from there. I did get spewed with warnings about a corrupted GPT (probably from zeroing it) but that "signatures" were there.
So I ultimately restored my USB stick, but it would still be nice if someone could shed some light on what exactly happened, where were those signatures stored?
dd if=/dev/zeroshould have overwritten it (and everything else). Did you check the state of the USB stick afterddbut before removing it from the computer? – StarNamer Aug 21 '12 at 10:41syncand made sure the little blue light on the stick wasn't flashing (I waited ~20 seconds). – Felix Aug 21 '12 at 13:49blkiduses a cache file/etc/blkid.tab. It may have been displaying cached values. To force a re-read you should usesudo blkid -c /dev/null. – StarNamer Aug 21 '12 at 16:15sudo sfdisk -d /dev/sdbor something similar to read the actual partition table on the device. – StarNamer Aug 21 '12 at 16:16fdiskon it and it displayed the extra partitions as well. – Felix Aug 21 '12 at 16:35