Talk:GUID Partition Table/Archive 1

Archive 1

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)

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)

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)

GPT boot support for Vista x64

About GPT boot support for Vista x64, "UEFI and Windows" [1] 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

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)

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)

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)

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. — Preceding unsigned comment added by 91.213.255.7 (talk) 23:09, 21 September 2011 (UTC)

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)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 — Preceding unsigned comment added by 115.248.50.21 (talk) 06:43, 29 September 2011 (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)

I think this is a very important topic. I've had a thorough reading of Chapter 5 of the UEFI specifications Version 2.3.1, Errata A. Most, if not all, hard disk drives today still utilize a LBA (logical block address) of 512-bytes, regardless of the physical size of the block due to most manufacturers implementing firmware to translate logical to physical addressing (despite the need to limit the number of blocks given the size of drives, currently at 6TB, and the address limitations of 32-bit partition tables).

According to Chapter 5 Section 3.1, paragraph 7, the following is stated:

If the block size is 512, the First Usable LBA must be greater than or equal to 34 (allowing 1 block for the Protective MBR, 1 block for the Partition Table Header, and 32 blocks for the GPT Partition Entry Array); if the logical block size is 4096, the First Useable LBA must be greater than or equal to 6 (allowing 1 block for the Protective MBR, 1 block for the GPT Header, and 4 blocks for the GPT Partition Entry Array).

Given this LBA size default of 512-bytes, is this a non-issue and the hard drive firmware avoids this problem or will there be mis-alignment of the GPT Header and GPT Partition Entry Array?

This hard drive firmware conversion creates a bit of confusion. Due to the firmware implementations, to avoid mis-alignment of a given partition, the First Usable LBA must be a multiple of 8 (or have a x mod 8 = 0 | x="First Sector of Partition n"). Hence, although the First Usable LBA is 34, it should be 40 given the current "Advanced Format" or long physical block size of 4096.

If one is to take the precaution of avoiding a potential mis-alignment of the GPT Header and GPT Partition Entry Array, then should not the First Usable LBA be 48?--Imwithid (talk) 16:27, 14 April 2012 (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)

This was addressed in mid-2011 in gdisk 0.7.2 and in patches to parted 3.0; however, the patches did not make it into parted 3.1, so it will only be when parted 3.2 is released that the new type code will be used by most Linux tools. The current state (7 November 2013) of the wiki describes this situation, albeit tersely. (User:srs5694 7 November 2013) —Preceding undated comment added 00:27, 8 November 2013 (UTC)

GPT Implementation: Linux vs. WIndows XP

There seems to be some difference in the way that Linux and Windows implements the GUID Partition Table. I've spend several days investigating why one OS cannot read the other's partition table.

Having formatted a new 3TB drive several different ways (using different interfaces: USB, eSATA), I find that Windows does not take well to sharing eSATA connected GPT formatted drives.

From my trials, Linux cannot read a drive formatted as a GPT disk via eSATA or USB through Windows XP x64.

If a drive is formatted via Linux (using gdisk and fixed using GParted), WIndows can fully utilize the drive but only through a USB interface (I have not been able to confirm Firewire). — Preceding unsigned comment added by Imwithid (talk • contribs) 17:06, 14 April 2012 (UTC)

Imwithid, your problem is most likely caused by differing handling of sector sizes between the OSes or between the hardware interfaces (especially if you use eSATA for one OS and USB for the other). I've seen this before. It doesn't really have much to do with this wikipedia article, though. (User:srs5694) —Preceding undated comment added 00:34, 8 November 2013 (UTC)

Exactly, as the USB interface exposes underlying hard drives in 4 KB "chunks", despite the fact there are no 4Kn drives yet. On the other side, eSATA exposes the true sectors, what means 512-byte "chunks". -- Dsimic (talk) 12:43, 8 November 2013 (UTC)

This isn't a reference manual

Sadly, for all the useful technical content here, the article presently contains so much random reference documentation that the {{manual}} tag which was so hastily removed needs to be reinstated. Wikipedia articles are not supposed to contain complete reference documentation; this should be left to external sources. Accordingly, the second half of the article either needs to be rewritten completely or deleted. The tag should be reinstated until that's taken place. Chris Cunningham (user:thumperward) (talk) 11:23, 14 March 2014 (UTC)

