[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Need for a unique Linux GPT GUID type code (PATCH included)
From: |
Jim Meyering |
Subject: |
Re: Need for a unique Linux GPT GUID type code (PATCH included) |
Date: |
Thu, 23 Jun 2011 20:18:16 +0200 |
Rod Smith wrote:
> I've recently discovered that when Windows reads a GPT disk with Linux
> partitions on it, those partitions are given drive letters and show up
> as unformatted. This situation can happen with removable disks or when
> Linux and Windows dual-boot on a UEFI-based computer. Because UEFI is
> becoming more common, this situation is also becoming more
> common. This strikes me as a disaster waiting to happen; sooner or
> later, somebody is going to trash a Linux installation by opting to
> format a Linux partition in Windows.
>
> This problem occurs because Linux partitioning tools (libparted and my
> own GPT fdisk) give Linux partitions the same partition type code GUID
> used by Windows for its filesystem partitions
> (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7). Linux has its own GUID type
> codes for other partition types, such as RAID, LVM, and swap space.
>
> 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
>
> That's just a partition-unique GUID for a partition I created on a
> test disk using GNU Parted 3.0.
>
> Alternatively, we could use the existing "Linux reserved" partition
> type code (8DA63339-0007-60C0-C436-083AC8230908); however, I don't
> know who came up with that code or if it was intended for some
> specific purpose or even a general non-filesystem purpose. Lacking
> that knowledge, my inclination is to steer clear of that GUID.
>
> Of course, if somebody more needs to be involved in this, I'm happy to
> contact whoever it might be. AFAIK, the kernel doesn't use partition
> type codes, although some distributions' installers might.
>
> At the risk of jumping the gun, I'm attaching a patch to implement my
> suggestion in libparted. (I hope the attachment gets through; but
> Thunderbird is rewrapping it if I insert it inline.)
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?
In addition, there are a few tools that handle the BDP GUID specially:
https://codesearch.google.com/codesearch#search&q=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
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.