Where is the GUID Partition Table stored on a device?


Found the answer: the Fedora ISO contains a GUID Partition Table with a partition layout very similar to that of OS X. Because of this, I confused the partitions created by

dd if=Fedora.iso of=/dev/sdb

with the ones created by the OS X installer. The confusion was furthered by the fact that one of the partitions has a HFS+ filesystem, which is specific to OS X. What's even more curious is the fact that running parted after writing the ISO to the stick yields:

$ sudo parted /dev/sdb
GNU Parted 2.3
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Warning: /dev/sdb contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted --
possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?

Anyway, the point is that the partitions were not magically reinstated after zeroing the entire device, instead they were created when dd-ing the ISO.


Related videos on Youtube

Author by


I write code.

Updated on June 30, 2022


  • Felix
    Felix less than a minute

    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?


    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?

  • m-ric
    m-ric over 9 years
    I got your question, but I didn't get why your answer fits. E.g. "partitions were not magically reinstated after zeroing the entire device" is probably wrong. Did you try dd if=/dev/sdb of=sdb.img bs=4k count=10; hexdump -Cv sdb.img to check if GPT was there after zeroing de device?
  • Felix
    Felix over 9 years
    @m-ric no, but there's no way it could have been. The partitions of the OS X installer exactly matched those of the Fedora installer, which is why I got confused, and thought the partitions were coming back somehow. Now that I understood where they were coming from, I feel kinda stupid for thinking "they were coming back" in the first place :).