Re: Need for a unique Linux GPT GUID type code (PATCH included)

[Rod Smith]

On 06/23/2011 02:18 PM, Jim Meyering wrote:
> Rod Smith wrote:
> > Thus, it seems to me that Linux needs its own partition type code GUID
> > for filesystem partitions on GPT disks, much as it has its own MBR
> > partition type code for filesystems (0x83 on MBR). I'd like to
> > implement such a change in my own program, but I don't want to do this
> > unilaterally. Assuming there's no unusual protocol for creating
> > partition type code GUIDs, I suggest the following be used:
> >
> > 0FC63DAF-8483-4772-8E79-3D69D8477DE4
>
> Hi Rod,
>
> Thanks for bringing this up and for the patch.
> However, if we were to make such a change, wouldn't it make it
> so parted clients that then create say NTFS- or FAT-formatted
> partitions would find those partitions are no longer treated as
> well on window systems?

No. Any sane implementation (including my patch, although my testing has 
been limited) creates FAT and NTFS partitions with the Microsoft basic 
data partition type code. So long as the user specifies "ntfs" or one of 
the FAT codes for the FAT/NTFS partitions, it'll work. (OTOH, if the 
user selects "ext2" or some other filesystem as the partition's type in 
parted and then puts an NTFS or FAT filesystem on the partition, it 
won't work under Windows. That's user error, though, and the same 
limitation applies to MBR disks, so it's not exactly a new problem that 
will throw users for a loop.)

More broadly, the current parted code sets a GUID type code based on the 
filesystem type the user selects, and this code can be modified by 
setting partition "flags." My patch does two things:

- It creates a new GUID definition (PARTITION_LINUX_DATA_GUID, using
  the GUID in my first post). By itself, this does nothing; it just
  makes the type code available.

- It tells parted to use PARTITION_LINUX_DATA_GUID as the default
  type code, rather than PARTITION_BASIC_DATA_GUID, as it is now.
  This is done in two locations: Once when creating the partition
  data structure and once when setting the type code based on the
  filesystem type that the user enters.

The current (pre-patch) code actually explicitly sets the 
PARTITION_BASIC_DATA_GUID type on FAT and NTFS partitions, so I just 
left that alone. (I believe this code is superfluous in the pre-patch 
state, but it's necessary in my patched version.) Alternatively, the 
code could be further changed to keep PARTITION_BASIC_DATA_GUID as the 
default type code and set PARTITION_LINUX_DATA_GUID only when the user 
specifies a Linux filesystem, but as the range of Linux filesystems is 
so big and grows pretty rapidly, it's a bit simpler are less likely to 
malfunction in the future to do it the way I've patched it.

> This suggests that instead we might want to teach parted how to change a
> GPT partition type GUID to a new value.  Then, a higher level tool (like
> gparted) that knows the type of file system it has just created in a GPT
> partition can set the "type GUID" of that partition to something other
> than the basic data partition GUID when the FS type is not FAT or NTFS.

I agree that giving parted the ability to change GPT GUID type codes to 
arbitrary values is desirable; but it already sets type codes to any of 
a handful of common values, based on a combination of the filesystem 
type the user specifies and any flags that the user sets. Thus, I don't 
view the ability to set GPT GUID type codes as something that should be 
done INSTEAD OF creating an independent Linux-only type code; rather 
it's something that might be considered IN ADDITION TO creating such a code.

Getting back to my original point, currently both gparted and gdisk 
create Linux partitions that use the same GUID type code that Microsoft 
uses for its filesystems. The result is a potentially dangerous 
situation in Windows, since Windows is telling users that they "need to 
format the disk in drive X: before you can use it" whenever they 
double-click a Linux partition in the Windows "Computer" window or 
insert removable disk that uses GPT and a Linux filesystem. This danger 
can be eliminated by using a new GUID type code for Linux partitions. 
AFAIK, there's no standards body that issues GUIDs for such purpose, so 
it's basically up to the parted developers and me (as the author of 
gdisk) to agree on a new type code and begin using it. If we don't do 
that, then sooner or later users are going to start trashing their Linux 
partitions in Windows. Such accidents are becoming more likely as 
UEFI-based machines (on which Windows must use GPT) are becoming more 
common.

--
Rod Smith
address@hidden
http://www.rodsbooks.com