Talk:GUID Partition Table/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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)

Partition type GUIDs formatting error

The table at https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs starting at the end of the Linux section is misformatted / misaligned. I'd fix it, but don't know the authoritative information. Perhaps one of the experts can fix this.

—Wiki559 (talk) 19:04, 3 January 2017 (UTC)

Fixed
The row span for the cell containing "Linux" wasn't updated when two rows were deleted, so it was extending into the following section and displacing that. Fixed by subtracting 2 from the row span. Thanks!
—80.192.178.199 (talk) 03:35, 5 January 2017 (UTC)

Check my GPT

Hello. I tryed to check my GPT and may be my picture with color selectings will be helpfull thomebody else... <a href='https://postimg.org/image/d6ak6937h/' target='_blank'><img src='https://s14.postimg.org/d6ak6937h/GPT.jpg' border='0' alt='postimage'/></a> — Preceding unsigned comment added by 176.38.118.68 (talk) 22:03, 6 July 2017 (UTC)

Please note that Wikipedia is not a forum, and that these talk pages are for discussion of the development of the encyclopedia only. – voidxor 03:42, 8 July 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on GUID Partition Table. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:17, 9 October 2017 (UTC)

Endianness

This is a mess. Someone needs to go through all those GUIDs and check them. I can only check a few right now. To lay it out:

  • UUIDs, according to the RFC, are always written as hex integer ASCII strings (i.e. MSB first, the mathematical way)
  • the natural layout in memory would be exactly the same
  • some systems, such as Microsoft, and Intel who specified GPT, didn't feel like that and instead use mixed endian marshalling[1]
  • you can recognize the byte order a GUID was written in by checking its version field (most significant nibble in the third field, i.e. Vxxx) for a valid number. you'll notice that microsoft uses version 4 GUIDs. on-disk structures have that field in little endian, so the top four version bits sit like xxVx

Example: a "MS Reserved" partition (reserved for being turned into an EFI partition), has the bytes 16 E3 C9 E3 5C 0B B8 4D 81 7D F9 2D F0 02 15 AE on disk, but everyone agrees that the GUID is E3C9E316-0B5C-4DB8-817D-F92DF00215AE

So... #Partition_type_GUIDs has a footnote that explains this wrong. These GUIDs are written as specified. There's nothing little-endian about them.

I'll go ahead and fix this. My little explanation here because I know someone will need it.--Crackwitz (talk) 19:42, 21 January 2019 (UTC)

References

  1. ^ "Technical Note TN2166: Secrets of the GPT". Developer.Apple.com. Apple. 2006-11-06. Retrieved 2014-04-16.

Error in GPT disk layout figure

I have been trying to understand the GPT disk layout. From reading the UEFI spec and other pages, my impression is that the secondary (alternate) GPT header is located in the last addressable block on the disk. However, the figure (GUID Partition Table Scheme) is not consistent. The caption says that -1 is the last addressable block, but following the same graphical logic as used at the top of the figure the figure indicates that the secondary GPT header starts at -2 and ends at -1, i.e., it indicates that that the secondary GPT header is located at the second addressable block from the end, which should be wrong.

Am I right in this? Who has made the figure and how can we modify it?

this is indeed misleading. the backup GPT header is in the very last LBA. nothing follows it. The figure must be fixed. I'll see if I can fix it. --Crackwitz (talk) 20:10, 21 January 2019 (UTC)
I meditated on this briefly. The alignment of the text relative to the dashed lines can be misleading. It was probably intended to be relative to blocks. "LBA-1" is beside the last block. It's not meant to label the dashed line. --Crackwitz (talk) 20:12, 21 January 2019 (UTC)
I made some edits: https://gist.github.com/crackwitz/e492e43cbf28d4a3877fe6108f99e6fa (vertically aligned the labels, added/removed some labels, removed some dividers) If anyone knows how to replace/overwrite a file in here, feel free to do it.--Crackwitz (talk) 20:29, 21 January 2019 (UTC)
Nevermind, had to go to Wikimedia Commons to find the feature. It's done.--Crackwitz (talk) 20:34, 21 January 2019 (UTC)

Limitations vs MBR

