Talk:GUID Partition Table

32-bit Windows and booting from UEFI with GPT

"Microsoft does not support EFI on 32-bit platforms, and by extension, does not allow booting from GPT partitions."

Isn't windows 8 going to have 32-bit UEFI+GPT support? If so it should be mentioned. — Preceding unsigned comment added by 58.178.195.203 (talk) 11:23, 8 July 2011 (UTC)

New version created by Scorpiuss

I've created a new version of the GPT page. The fundamentals are all there. Could use a chart of the things represented at each bit position. Microsoft's got a nice one on the external link indicated (which, by the way, is a great source).

-Scorpiuss, Aug 26 2005, 13:25 GMT

GUID Partition IDs

I just put a little collection of GUID partition type IDs in my talk page, but it lacks the UFS ones of FreeBSD and the HFS ones (OS X includes a the BSD's gpt partition tool, and creates HFS partitions by default, who knows why, as OS X uses Apple Partition Map and not GPT).

—Claunia 00:42, 27 August 2005 (UTC)

Put it yesterday in the article —Claunia 19:58, 27 August 2005 (UTC)

The future Intel-based Macs use GPT. Bo Lindbergh 18:34, 4 November 2005 (UTC)

Do you have any kind of confirmation? Please, post reference. —Claunia 11:13, 5 November 2005 (UTC)

Just a high-confidence guess.

• Universal Binary Programming Guidelines (PDF) says "The partition format of the disk on a Macintosh using an Intel microprocessor differs from that using a PowerPC microprocessor."
• The developer tools for Mac OS X 10.4 includes the header file /System/Library/Frameworks/IOKit.framework/Versions/A/Headers/storage/IOGUIDPartitionScheme.h which wasn't there in 10.3.

Bo Lindbergh 15:04, 9 November 2005 (UTC)

Yes but that is only a speculation.

Windows 2003 and XP can both use GPT under x86 and x86-64, but they don't boot from it.

MacOS X 10.4 recognizes, formats (command-line), and can use GPT disks, but don't boot from it.

There are also rumours that Apple is questioning between using BIOS or EFI in their new machines.

—Claunia 16:27, 9 November 2005 (UTC)

EFI System partition GUID contradiction

The GUID for an EFISys partition under the Partition Entries section is different than the one in the list of GUIDs. On the MS page linked at the bottom, the one given in the Partition Entries section is given.

-Scorpiuss

GPT Windows only?

I'm reading this article, very interesting and all, but then I read, 'only 64bit Windows' and later '64 bit Windows 2003 Server'. I'm sure other operating systems will use GPT disks, like linux, as they have GUID entries? Shouldn't this be changed to '64bit OS'?

No. GPT doesn't need 64bit OS at all. I use GPT on 32 bit system without any problem at all. 64 bit OS/CPU and fact that GPT entries uses 64-bit LBA are completely independent. Also 32-bit Windowses could work GPT but for some obscure reasons Microsoft choose to not make this happen (there may be some small technical problems with Windows limitations, but I guess it is rather a marketing and way to force people to buy and use 64bit Windows OS). --91.213.255.7 (talk) 23:00, 21 September 2011 (UTC)

Questions

With that in mind, what is the status of GPT? I'd expect more info about this here, is it a standard allready? Do operation systems support it? Windows? Linux? (Will older OS's support it? will it only work on 64 bit and not 32 bit and why?) Could I convert and start using GPT now on my old linux pc?

Also, what happend to primary/logical partitions. Is it safe to assume we simply have up to 128 partitions. No more worring about primaries, secondaries and bootables?

GPT is part of the EFI specification, which seems to have been accepted as an

industry standard.

The leagacy PC BIOS doesn't have the ability to boot off of a GPT partitioned disk.

However, you could use GPT to partition disks that are not booted from, as Linux

(with GPT enabled, on any platform) and some newer (most, if not all 64-bit)

Microsoft OSes understand GPT. However, the GPT method of partitioning is not

as widely supported as MBR.

GPT is a new, improved way to divide disks into partitions; redesigned almost from

scratch. GPT does not need to diferentiate between the ways a partition could be

