[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 (Chris Murphy)

From: Chris Murphy
Subject: Re: Need for a unique Linux GPT GUID type code (Chris Murphy)
Date: Mon, 17 Oct 2011 14:14:26 -0600

On Oct 17, 2011, at 10:14 AM, Rod Smith wrote:
> I can't speak to what's causing the delay, but if you want to implement that 
> GUID now, you can do so using GPT fdisk (gdisk; 
> http://www.rodsbooks.com/gdisk/). Use its "t" option to change the type code 
> to "8300" (gdisk's internal code for the new GUID). You'll need version 0.7.2 
> or later to support the new type code. I don't know offhand what Fedora 16 
> provides.

I'm using gdisk already to address some other (hopefully temporary) issues with 
the current Fedora beta post installation. I believe they are using parted, and 
are still setting the 'boot' flag on /boot partitions, even for GPT disks which 
causes the partition type GUID to change to the one for "EFI System" resulting 
in potentially more than one such partition on a disk. It also leaves the disk 
without a hybrid MBR, which prevents Fedora from booting on Apple hardware. 
gdisk makes creating a hybrid MBR and setting the boot flag in the MBR (not the 
GPT) quite straightforward.

Although gdisk is not included with Fedora, but is in the repo for download 
with yum, and currently is 0.7.2. So that's what I've been using to fix these 
issues. But it is parted that's used by many if not most distro installers and 
so that's where this problem primarily needs to be addressed.

I'm perplexed about the irony of a billion times a billion options available 
for a partition type GUID, and yet the choice apparently was to intentionally 
pick an existing one. Microsoft basic data. Under MBR there was better 
distinction, despite fewer available codes. There's nothing Microsoft or basic 
about ext2/3/4, btrfs, XFS, etc. 

I think instead of asking what are the hypothetical problems of changing to a 
linux specific GUID, the question is what is the advantage of claiming a 
partition used for linux is actually Microsoft basic data? Maybe it was 
intentionally chosen for a reason?

As a consequence, however, I'm seeing hybrid MBRs using 07 for linux 
filesystems instead of 83, because the hybrid MBR is being created based on the 
GPT's partition types, rather than from scratch. So this choice to use an 
existing partition type GUID for BDP, is causing a shift away from MBR code 83 
for linux filesystems to code 07. What problem is that going to cause?

Chris Murphy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]