I was wondering if perhaps this talk topic title should be an included section in the article? I know that "technically" GPT does not have any of the limitations that MBR does, but in certain instances a GPT-partitioned disk is not feasible. For example, some built-in Windows (7 thru 10) backup features do not support GPT disks. I can't quite remember for sure, but I seem to recall running into issues with restoring from a Win7 system image which was located on a GPT disk. I believe File History also does not support GPT disks. Just wondering what everyone's thoughts/experiences are.. thanks. -Jchap1590 (talk) 10:29, 5 November 2019 (UTC)

no one has anything to say, for or against, about this being mentioned in the article? -Jchap1590 (talk) 21:23, 21 November 2019 (UTC)

corrections

macOS does NOT support GPT: that is, it doesn't support any other OS on the integral drive (which is the purpose of GPT from the consumer's standpoint).

Win10 installer refuses to install on a GPT drive: Microsoft does NOT support GPT however it can read/write to them during runtime. Win10 does NOT support GPT.

Redhat Oracle installers do NOT support GPT unless to hoard it. I installed FreeBSD which insists on using GPT (my intuition said use 4-OS old way on my 1TB HD, but it was not allowed). I then tried intalling RH as a 2nd OS: the installer could not automatically or manually install, saying freeBSD was "where it wanted to be, it could not make room to install boot files". (instead of proceeding to install the HD image without boot, it simply refuses to anything but stall my time and insist on being the sole owner of the drive)

I SEE ABSOLUTELY 0 IMPOROVEMENT using GPT having EFI in my system as a consumer. I now cannot bithack my way into installing because installers "smartly prevent installation" ... which they seem to do whenever a competitor's system has already installed, demanding to be the first and only installed IMHO.

The "easily 4, always 4" partition scheme of the past never failed until modern installers began refusing to install if they must use it - yet also they are incapable of using the GPT they claim has "saved the end user": which they know is a big FAT lie.

You can say GPT has 0 todo with EFI or UEFI, but really it does because a GPT without any booting is not a possibility. You do have to boot. And it isn't really, as I said, booting USB that's the problem it is that installers refuse to install. Which? Win10, Redhat, Apple, FreeBSD, all conditionally where the other installed first. -- 4 May 2021 2601:143:480:a4c0:a483:d2b5:4a76:c6d5 talk

Hybrid MBR

My understanding of a hybrid MBR is a disk containing an EFI header alongside an MBR partition table, where both tables define partitions with the same position, size and type[1], allowing the disk to be used by EFI and MBR operating systems alike. It is non-standard, but just placing native boot code in the first bytes of the MBR while keeping the single protective partition does not make it "hybrid" as stated in the article. --Bachsau (talk) 🐗 18:29, 8 July 2021 (UTC)

References

  1. ^ https://www.rodsbooks.com/gdisk/hybrid.html

Forced to use this poorly designed "partition table" on large drives when you can't change to 4096-byte sectors. Complete joke.

Sickening. — Preceding unsigned comment added by 194.193.45.135 (talk) 09:31, 6 April 2022 (UTC)

Aralin Panlipunan

Tula tungkol sa pag-unlad 120.29.77.220 (talk) 09:37, 9 May 2023 (UTC)

undefined footnote

Wdpp, you recently added a couple dozen footnotes to this article ... all of which reference an undefined footnote named "dm-verity-signature". Are you able to provide a definition for thise footnote? What is it meant to say? -- Mikeblas (talk) 14:30, 8 October 2023 (UTC)

I'm sorry. It's a mistake. I will remove them. In the first draft, I wrote “Root varity signature partition (ARC){{Efn|name="dm-verity-signature"|used by dm-varity}}<ref name="DiscoverablePartitionsSpec" />”. Finally I changed it to "Root varity signature partition for dm-varity (ARC)<ref name="DiscoverablePartitionsSpec" />". But I forgot to remove the Efns. --Wdpp (talk) 14:55, 8 October 2023 (UTC)
I fixed it at Special:Permalink/1179196701. --Wdpp (talk) 15:07, 8 October 2023 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:GUID_Partition_Table/Archive_1&oldid=1214167549"