Using a USB key with a GPT partition table on Fedora results in corruption and renders partitions unmountable. OS reports errors with file systems, misidentifies file systems etc. Disk tools show that the GPT partition table has been damaged.

Note that I'm not at all certain which component of the OS is responsible. I am sorry but I only installed Fedora yesterday and am not yet familiar with it.


I have not attempted to reproduce this bug. Given that Fedora's installer seemed not at all happy about a GPT disk and installed Fedora but left it unbootable, and that I'd already lost what was on one USB key, I was not really inclined to test further. If the bug is not reproducible for you, let me know and I will deliberately try to reproduce it and provide further details of the conditions triggering it. 


Steps to Reproduce:
1. Insert a USB key. I used a machine running Arch.
2. Format a USB key using a GPT partition table. I used gdisk. 
3. Create a single, FAT 32 partition on the key. I used gdisk to make the partition and mkfs.msdos -F32 to write a file system to it.
4. Mount the partition. I used pmount.
5. Write some data to the key. I copied a public key generated by ssh-keygen. There was already an .iso on the key.
6. Unmount the partition and eject the key. I used pumount.
7. Mount the partition on a machine running Fedora 17. I used pmount.
8. I did not write anything to the key so I don't think this is necessary. I just catted the ssh key, directing the output to the appropriate file in ~/.ssh.
9. Unmount the partition. I used pumount.
10. Try to remount the partition on the original machine using pmount (as user); or mount -t vfat (as root).
11. Examine key with gdisk.
  
Actual results:

It is impossible to mount the partition again. The system complains of errors with the file system saying that it can only deal with fat 1 or 2, not 133. (I forget the exact wording of this message).

gdisk shows that the partition map has been damaged.

Expected results:

The OS should not damage the GPT partition map but should handle devices with GPT maps correctly. Failing this, it should refuse to mount partitions from the device at all and should tell the user that it cannot handle GPT devices without corrupting the table and causing loss of data.

Additional info:

Repeating the same procedure with a MBR partition map on the same USB key with, again, a single FAT 32 partition results in no errors.

Windows 7 and Arch Linux both handled the GPT partition map on the key fine. Windows XP does not but it simply refuses to recognise it - the data and partition map are not damaged and the key can be successfully used on a suitably configured machine without further interruption.