Sorry, but I really don't get it? Could you, please, explain in more detail which section is looking bad to you? That's what GPT is, harsh technical stuff, and replacing the actually useful content with some nice-looking prose (or even worse, deleting it) would just decrease the value of this article. Also, we shouldn't expect only Joe Averages as the readers of this article, so it should contain more of the associated "hard" stuff. — Dsimic (talk | contribs) 21:28, 15 March 2014 (UTC)

Additionally, if we take this article as containing "so much random reference documentation", then we can easily extend such classification to many more articles, including those describing various Intel microarchitectures, articles related to the MBR, UEFI etc. They all contain such stuff, and they're usable. — Dsimic (talk | contribs) 21:32, 15 March 2014 (UTC)

If you don't get it, then you should consult WP:NOTMANUAL. Wikipedia articles do not exist to teach subject matter: long lists of otherwise-uninteresting facts which serve no purpose other than as reference material have no place in articles. It is entirely possible to create accessible articles on deeply technical matters without having to include long lists of such data, and the first half of the article (although it defers too readily to tables rather than explanations) does a reasonable job at this. The rest is unnecessary to include here: Wikibooks would be a better fit. Chris Cunningham (user:thumperward) (talk) 13:23, 18 March 2014 (UTC)

Ok, thank you for the clarification, it all makes sense. However, there's still the question about which table(s) exactly do you find unacceptable? The only thing I'd do is moving GUID Partition Table § Partition type GUIDs section into a separate article, what would be inline with MOS:LIST – if you agree. — Dsimic (talk | contribs) 23:40, 18 March 2014 (UTC)

The OS support tables are massively overwrought; the Windows ones could be condensed into a couple of sentences of real prose, for instance. That applies broadly to most of the tables, in fact. Chris Cunningham (user:thumperward) (talk) 14:26, 20 March 2014 (UTC)

Yeah, that's always true for pretty much all tables, but again would the prose form be more usable? I'd really like if other editors could weigh in. — Dsimic (talk | contribs) 21:10, 20 March 2014 (UTC)

While there, please have a look at the Partition type article, or even Haswell (microarchitecture). The same story, but those articles are usable, if you agree. — Dsimic (talk | contribs) 21:37, 20 March 2014 (UTC)

Wow. The former is a complete horror show: the latter is sadly typical of our articles on processors and architectures. There are a great many well-developed and yet fundamentally broken articles on tehnical subjects on Wikipedia of course. Chris Cunningham (user:thumperward) (talk) 10:46, 21 March 2014 (UTC)

Right, Partition type article is really ugly, but still providing usable content; in my opinion, extracting Partition type § List of partition IDs section into a separate article would help a lot, while not requiring too much effort. Also, when looking at papers like this one, it's clearly understandable what the articles on processors and architectures could look like – at least to some extent. — Dsimic (talk | contribs) 20:15, 22 March 2014 (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)

25-30 years seems unlikely (if it was likely, this spec would be bad at inception). Please note that the difference between max "original" CHS-scheme (504MB) and 32-bit LBA (2TB); it's "only" roughly 4 thousand times larger. The difference between a 100MB ATA disk available in the early 90's and a 2TB disk common now (2013), is "only" 20 thousand times. The difference between 32-bit LBA and 64-bit is 4 billion. That is, 4 billion times more than two terabytes. Assuming we still have sector-based storage then, chances are it's 4KB-sectors or more, making it 32 billion times larger than 2TB. Just wanted to put into perspective how much 64 bits really is. 85.229.218.51 (talk) 17:57, 24 October 2013 (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)