defined, as with GPT there is only one way.

"8 bytes - First LBA (little-endian)". 8 bytes, not 16! IOW, only 2^64 max. Ahhhahahahahaha... these guys never learn. "640k will be enough for anyone" again. Never mind that we _just_ discovered that 2^32 sectors is not as huge as we thought... let's emplace a new banana around next corner. 90.176.40.79 (talk) 00:50, 16 September 2009 (UTC)

There's no point in crying over the address of the first available LBA. On GPT partitioned disks it is going to be 2 in almost every case (you want to start using the disk from the very start - no point in leaving the first xx TB empty :-) ). There's also no point in complaining about the max. address of the last LBA being only 8 bytes because the entire GPT is built around 8 byte values so bumping one to 16 bytes would be pointless (e.g. one wouldn't be able to make partitions passed LBA #2^64). By the time we get to exhaust the 64bit space we'll bump it to 128bits. I think it will take us about 25-30 years to get there based on how long it took us to exhaust the 32bit space in MBR. 174.6.87.98 (talk) 10:39, 20 June 2010 (UTC)

128 partitions is just a Microsoft default, it seems the minimum would be 0 (although

that's not really useful), and the maximum limited only by the 32-bit number used to

define how many entries are in the partition table and the space needed to store the

table.

Jakllsch 04:18, 5 May 2006 (UTC)

As far as booting from GPT goes, you DO NOT need EFI to do it. HP already has an implementation that can boot GPT volumes from good old BIOS.[1] 142.150.48.191 (talk) 21:01, 10 March 2008 (UTC)

"the same GUID for their respective data partitions"

What's with the comment Note: Linux and Windows use the same GUID for their respective data partitions? From the table, the GUIDs look quite different... --moof 02:51, 29 July 2006 (UTC)

Look closer.

--Jakllsch 21:51, 1 August 2006 (UTC)

There is something fundamentally wrong with the idea of two different systems using the same "Globally Unique" ID, since it is no longer unique then. I think this article should mention something about how this could happen, and who allocates these not-so-globally-unique IDs. Zuiram 17:54, 13 October 2006 (UTC)

Well, if my disk contains "just some data" (say, my movie collection), it is natural to have it marked as such in both Windows and Linux. 90.176.40.79 (talk) 00:46, 16 September 2009 (UTC)

OS and utility support ?

Which operating systems support GPT ? What tools exist that can work with GPT (like partitioners, backup utils, etc...; I know parted supports it, at least they claim so)

--Xerces8 (talk) 12:00, 17 November 2007 (UTC)

dito. even 2 years later it seems that there is no (backup) utility that supports hard discs with GUID partition tables. does anyone know some? —Preceding unsigned comment added by 78.51.115.149 (talk) 18:43, 1 July 2009 (UTC)

Re Backup, I see from http://kb.acronis.com/content/6533 that "Support of dynamic disks and disks with GUID Partition Tables (GPT) is available in Acronis True Image Home 2010 Plus Pack." Whether it's appropriate to add a Tools section to the article I leave to others to decide. -- dww —Preceding unsigned comment added by 86.9.90.50 (talk) 16:36, 29 December 2009 (UTC)

ZFS GUID

ZFS on Mac OS X uses the same GUID as the /usr partition on Solaris. I couldn't find any external sources for it, but the following command will reveal the descriptors for ZFS when executed on a Mac running Mac OS X 10.5. I have the ZFS developer preview installed, but that shouldn't matter.

% grep -A1 FSFormatContentMask /System/Library/Filesystems/zfs.fs/Contents/Info.plist
			<key>FSFormatContentMask</key>
			<string>6A898CC3-1DD2-11B2-99A6-080020736631</string>

--DanChr (talk) 04:30, 19 November 2007 (UTC)

What about hex?

Why not giving offsets for the pieces of the GPT-field in both decimal and hex?

78.53.226.102 (talk) 14:01, 11 August 2009 (UTC) Jochen

About GPT Format Specification

I think there is a mistake in GPT Format section

I did a lot experiment in GPT(because I lost all of my partitions in my GPT disk...) and I found something (all experiment is done under windows environment)

Header CRC in offset 16(0x10) is not "0 to Header Size" and should be "0 to Partition Array CRC"(that means 0x0 to 0x5B or say offset 0 to 91, total 92bytes) and with this field zeroed during calculation.

Should I edit this section? —Preceding unsigned comment added by Pig1800 (talk • contribs) 14:24, 8 October 2009 (UTC)

Maximum GPT Drive Size

This article confuses me where it appears to say that the maximum partition size is 2 Terabytes. (BTW - is "Terabytes" misspelled in the legacy partition section??)

This is not clear - does this mean that the maximum size of a "msdos" (legacy) partition is 2T, or the maximum size of a GPT partition is 2T. This is not a trivial distinction - I am currently trying to partition and format a single 2T hard drive in Fedora 10 - and I am running into all kinds of subtle issues.

If the maximum size for a legacy partition is 2T - that's one thing - and I'd really like to know what the maximum size for a GPT partition is too.

If the maximum size for a GPT partition is 2T - that's a horse of an entirely different hue.

IMHO this is important and should be clarified. Thanks! Jharris1993 (talk) 01:03, 22 October 2009 (UTC)

For MBR limits, see Master_boot_record. If your drive is Linux-only, and you don't need to share it with Windows, then probably you don't need a MBR at all -- you could impose a BSD-style "label", or whatever your software supports... AnonMoos (talk) 12:56, 30 December 2009 (UTC)

I have added information and references on the maximum disk and partition sizes for GPT which are both 9.4 zetabytes (a zettabyte is a billion terabytes). --GrandDrake (talk) 03:57, 10 June 2010 (UTC)

Larger sectors

As a random reader passing by, i could not understand what this paragraph had to do with the rest of the article: "According to Apple,[2] "Do not assume that the block size is always going to be 512 bytes." Modern storage devices such as solid-state drives may contain 1024-byte LBAs and some magneto-optical (MO) drives use 2048-byte sectors (but MO drives are typically not partitioned). Hard disk manufacturers are planning to transition to 4096-byte sectors, but as of early 2010, the first such drives employ firmware that presents the illusion of 512-byte sectors to the OS. [3]"

I can see how it would affect the maximum partition size, or the amount of data reserved by windows mentioned in the paragraph above it - but i can't really figure out what it's supposed to contribute to the article. Thulle (talk) 23:06, 14 January 2010 (UTC)

Styling/Formating issues

{{helpme}} Presently, I am having some trouble trying to separate "Partition type GUIDs" table into two floating tables so that wide screens can see it in two columns, however I have no idea on how to put up a containing div over them (floating them works but breaks the following text) and html don't work (rather I do not know how to embed it). 216.66.134.2 (talk) 02:23, 28 January 2010 (UTC)

Answered at your talkpage. (See WP:VPT) —DoRD (?) (talk) 05:06, 28 January 2010 (UTC)

Where's the boot code for BIOS?

If GPT is used on a system without EFI firmware (e.g. because the disk is larger than 2 TiB), then where is the boot code in this scheme? The first part must of course be in the MBR in block 0, but I assume that space there is too limited to hold all of it. There has to be code somewhere on the disk that parses the GPT and hands control to an OS boot loader. Please add this info. -- 92.229.113.235 (talk) 19:26, 29 March 2010 (UTC)

I'm not sure if I understand your question. GPT is a partition mapping schema based around GUIDs. It doesn't really pertain to boot code. Part of the EFI spec shows that there's a 'special' 200MB partition - the EFI System partition- that's used to contain bootcode and patches, etc to allow the machine to snag the kernel. However, the protocols used to handle the filesystem and blockIO, etc are already contained in the EFI bootROM and I'm guessing the non-EFI-based system won't be smart enough to store bootcode in the EFI system partition. BTW - found this patent while digging around ... - Alison ^❤ 02:19, 30 March 2010 (UTC)

The bootcode can be anywhere the code in the MBR tells him it is :-) Just like when booting MBR-based disks with advanced bootloaders. Bootloaders usually have a map of LBA addresses where their next stage is. This stage deals with menus and jumping to LBA holding bootsector of a chosen OS. The bootloader must know how to interpret GPT in order to determine the correct LBA to boot all OS in the menu. Have a look at GNU GRUB and its online manual. 174.6.87.98 (talk) 10:22, 20 June 2010 (UTC)

Sorry, wrong version of the manual. The correct one for the latest GRUB is here. GRUB website also talks about where its second stage is located and how it's found. Quite an interesting reading. They can use either a map of LBA sectors as I mentioned above (which they discourage - see below) or the 31KB continuous area after MBR (the traditionally empty sectors 1-63 between MBR and the start of the first FAT partition) or in the case of GPT where there's almost no limit on the number of partition entries in the table and where there's no reason to hold back creating or declaring new partitions GRUB creates its own partition of type "bios_grub" where it places its second stage. This way it's not a part of other filesystems and its blocks can't be shuffled around without its knowledge requiring following reinstallation because of a change in LBA blocks map. 174.6.87.98 (talk) 09:25, 22 June 2010 (UTC)

More on so-called "bios_grub" partition can be found here on Wikipedia in BIOS Boot partition article.

Correction: "empty sectors 1-63" should read "normally unused sectors 2-63". My apologies.

174.6.87.98 (talk) 04:03, 12 July 2010 (UTC)

Split for Table: OS support of GPT

I think the table in this section should be split up into 3 distinct ones - x86, x86-64/EM64T and ia64 (Itanium) - this should improve general readability and sort things out as operating system support seems to be very processor dependent, especially when it comes to the windows history. --Alexander.stohr (talk) 21:09, 14 April 2010 (UTC)

I do not thing this is good idea. GPT is supported independent of CPU architecture. True, some OSes runs only on some architectures, and will only support some file systems on GPT, but generally they will always allow to access underlaying data even if particular OS doesn't understand file system.

GPT boot support for Vista x64

About GPT boot support for Vista x64, "UEFI and Windows" [2] says Vista x64 RTM does not support UEFI. Therefore, Vista x64 RTM seems not bootable from GPT on EFI. Vista x64 SP1 seems bootable.--125.201.187.3 (talk) 19:08, 7 May 2010 (UTC)

Run-On sentence should be rewritten

The following sentence begins the Windows GPT Support section. I propose that it qualifies as a run-on sentence and should be replaced.

There is a problem documented for earlier 32-bit Windows versions that hard disks with more than 2 TB of space and GPT partitioning moved to that platform from e.g. a 64-bit Windows Server machine were not handled correctly in a fashion that any data that got written beyond those limits got wrapped around and appeared in the beginning of the harddisk thus destroying user data, file system structures and even the harddisk formatting information.

I might forward a suggested replacement of,

Hard disks greater than 2TB in size and partitioned with GPT, when moved from e.g. a 64-bit Windows Server to a 32-bit windows version, are reportedly handled incorrectly. Writes beyond the 2TB limit would wrap and be written to the beginning of the disk, overwriting user data, file system structures, and even partitioning information.

This version is superior, I believe, because it clarifies the meaning of the statement, breaks it into 2 more easily digestible chunks, and simplifies a number of unnecessarily complicated phrasings.

However, since no source is cited, and I can't verify the validity of the statement or my interpretation, I don't feel comfortable making the change unilaterally.

76.113.215.212 (talk) 15:56, 22 May 2010 (UTC) Dan F

Byte swapping endianess

Near the end it is stated only the first 3 parts of the GUID are byte swapped. This doesn't make sense to me at all, is the system some how little endian for the first 3 parts and big endian for the last part? Can this be clarified? —Preceding unsigned comment added by Freaky2000 (talk • contribs) 12:09, 6 July 2010 (UTC)

32-bit Windows and booting from EFI contradiction

There seems to be a contradiction in the "Windows 32-bit versions" section: "Microsoft does not support EFI on 32-bit platforms, and by extension, does not allow booting from GPT partitions." Which is followed by a table that indicates that "Boot from GPT on EFI" is possible for 32-bit Vista, 2008 and 7. So, which is it? Torrentss (talk) 15:54, 25 March 2011 (UTC)