Minimum is 128 as per UEFI spec, however, Microsoft Windows will not see latter partitions in a >128 entry-GPT. 178.245.175.141 (talk) 14:40, 9 November 2014 (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.[2] 142.150.48.191 (talk) 21:01, 10 March 2008 (UTC)

Error in GPT Entry Specification

According to the UEFI standards document v2.5 (April 2015) on page 123 states the following:

PartitionName Offset 56 Length 72 Null-terminated string containing a human-readable name of the partition.

Absolutely nothing is mentioned about unicode characters. Although unicode is mentioned elsewhere in the document (especially within the protocols), from what I read of this, if an operating system (most likely Windows in this case) is storing a string as unicode in this field, then it is possibly violating the standard.

Also, according to the document on page 11 and continuing onto page 12, the following is stated:

http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf : 1.8.1 Data Structure Descriptions Supported processors are “little endian” machines. This distinction means that the low-order byte of a multibyte data item in memory is at the lowest address, while the high-order byte is at the highest address. Some supported 64-bit processors may be configured for both “little endian” and “big endian” operation. All implementations designed to conform to this specification use “little endian” operation. In some memory layout descriptions, certain fields are marked reserved. Software must initialize such fields to zero and ignore them when read. On an update operation, software must preserve any reserved field.

This means that all fields use little endian byte order. This should be stated on the wiki somewhere, probably right before or after the header layout description table. Then the little endian markers can be removed from the entries that specify them.

1: http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf — Preceding unsigned comment added by 99.63.220.171 (talk) 22:11, 19 May 2015 (UTC)

Having difficulty understanding this article

I'm a novice at this stuff but have some understanding of it. I'm having trouble getting a foothold reading this article. Maybe I'm wrong, but I'm going to make a guess that you writer(s) here are more interested in various ramifications of GTP than in clarifying and explicating what it is and how it works. Is it that it's too simple and boring for some of you? It's the subject of this article, and if we readers already knew this stuff we wouldn't be looking it up. What do you think? lifeform (talk) 05:22, 31 May 2015 (UTC)

2-Byte Partition IDs

What about that simple Partition ID? There are still 2 bytes assigned with partition type. gdisk print output refer to it as "code". --Itu (talk) 17:56, 6 June 2015 (UTC)

OK, these codes are unique to gdisk, as man gdisk tells in the paragraph of command l. They are quite similar to the MBR partition types. --Itu (talk) 22:49, 7 June 2015 (UTC)

Legacy MBR (LBA 0)

I believe the last sentence in this section contains a mistake -- "Additional MBR partitions are then defined to correspond to the next three GPT[citation needed] partitions." This is contradictory. I think the author might have meant "next three primary MBR partitions", not "next three GPT partitions". If you read the entire paragraph, it starts off saying "...(which at the time of Boot Camp's creation did not support GPT or EFI)..." additionally by extension, how would it make sense to support exactly 3 GPT partitions? Whereas a standard MBR usually supports exactly 4 primary MBR paritions. -thanks to the authors though, this information is great for clarifying why there is so much trouble and lack of unified support for booting partitions. Roger Tiedemann (talk) 20:01, 12 July 2015 (UTC)

Intel Smart Response Technology GUID code

I've read that Intel SRT (formerly SSD Cache) uses GUID B8CB5058-C187-4719-BAF0-379CA2D4C97E. Source here: http://superuser.com/questions/427795/how-do-i-format-an-ssd-to-be-used-as-the-hibernation-drive-acer-s3 Since it's not a reliable source, I've held back from editing the article. But my laptop does it have alongside an Intel FFS (used for Rapid Start). I couldn't find a reliable source, sorry. — Preceding unsigned comment added by 201.37.134.212 (talk) 17:25, 27 June 2015 (UTC)

GUID b8cb5058-c187-4719-baf0-379ca2d4c97e is used by SanDisk express cache. — Preceding unsigned comment added by 68.71.70.211 (talk) 21:51, 1 November 2015 (UTC)

Partition attributes

In diskpart, partition attributes are represented by a 16-digit (not counting the initial "0x") value, not the 2-digit value. The 16-digit values are described here. Should this information be included in the article, or should it go somewhere else? ZFT (talk) 20:43, 24 March 2016 (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)

The mbr is small, but both gpt and mbr parsers can fit inside. That's what chameleon (the stage 0 of a hackintosh bootloader) does. I know it because I sent a patch to fix something related. I had a lot of problems making the patch because I needed 1 or more bytes, but it fits. Read "checkGPT" here [3] Of course you can bootchain other bootloaders and then read gpt, just wanted to point it out that it's already been done with only the mbr. Fernando Gutierrez (talk) 03:01, 25 March 2016 (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)

Another backup software, AOMEI Backupper also support backup GPT disk partition, I see from http://www.backup-utility.com/features/backup-gpt-disk-partition.html that write about "How to Backup GPT Disk Partition for Windows PC and Server?" — Preceding unsigned comment added by Doris2016003 (talk • contribs) 06:46, 30 March 2016 (UTC)