Wikipedia - Benutzerbeiträge [de]

Diskussion:GUID Partition Table

2024-12-27T19:45:12Z

Michalsc: /* Partitionstyp (GUID) von AmigaOS */ Antwort

== Abschnitt GUIDs und deren Zuordnung ==
Auf was bezieht sich die Tabelle unter der Überschrift "GUIDs und deren Zuordnung".

Ansonsten: Toller Artikel, hoffentlich wird er nicht wegen Irrelevanz gelöscht :-/

:Diese GUIDs sind eine Zuordnung zu einem Betriebssystem u.ä., genauso wie der Partitionstyp in einer [[Partitionstabelle]]. --[[Benutzer:Kvedulv|Kvedulv]] 16:02, 6. Nov. 2007 (CET)

:: Die Frage war wohl so gemeint, dass eine verbindliche Quellenangabe fehlt. Wer definiert die GUIDs, gibt es eine zentrale Registrierungsstelle, und woher bekomme ich die aktuelle Liste? --[[Benutzer:RolandIllig|RolandIllig]] 12:43, 20. Dez. 2007 (CET)

::: Es gibt keine zentrale Registrierungsstelle, das ist ja der Gag an [[GUID]]s / [[UUID]]s. Eine aktuelle Liste ist auch schwierig, da ja jeder Hanswurst eigene GUIDs benutzen kann. Du kannst nur die Hersteller, deren Dateisysteme/Partitionstypen du unterstützen willst/musst, abklappern und fragen, ob sie dir ihre benutzten GUIDs sagen. Mag sein, dass es im Internet von Freiwilligen zusammengestellte Listen gibt, aber normativ sind die sicher nicht. --[[Benutzer:RokerHRO|RokerHRO]] 23:15, 9. Apr. 2008 (CEST)

== Treiberfehler? ==

Zu dem Satz: ''Leider scheint sich auch das Treiberproblem bei der 2-TB-Grenze bei Festplatten größer 2 TB, wie bereits bei 128 GB, zu wiederholen[1] bei dem Daten in den ersten 2 TB überschrieben werden wenn auf einem Bereich über 2 TB geschrieben wird.''
Ich finde das etwas verwirrend: ist es wirklich so, dass aktuell beim Schreiben hinter 2 TiB, Daten vor 2 TiB auf einer größeren Partition gelöscht werden? Und auf welchen Betriebssystemen ist dies der Fall? An ein 128-GiB-Treiberproblem kann ich mich nicht erinnern. Die Quellenangabe ist zwar schön, aber da die c't den besagten Artikel nicht im WWW frei veröffentlicht hat und ich keine Ahnung habe, wie ich an die Zeitschrift kommen soll, stehe ich jetzt ziemlich verunsichert da. kann jemand, der die zeitschrift hat, vielleicht etwas mehr dazu sagen? --[[Benutzer:SvenEric|SvenEric]] 01:16, 29. Jan. 2009 (CET)

:In besagtem Artikel wurde eine 4-Terabyte-Festplatte getestet. Da ist aufgefallen, dass unter bestimmten SATA-Controllern von Intel, AMD und JMicron die Kapazität zu niedrig angegeben wurde (nämlich nur 2 Terabyte). Hatte man die Platte aber schon mit einem besser funktionierenden Controller formatiert, hat Vista die Größe der Partitionstabelle entnommen und damit wieder korrekt angegeben -- und in diesem Fall haben dann die fehlerhaften Treiber nach der 2-Terabyte-Grenze wieder von vorne angefangen. (siehe [[Ganzzahlüberlauf]])Zur 128-Gigabyte-Grenze steht im Artikel nur: ''Genauso verhielt es sich seinerzeit, als die Festplatten die 128-GByte-Grenze überschritten und alte Treiber die neue Adressierungsart noch nicht beherrschten''. --[[Benutzer:Felino|Felino]] 17:24, 5. Feb. 2009 (CET)

:Was ich an anderer Stelle (z.B. engl. Wikipedia) gelesen habe war es sehr wohl möglich schon mit DOS-Partitionen über die 2 TB hinaus zu kommen, wenn nur der erste Sektor noch unterhalb lag. Also kein sogenannter "Wrap-Around" (dt. Umbruch), der natürlich fatal wäre. Mag sein manche Treiber von den Platten oder Controllern hatten da wirklich ein Problem - es gibt da aber wohl einen Stand 1 der GPT-Implementierung unter den diversen Windows-Versionen der wohl echt bei 2 TB ein harte Grenze zog (ohne dass es technisch nötig gewesen wäre) und dann doch so um 2006/7 ein Patch raus kam, mit dem üblichen KB-Prefix und ner 8-stelligen Nummer, der im Betriebssystem alle Weichen auf "GO" stellte um diese Barriere mal wieder hinweg zu räumen. Im übrigen - Microsoft hat die Server-Systeme als erstes dafür flott gemacht weil die natürlich Terabytes als erstes benötigen, und dann die Workstation-Varianten teilweise ebenso. Endanwender/Heimnutzer haben davon bis heute nur ganz indirekt wirklich was gehört oder gar einen Vorteil (das mag sich im Lauf der nächsten Jahre leicht verändern). Im übrigen geht mir der Artikel zu wenig auf die Details der XP-Varianten ein, und insbesondere die x86 (cpu: x86-64/EM64T) aber auch x86 (i386/i586) haben durchaus eine diesbezügliche Support-Historie die erwähnt werden sollte. --[[Benutzer:Alexander.stohr|Alexander.stohr]] 16:08, 17. Apr. 2010 (CEST)

== Sektor-Größe ==

In dem Text wird an mehreren Stellen expliziet oder impliziet von 512 Byte großen Sektoren ausgegangen. Dies ist aber nicht zwangsläufig gegeben. Wie verhält sich das ganze den z.B. bei 4kByte großen Sektoren? Hat man dann mehr Partitionseinträge (weil die Tabelle imer noch 32 Sektoren groß ist) oder wird dann die Tabelle kleiner (nur noch 4 Sektoren mit insgesammt 128 Einträgen) oder werden von jedem Sektor nur die ersten 512 Bytes benutzt (was natürlich nicht sehr sinnvoll wäre)? Es müsste klar bschrieben werden wie das GPT-Konzept von unterschiedlichen Sektorgrößen beeinflusst wird. --[[Spezial:Beiträge/217.110.99.237|217.110.99.237]] 13:53, 27. Mai 2010 (CEST)

:Die EFI/UEFI Spezifikation spricht nicht von 32 Sektoren, sondern einer Mindestgrösse von 16 KiB die für Partitionseinträge zu reservieren sei. Bei Datenträgern mit 512er Sektoren ergibt das die besagten 32, bei grösseren entsprechend weniger. Es bleibt in jedem Fall bei mindestens 128 möglichen Einträgen. Nicht zu vernachlässigen: Das sind ausdrücklich nur Mindestwerte, man kann nach Belieben auch mehr Platz und damit auch mehr mögliche Partitionen konfigurieren. (Allerdings sind nicht alle im Umlauf befindlichen Werkzeuge darauf tatsächlich auch vorbereitet.)
: (''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/2.208.95.60|2.208.95.60]] ([[Benutzer Diskussion:2.208.95.60|Diskussion]])<nowiki/> 16:43, 14. Apr. 2012 (CEST)) 

== GPT-Verwendung win32 ==

''Die normalen, abwärtskompatiblen Versionen von Microsoft Windows XP, die noch für die 32 Bit-i386-Architektur entwickelt wurden, können auf einer GPT-Festplatte nur mit Einschränkungen installiert werden. Unter anderem benutzen sie nur den Master Boot Record (MBR), um Partitionierungsdaten zu erhalten. Es stehen so nur maximal drei Partitionen zur Verfügung, da der MBR nicht mehr als vier Einträge zulässt, die erste Partition für die EFI-Firmware reserviert ist und erweiterte Partitionen, die mehrere logische Partitionen enthalten konnten, von GPT nicht mehr unterstützt werden.''

:Ähm, zuerst wird von "GPT-Verwendung durch Win32" gesprochen, dann aber nur noch von MBR-Verwendung. Wie ist denn nun der Zusammenhang?
:Ich dichte mir das mal zusammen: Es gibt auf der Platte den alten MBR, der jetzt '''kein''' „protectiv MBR“ mehr ist, sondern (maximal) 4 reale Eintrage (alles "primäre Partitionen") enthält. Diese stimmen auf die exakte Blocknummer mit (gleich vielen) 4 Partitionen überein, die auch in der (nachfolgenden) GPT angelegt sind. Und das Win32-System benutzt die GPT überhaupt nicht, sondern einfach den MBR.
:Damit bleibt die GPT also gänzlich unbeachtet, und keiner ihrer Vorteile (z.B. >2TB Platten) kommt zum Tragen. (Bestenfalls die Wiederherstellbarkeit bei futschem MBR mittels Spezialsoftware, welche die GPT ''tatsächlich'' verwendet.)
:Die Partition für EFI-Firmware ist übrigens unnütz, GPT hat mit EFI grundsätzlich erst mal nichts zu tun (außer, dass es im EFI-Dokument mitbeschrieben ist. (Siehe c't 4/2011 S.170: Linux kann GPT verwenden und davon booten, ganz ohne (U)EFI.))
: --[[Benutzer:Arilou|arilou]] 15:43, 9. Feb. 2011 (CET)

Soweit ich weiß, ist es bei Apple-Notebooks so: Mac OS X verwendet nur EFI. Um Windows XP (32-Bit) installieren zu können wird mittels Bootcamp-Assistent die HFS-Partiton (von Mac OS X) im Betrieb verkleinert und danach eine FAT-Partition erstellt (diese kann dann unter Windows als NTFS formatiert werden). Unter Windows XP sieht das dann so aus: Erst eine geschützte EFI-Partition (manche Tools erkennen verstecktes FAT, ist aber EFI), danach die HFS-MAC-Partition, danach eine notwendige Lücke und dann die Windows-Partition. Alles primäre Partitionen. Windows erkennt einen Standard-MBR mit drei primären Partitionen, Mac eine EFI-Platte mit drei identischen EFI-Partitionen. Aber versuch bloß nicht unter Windows die Partitionen im MBR zu verändern, beim nächsten Start wird wieder EFI ausgelesen und alles ist durcheinander!
Dann lieber ein Backup von Windows machen, dieses löschen, das ganze unter laufendem Mac OS neu partitionieren und Windows neu installieren. [[Benutzer:J-g-s|J-g-s]] 13:44, 14. Dez. 2011 (CET)

== Deutsch oder Englisch? Entscheidet euch bitte! ==

Die Tabellen sind alle in einem merkwürdigen Denglish verfasst, mit Deppenleerzeichen zuhauf, deutscher Großschreibung, größtenteils englischen Wörtern und englischer Grammatik.

Entscheidet euch mal bitte. Wir (die ganze Welt) wissen, dass ihr noch immer zwanghaft meint euch für eure Kultur und Sprache schämen zu müssen, weil sonst wieder ein Extremist von der anderen Seite „Da! Nazis!“ schreien würde. Aber so langsam ist mal gut. (''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/88.77.134.93|88.77.134.93]] ([[Benutzer Diskussion:88.77.134.93|Diskussion]]) 09:45, 3. Jan. 2012 (CET)) 

== wofür ist datt ==

Ich vermisse in dem Artikel Gründe weshalb man nicht beim (alten) MBR bleibt sondern jetzt was neues aus dem Hut zaubert. Ich habe leider nur lückenhaftes (gefährliches) Halbwissen - Ich meine es hängt mit den aktuellen Größen der Festplatten zusammen. Ich glaube mal gelesen zu haben, dass mit dem MBR eine Grenze bei 2 TiB liegt ... wie gesagt gefährliches Halbwissen. 
--[[Benutzer:Zuul|Zuul]] ([[Benutzer Diskussion:Zuul|Diskussion]]) 11:22, 7. Mär. 2012 (CET)
: Es werden Blöcke auf der Festplatte adressiert (LBA). Jeder LBA ist 512 Bytes groß.
: MBR verwendet 32 Bit für die Adressierung von LBAs, damit gibt's 512 * 2^32 = 2199023255552 Bytes (2 TiB) adressierbaren Speicher; alles, was darüber liegt, kann vom MBR nicht angesprochen werden. Außerdem können im MBR maximal 4 Partitionen erstellt werden.
: GPT verwendet 64 Bit, damit können 512 * 2^64 = 9444732965739290427392 Bytes (8589934592 TiB = 8 ZiB) adressiert werden. Mit GPT können 128 Partitionen verwaltet werden.
: [[Benutzer:Gulliveig|Gulliveig]] ([[Benutzer Diskussion:Gulliveig|Diskussion]]) 04:21, 18. Mär. 2012 (CET)

:: Anmerkungen: Mit der C/H/S Adressierung in der Partitionstabelle kann man nur 8 GB adressieren; die erste Erweiterung besteht darin, die C/H/S Adressen auf den Maximalwert zu setzen, um anzudeuten, dass die Partition mindestens so groß ist. Mit LBA und 64 Bit bei GPT kommt man dann auf "richtig große" Werte (siehe oben). Aus Kompatibilität reserviert man mit dem alten MBR eine Pseudopartition, die maximal groß ist ("Protective MBR"), sodass alte Betriebssysteme keinen freien Platz finden können. Es können zwar im MBR nur vier Partitionen gespeichert werden, aber über "erweiterte Partitionen" kann man auch beliebig viele (theoretisch) Partitionen verwalten. Nicht richtig ist, dass man mit GPT (maximal) 128 Partitionen verwaltet werden können. Man kann mit dem Schema (nicht mit jeder beliebigen existierenden Partitionstabelle) beliebig viele Partitionen verwalten. Die empfohlene Mindestgröße ist 16 KB (UEFI Spezifikation 2.4, Seite 107: "A minimum of 16,384 bytes of space must be reserved for the GPT Partition Array.") -- [[Benutzer:Uhw|Uhw]] ([[Benutzer Diskussion:Uhw|Diskussion]]) 12:36, 2. Dez. 2014 (CET)

== Unterstützung in Betriebssystemen ==

Vorletzter Absatz: "Das Fachmagazin c’t konnte in der Anfangsphase der Einführung während des Tests einer 4 TB großen, mit GPT formatierten Festplatte feststellen, [...] Nach meinem Halbwissen kann man eine Platte nicht mit GPT formatieren, sondern höchstens partitionieren. Haut mich, wenn ich Blödsinn rede.
--[[Benutzer:Timbomat|Timbomat]] ([[Benutzer Diskussion:Timbomat|Diskussion]]) 19:02, 18. Nov. 2012 (CET)

: IMHO ist "Formatieren" das Vorbereiten zur Verwendung (In https://en.wikipedia.org/wiki/Disk_formatting steht: "''Disk formatting is the process of preparing a data storage device such as a hard disk drive, solid-state drive, floppy disk or USB flash drive for initial use.''"). In den Floppy-Urzeiten hieß das dann alles mit 0xE5 überschreiben. In gewissem Sinne könnte man also IMHO von mehreren Ebenen der Formatierung sprechen:

:* Partitionierung
:* Formatieren einer Partition

: Bei einem Software-RAID (z.B. Intel® Rapid-Storage-Technik, IRST) käme dann ganz vorne in der logischen Reihenfolge noch die Formatierung der Platte als RAID-Mitglied.--[[Benutzer:Uhw|Uhw]] ([[Benutzer Diskussion:Uhw|Diskussion]]) 00:20, 18. Nov. 2018 (CET)

== Änderungen von FFrenzel ==

Die Änderungen von FFrenzel (6.Juli, 5 Änderungen) sind schlicht und einfach absoluter Mist.
"GPT" steht ja für "GUID Partition Table", "GPT Partition Table" steht also für "GUID Partition Table Partition Table"?
Gleiches gilt für die Übersetzung.
"GPT-Partition" wäre dann wieder ein sinnvolles Wort, ist aber nicht gleichbedeutend mit "GUID Partition Table" und gehört deshalb nicht an diese Stelle.

Sehr interessant finde ich auch, dass "GPT-Partitions" (nur) mit Diskpart erstellt werden (können). Ich mache das meistens mit gdisk oder gparted, aber gut zu erfahren, dass ich das immer falsch gemacht habe...

Ich bin neu hier und weiß noch nicht wie das so mit dem Zurücksetzen ist. Muss ich dazu jede Änderung nacheinander rückgängig machen oder gibt es auch die Möglichkeit eine ältere Version einfach wiederherzustellen?
--[[Benutzer:SchrödingersZomb|SchrödingersZomb]] ([[Benutzer Diskussion:SchrödingersZomb|Diskussion]]) 01:23, 25. Jul. 2013 (CEST)
:Ok, habe das gerade selber rausbekommen mit dem zurücksetzen... --[[Benutzer:SchrödingersZomb|SchrödingersZomb]] ([[Benutzer Diskussion:SchrödingersZomb|Diskussion]]) 01:25, 25. Jul. 2013 (CEST)

::Ja, danke, dass dir das aufgefallen ist. Mir ist es schlichtweg entgangen. ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 16:31, 25. Jul. 2013 (CEST)

:::Mir ist das wegen Diskpart aufgefallen und dann habe ich halt mal geguckt, seit wann das da so drinn steht... --[[Spezial:Beiträge/79.215.159.248|79.215.159.248]] 01:05, 26. Jul. 2013 (CEST)

== Probleme mit GUID / UUID: Wert oder Darstellung? ==

Ich habe ein Problem mit den UUIDS bzw. GUIDs für die Partitionstypen: In RFC 4122 (A UUID URN Namespace) steht auf Seite 7 (Layout and Byte Order): "...with each field encoded with the Most Significant Byte first (known as network byte order)...". Interpretiere ich die GUIDs so wie sie von parted-3.2 erzeugt werden gemäß RFC 4122, so kommen nicht die Werte heraus, die in der Tabelle angegeben sind:
Für eine "Basic Data Partition" finde ich folgende Byte-Folge:

{0xa2, 0xa0, 0xd0, 0xeb, 0xe5, 0xb9, 0x33, 0x44, 0x87, 0xc0, 0x68, 0xb6, 0xb7, 0x26, 0x99, 0xc7} # Wie wählt man eine nicht-proportionale Schriftart für Computer-Output?

Dekodiert man diese gemäß RFC 4122, so erhalte ich "a2a0d0eb-e5b9-3344-87c0-68b6b72699c7", was wiederum nicht mit den angegebenen GUIDs der Tabelle übereinstimmt, weil dort die Zahlen der GUIDs als "little endian" interpretiert werden.

Betrachtet man in Appendix A ("Sample Implementation") von RFC 4122 die Seite 29 (puid()), so sieht man, daß dort die ersten drei Felder als Zahlen und nicht als Bytefolgen ausgegeben werden (d.h.: die Konvertierung von Big Endian wäre demnach beim Einlesen anzuwenden).
Also entweder ist RFC 4122 falsch, oder die Tabelle im Artikel, oder die GUIDs sind doch keine UUIDs gemäß RFC 4122. Klärung erwünscht!

Derzeit bin ich der Meinung, daß die GUIDs so wie oben gezeigt (also als a2a0d0eb-e5b9-3344-87c0-68b6b72699c7", und nicht "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7") dargestellt werden sollten. RFC 4122 sagt außerdem, daß die sedezimalen Ziffern in Kleinbuchstaben dargestellt werden.

-- [[Benutzer:Uhw|Uhw]] ([[Benutzer Diskussion:Uhw|Diskussion]]) 12:20, 2. Dez. 2014 (CET)

Laut Appendix A der EFI Spezifikation wird z. B. die type guid so in die Tabelle auf der Festplatte geschrieben: Die ersten drei, der durch Bindestrich getrennten, Teile der GUID werden little endian geschrieben, der Rest big endian. Beispiel:
ESP-Partition GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B steht so in der Tabelle 28 73 2a c1 1f f8 d2 11 ba 4b 00 a0 c9 3e c9 3b
Quelle https://developer.apple.com/library/mac/technotes/tn2166/_index.html (''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Spezial:Beiträge/109.85.30.99|109.85.30.99]] ([[Benutzer Diskussion:109.85.30.99|Diskussion]])<nowiki/> 00:15, 3. Aug. 2015 (CEST))

== Bootcode ==

Wie auch beim MBR erfährt man hier nicht wirklich etwas zum Bootcode bzw. wie der Bootprozess läuft bzw. definiert ist. (Und das ändert sich auch nicht wenn man [[UEFI]] gelesen hat.) --[[File:Chess ndl45.svg|15px|kostenloses Arbeitspferd ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 06:55, 28. Mai 2015 (CEST)

:Beim Artikel [[Master Boot Record]] erfährt man eigentlich schon, wie der Bootprozess abläuft. Das Problem ist, dass es eigentlich ein BIOS+MBR-Bootprozess ist, jedoch nicht zwangsläufig beim BIOS immer so ablaufen muss (kann auch BIOS+Bootsektor, der nicht MBR ist, sein), beim MBR jedoch immer (MBR benötigt ein BIOS oder etwas dazu 100% kompatibles, wie UEFI+CSM). Daher steht es im Artikel zum MBR (und nicht etwa im Artikel zum BIOS).
:Bei GPT wird die Sache noch komplizierter, da es eigentlich kein Startprogramm gibt: zumindest nicht bei EFI, Apple-EFI, UEFI und Open Firmware ([[OLPC XO-1]]).
:Allerdings kann man auch mit einem Startprogramm, z.B. von einem BIOS-basierten PC, von einer GPT-partitionierten Festplatte starten. Dazu braucht man ein Startprogramm, das im Bootsektor des Schutz-MBR sitzt und das im Anschluss einen weiteren Bootloader (wie z.B. GRUB) oder direkt einen Kernel auf einer der GPT-Partitionen startet. Siehe auch [http://www.rodsbooks.com/gdisk/booting.html Booting from GPT] von Rod Smith.
:Weil der Startprozess sehr stark von der verwendeten Firmware eines Computers abhängt (BIOS, Open Firmware, EFI), ist es nicht so einfach möglich, ''den'' Bootprozess zu beschreiben. Man müsste sehr weit ausholen.
:Bei MBR ist das einfacher – der enthält nämlich einen dafür vorgesehenen Bootcode.
:GPT hat normalerweise keinen Bootcode. Abgesehen natürlich von dem Fall, dass man mit BIOS+GPT starten will: dann hat der Schutz-MBR den nötigen Bootcode.
:Doch halt:
:Beziehst du dich auf die auf der EFI Service Partition befindlichen EFI-Binary-Bootloader, so ist dazu anzumerken, dass diese nur in Zusammenarbeit mit dem EFI-NVRAM funktionieren, weil sie dort eingetragen werden müssen. Die Ausnahme ist der Fallback-Bootloader in /boot/bootx64.efi (auf 64-Bit-Systemen) auf der ESP (EFI <s>Service</s>System Partition).
:Was meinst du also genau mit ''Bootcode''?
:‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 15:48, 12. Jun. 2015 (CEST)

== 1 MB-Alignment ==

Wird von der GPT Specifikation scheinbar verlangt ("GPT specifications that require 1_megabyte/2048_sector disk"[https://wiki.archlinux.org/index.php/GRUB#Install_grub-bios_boot_files] ). Umseitig steht noch nichts über Alignment. --[[File:Chess ndl45.svg|15px|kostenloses Arbeitspferd ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 04:58, 12. Jun. 2015 (CEST)

:Nachdem, was ich darüber gefunden habe, ist GPT nach LBA-Blöcken ausgerichtet. Siehe z.B. [http://ntfs.com/guid-part-table.htm Ntfs.com]. Jedes andere Alignment ist der physischen Blockgröße eines Speichermediums geschuldet (vermutlich, weil logische LBA-Blockgrößen nicht immer der physischen Größe folgen, etwa bei Advanced Format mit 512-Byte logischen aber 4096-Byte physischen Blöcken). Beispielsweise macht Apple unter OS X standardmäßig ein 4 k-Alignment für Partitionen, siehe [https://developer.apple.com/library/mac/technotes/tn2166/_index.html TN2166], Abschnitt ''Partitioning Policy''. (Beachte: 4k ist 1 LBA-Block bei 4096-Blockgröße und 8 LBA-Blöcke bei 512-Blockgröße.)
:In einer GPT-Spezifikation (oder, was sonst so verfügbar ist) habe ich kein zusätzliches Alignment finden können. Auf der [http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel-UEFI]-Seite findet sich unter ''Tools and Utilities'' ein Download für ''UEFI Disk Utilities'', in dessen Quellcode sich ebenfalls ein Ausrichten nach LBA-Blöcken findet – die darin enthaltene Illustration (ASCII) zeigt 1:1 wie auf der Ntfs.com-Seite bereits illustriert ein Layout nach fortlaufenden LBA-Blocknummern.
:Auf Linux.com findet sich [https://www.linux.com/learn/tutorials/730440-using-the-new-guid-partition-table-in-linux-good-bye-ancient-mbr- Using the New GUID Partition Table in Linux (Goodbye Ancient MBR)] vom 25. Juni 2013:
::''GPT has several advantages over the MBR:''
::*''64-bit disk pointers allows 264 total sectors, so a hard disk with 512-byte blocks can be as large as 8 zebibytes. With 4096-byte sectors your maximum disk size is really really large''
:Das legt nahe – ''…with 512-byte blocks … with 4096-byte sectors …'' – dass GPT auf unterschieldichen LBA-Blockgrößen genau gleich funktioniert: <code>LBA 0</code> bis <code>LBA LAST</code>, mit dem GPT-Header jeweils auf <code>LBA 1</code> und <code>LBA LAST-1</code>.
:‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 09:49, 12. Jun. 2015 (CEST)

:::Niemand hat behauptet, dass kleinräumiges und schlechtes Alignment nicht funktioniert. --[[File:Chess ndl45.svg|15px|kostenloses Arbeitspferd ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 11:57, 12. Jun. 2015 (CEST)

:Vermutlich ist das der Teil der Spezifikation um den es geht:
{{Zitat|Quelle=[http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf UEFI Specification Version 2.5] Seite 120|Text=To avoid the need to determine the physical block size and the optimal transfer length granularity,
software may align GPT partitions at significantly larger boundaries. For example, assuming logical
block 0 is aligned, it may use LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB)
boundaries, which supports most common physical block sizes and RAID stripe sizes.}}
:--[[Benutzer:F. Saerdna|F. Saerdna]] ([[Benutzer Diskussion:F. Saerdna|Diskussion]]) 14:20, 12. Jun. 2015 (CEST)

::Ja, das ist es wohl.
::‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 14:57, 12. Jun. 2015 (CEST)
::Siehe auch [http://superuser.com/questions/732228/linux-tools-that-can-partition-gpt-with-proper-alignment superuser.com: Linux tools that can partition GPT with proper alignment]
::‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 15:00, 12. Jun. 2015 (CEST)

::::Danke, F. Saerdna. Das wirft bei mir leider wieder die Frage auf, wie sich may übersetzt: soll oder mehr als sollen? --[[File:Chess ndl45.svg|15px|kostenloses Arbeitspferd ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 22:17, 12. Jun. 2015 (CEST)

:::::Kein ''sollen''. ''May'' heißt ''es kann so sein (düfen, können, mögen)'', muss aber nicht. Und genau das passiert ja auch: jedes Betriebssystem setzt seine eigenen Alignment-Größen fest – hat also unterschiedliche Strategien, mit den verschiedenen Blockgrößen umzugehen. GPT selbst legt das aber nicht fest. Außerdem steht das in der UEFI-Spezifikation, die ja viel mehr als nur den GPT regelt. ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 23:06, 12. Jun. 2015 (CEST)
:::::::Hmm, ich bilde mir ein, dass mir vor einiger Zeit jemand mal bedeutet hat, dass ''may'' in ~juristischen Texten mehr als "soll" heißt. Weniger als "soll" würde allerdings wohl kaum Sinn ergeben. --[[File:Chess ndl45.svg|15px|kostenloses Arbeitspferd ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 06:05, 13. Jun. 2015 (CEST)

::::::::Möglich. Allerdings ist die UEFI-Spezifikation kein juristischer, sondern ein technischer Text.
::::::::Abgesehen davon steht dort ja nicht ''Software may align at a 1 MiB boundary'', sondern es steht ''for example a 1 MiB boundary''.
::::::::Ab Windows Vista ist die voreingestellte Ausrichtung auf 1 MiB gesetzt. Siehe [https://msdn.microsoft.com/en-us/library/dd758814.aspx Disk Partition Alignment Best Practices for SQL Server], Unterpunkt Partition Alignment in Windows Operating Systems: ''In Windows Vista as well as Windows Server 2008, partition alignment is usually performed by default. The default for disks larger than 4 GB is 1 MB;''
::::::::Mac OS X macht eine 4 k-Ausrichtung und lässt zwischen den Partitionen immer ein wenig Platz.
::::::::Unter Linux gibt es alles mögliche – je nach Distribution und verwendetem Partitionierungsprogramm.
::::::::Und viele anderen Betriebssysteme, ältere Betriebssysteme, machen keine Korrektur. Mit Glück partitionieren sie nach LBA-Blocknummern. Allerdings kann man ja immer auch manuell partitionieren, denn man weiß ja hoffentlich, welches Speichermedium welche physische Blockgröße hat.
::::::::Die im UEFI-Dokument vorgeschlagene Ausrichtung auf 1 MiB macht heute Sinn, aber mit der weiteren Entwicklung und neuen Speichermedien vielleicht nicht mehr. Dann gibt es vermutlich eine Revision dieses Dokuments, und einen neuen Vorschlag für das Alignment.
::::::::Mit GPT hat das aber eigentlich nichts zu tun – auch MBR und andere Partitionstabellen sollte man nach der physischen Blockgröße eines Speichermediums ausrichten. Es ist letztlich Betriebssystemsache und System-Administrator-Sache.
::::::::‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 08:15, 13. Jun. 2015 (CEST)
:::::Ich kann Andreas nur zustimmen. ''May'' heißt hier nicht mehr als ''kann''. (Auch wenn diese RFC nicht explizit in der Spezifikation erwähnt wird, siehe auch [https://www.ietf.org/rfc/rfc2119.txt RFC 2119]) --[[Benutzer:F. Saerdna|F. Saerdna]] ([[Benutzer Diskussion:F. Saerdna|Diskussion]]) 13:53, 14. Jun. 2015 (CEST)
::::::Danke! RFC2119 ist sogar im Artikel [[Request for Comments]] verlinkt… Man lernt nie aus! ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 14:14, 14. Jun. 2015 (CEST)

== GUIDs (Tabelle) ==

Ich habe mit [https://de.wikipedia.org/w/index.php?title=GUID_Partition_Table&type=revision&diff=143727285&oldid=143700426 dieser Änderung] die Tabelle der [[GUID Partition Table#Partitionstyp-GUIDs|Partitionstyp-GUIDs]] überarbeitet. Dazu hätte ich gerne Feedback und Hilfe:
# Sortierung: die Tabelle ist jetzt alphabetisch sortiert. (Hersteller/System)
# Einheitlichkeit der Farben. Wir sollten durchwegs mit hintergrundfarbe1 bis 9 formatieren, siehe [[Hilfe:Farbe#Hintergrundfarben|Hilfe:Farbe]].
# Spalten: Ich habe die Spalte „Betriebssystem“ in „Hersteller“ und „System“ zerlegt
#* Apple z.B. bietet mit Apple TV und OS X zwei unterschiedliche Systeme/Betriebssysteme an. Gerade beim Apple TV ist es schwierig, von einem Betriebssystem zu sprechen, jedoch ist es einfach, das System zu benennen. Daher erscheint es angenehmer, von Apple als Hersteller zu den einzelnen Systemen zu den verwendeten GUIDs zu kommen.
#* In Fällen, wo sich diese Unterteilung nicht machen lässt (Linux, *BSD), habe ich die Zellen zusammengehängt.
# Zu beachten ist, dass GUIDs grundsätzlich nicht auf die aufgelisteten Systeme beschränkt sind. Man kann jederzeit eine beliebige GUID-Partition erstellen und verwenden (gerade Linux und *BSD ermöglichen, dass beliebige GUIDs dennoch richtig verwendet werden können). GUIDs anderer Systeme können aber auch shr oft systemgerecht auf einem fremden System verwendet werden (z.B. verwendet MacZFS die ZFS-GUID für /usr von Solaris).
Ich persönlich finde die Tabelle mit der Priorisierung der Systeme (Betriebssysteme) als Ausgangspunkt okay. Alternativ könnte man die Partition in den Mittelpunkt stellen, und in einer der hinteren Spalten die Systeme auflisten, die diese Partition verwenden. (Vgl. [[Apple Partition Map#Partitionstypen|APM]]).

Jedenfalls hätte ich gerne Feedback.
‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 15:13, 4. Jul. 2015 (CEST)

:Ich habe mir die Freiheit genommen, die Tabelle doch [https://de.wikipedia.org/w/index.php?title=GUID_Partition_Table&type=revision&diff=143737385&oldid=143731805 komplett umzukrämpeln]. Ich habe die GUID als Ausgangspunkt genommen und die MBR-Typen (hexadezimal) mit einbezogen. Das erscheint mir nicht nur in Anbetracht von Hybrid-MBRs sinnvoll, sondern auch der Tatsache wegen, dass jede GUID-Partitionstabelle per Spezifikation auch eine MBR-Partitionstabelle enthält.
:Als Ausgangspunkt habe ich [https://github.com/kini/gptfdisk/blob/master/parttypes.cc parttypes.cc] (Zeilen 66 bis 176) von [http://sourceforge.net/projects/gptfdisk/ gptfdisk] herangezogen.
:‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 21:33, 4. Jul. 2015 (CEST)

== Falsche Verwendung des Begriffs "LBA" ==

LBA bedeutet "Logical block addressing" und bezeichnet eine Adressierungsart für die Datenblöcke eines Datenträgers. Nicht die Blöcke selbst! Die GPT beginnt sich also nicht auf "Logical Block Addressing 1", sondern auf "Block 1", wobei die Blöcke nach LBA nummeriert werden. Hat jemand was dagegen, wenn ich das im Artikel in Ordnung bringe? --[[Benutzer:RokerHRO|RokerHRO]] ([[Benutzer Diskussion:RokerHRO|Diskussion]]) 14:58, 24. Dez. 2018 (CET)

:Steht nicht in der Spezifikation auch LBA? Soweit mir bekannt ist LBA-Block 0-⚭ schon eine Art, Blöcke anzuspechen. Der Grund ist, dass ein LBA-Block eine Adresse sein kann, genauso wie ein C/H/S-Wert eine Adresse für einen Block sein kann. Darauf basiert dann die Referenzierung von Blöcken. Genauso wie man kein Short Messaging Service versicken kann, weil ein Service ja grundsätzlich nicht verschickbar ist, man dann aber doch eine SMS schickt.
:‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 15:53, 24. Dez. 2018 (CET)

: Nun, es heißt ja "logical" Block, der kann sich von der realen Blockschreibweise, wie es der Controller der HW in den Speicher schreibt unterscheiden. Insofern halte ich hier LBA als Bezeichner für die GPT Blöcke schon sinnvoll. --[[Spezial:Beiträge/109.192.198.207|109.192.198.207]] 08:49, 6. Mai 2020 (CEST)

== Wo definiert Microsoft die Attributeinträge? ==

Im Artikel heißt es "Microsoft definiert folgende Attributeinträge:". Es handelt sich um Bit Angaben, es
wird aber nicht gesagt, wo genau die definiert werden. Ist damit gemeint, dass die einzelnen Bit im Bereich der gesamten 128 Byte eines Partitionseintrag geschrieben werden? Also Bit 0, 1 und 2 in den Bereich, wo normalerweise die Partitionstyp-GUID steht, womit diese 3 Bits immer Teil der Partitionstyp-GUID sind. Sowie Bit 60, 62 und 63 in den Bereich im 8. Byte des Partitionstyp-GUID Eintrags? Wenn ja, dann sollte man das im Artikel deutlicher ausformulieren. So wie es jetzt drin steht, kann man nur raten bzw. hier fragen. --[[Spezial:Beiträge/109.192.198.207|109.192.198.207]] 08:46, 6. Mai 2020 (CEST)

== Einleitungs-Fail ==

„... der ausgehend von Großrechnern etwa seit dem Jahr 2000 das BIOS in PCs ersetzte.“ - dabei ist diese Zeitangabe so falsch oder irreführend wie „Großrechner“ unklar. --[[File:Lemon with white background.jpg|15px|Quetsch mich aus, ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 20:49, 30. Jun. 2020 (CEST)

:EFI: Seit 2001 in Itanium-Rechnern. Entwicklung von EFI seit 1999 oder so. Was sind Itanium-Rechner?
:Man kann den Text sicher verbessern. Ich selbst kenne keine Itanium-Rechner "persönlich". ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 20:56, 30. Jun. 2020 (CEST)
:''Nachtrag:'' Itanium: Prozessoren bzw. eine Architektur für den Server-Markt. Eine mögliche Umformulierung wäre also, "Großrechner" durch "Server" zu ersetzen. Oder? ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 21:03, 30. Jun. 2020 (CEST)

== Ende der Partitionstabelle ==

Ich bastle mir gerade einen Partitionstabellen-"Dechiffrierer". Ich bin fast fertig, frage mich jetzt aber noch: Wie ist vorgesehen den letzten Eintrag der Partitionstabelle festzustellen? --[[File:Lemon with white background.jpg|15px|Quetsch mich aus, ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 12:14, 3. Apr. 2021 (CEST)
:Im Header findet sich an Offset 80 die Nummer der <s>(benutzten)</s> Partitionen. ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 13:14, 3. Apr. 2021 (CEST)
::Okay, der Wert im Header ist wohl nicht die Anzahl der benutzten Partitionen, sondern die Größe der Partitionstabelle selbst (bei GPT sind per Spezifikation mindestens 128 Partitionen möglich). Ich denke, man müsste daher alle Partitionen auslesen und wenn eine davon nicht empty ist, kommt sie in die Liste (bzw. der Zähler für benutzte Partitionen zählt eines hoch). Vielleicht hilft dir das weiter: https://metebalci.com/blog/a-quick-tour-of-guid-partition-table-gpt/
::‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 13:27, 3. Apr. 2021 (CEST)

== Partitionstyp ==

Welchen Zweck erfüllt eigentlich der Partitionstyp? - dazu sollte durchaus noch was gesagt werden. --[[File:Lemon with white background.jpg|15px|Quetsch mich aus, ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 18:03, 18. Apr. 2021 (CEST)

:Wie schon vorher bei der MBR-Partitionstabelle: Damit Betriebssysteme und andere Software, die die Partitionstabelle auswerten, z.B. wissen, was "ihre" Partitionen sind, z.B. damit sie die dann booten können. --[[Benutzer:RokerHRO|RokerHRO]] ([[Benutzer Diskussion:RokerHRO|Diskussion]]) 18:09, 20. Apr. 2021 (CEST)

::Meine Frage galt unausgesprochen für MBR und GPT - Typen.
::Und hmmm... Zwar sind wie die Tabelle umseitig auch zeigt die GUID-typen stärker auf Betriebssysteme fokussiert als noch die MBR-Typen, aber auch hier ist das nicht so rein.
::Bei MBR ist ja noch eine grosse Vielfalt an Dateisystemen dabei. Wobei Filesysteme in ihren Partitionen selbst ja nochmal ihre eigenen Identifier haben...
::Wäre schon interessant was Quellen hierzu sagen. --[[File:Lemon with white background.jpg|15px|Quetsch mich aus, ... ]] [[Benutzer:Itu|itu]] ([[Benutzer Diskussion:Itu|Disk]]) 21:12, 20. Apr. 2021 (CEST)

:::Das ist wie bei allen Datentypen: Eine Software muss nur das Konzept können, um interoperabel zu sein. Dabei liest die Software die Tabelle in standardisierter Form, kümmert sich dann aber nur um jene Einträge, mit denen es umgehen kann. Damit lässt sich eine Reihe von Problemen umgehen: so können neuere Betriebssysteme neue Partitionenstypen verwenden, ohne dass gleichzeitig die Gefahr bestünde, dass ältere Software diese Daten zerstört, denn die Software lässt von unbekannten Partitionstypen einfach die Finger. Auch Multi-Boot lässt sich damit viel leichter regeln. Und zu guter letzt kann man – was GPT ja nutzt/bietet – auch festlegen, welche Partition das genau ist (der Zweck, wie z.B. freedesktop.org /home). Damit lassen sich gewisse Automatismen und Interoperabilität herstellen.
:::Ich glaube nicht, dass es irgendwo definitiv festgelegt ist, was der Partitionstyp darstellen soll. Denn er kann ein Hinweis auf ein Dateisystem sein, das von vielen Systemen gleichermaßen nutzbar ist, aber er kann auch system-spezfisch exklusiv sein. Bei GPT könnte ein Anwender (oder Systemadministrator) sogar seinen eigenen Partitionstyp festlegen (nicht öffentlich), und mit diesen z.B. auf Wechselfestplatten (mit wechselnder Partitionierung) dafür sorgen, dass die Partitionen korrekt eingebunden und/oder verwendet werden. Ähnlich wie z.B. Linux-Swap-Partitionen den gewünschten Nutzungszweck per Partitionstyp festlegen und ein automatisches Verwenden ermöglichen.
:::‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 19:17, 17. Mai 2021 (CEST)

== Partitionstyp (GUID) von AmigaOS ==

{{Ping|Michalsc}} Deine zwei Änderungen [[Spezial:Diff/247353649/251625829]] und [[Spezial:Diff/251625829/251625886]] haben leider keinen Beleg (siehe [[WP:BLG]]), und ich kann dazu auch im Internet nichts finden. Ein Sichten ist mir damit nicht möglich. Kannst du bitte eine Quelle angeben, woher du diesen Partitions-GUID eines [[Rigid Disk Block]]s von Emu68/AmigaOS hast? ‣[[Benutzer:Y2kbug|Andreas]]•[[Benutzer_Diskussion:Y2kbug|⚖]] 17:08, 27. Dez. 2024 (CET)

:Hi! Ich bin der Author und Entwickler von Emu68 sowie von dazugehörigen Treiber die bisher nur RDB eingebettet in MBR unterstützt haben (https://michalsc.github.io/Emu68/tutorials/SD_Preparation.html). Zur Zeit bin ich dabei die GTP Unterstützung hinzufügen und dafür habe ich den GUID generiert und gleich in Wiki eingetragen. Bald wird dieses auch in WinUAE (berühmte Amiga Emulator) implementiert.
:ich hoffe dass die Information ausreichend ist. --[[Benutzer:Michalsc|Michalsc]] ([[Benutzer Diskussion:Michalsc|Diskussion]]) 20:45, 27. Dez. 2024 (CET)

GUID Partition Table

2024-12-27T13:46:43Z

Michalsc: Emu68 MBR Typ zentriert in der Tabelle

'''GUID Partition Table''' ('''GPT'''), zu deutsch '''GUID-Partitionstabelle''' (von {{enS|[[Globally Unique Identifier]]}}), ist ein Standard für das Format von [[Partitionstabelle]]n auf [[Datenträger]]n wie beispielsweise [[Festplatte]]n. Die Spezifikation ist Teil des [[Unified Extensible Firmware Interface|UEFI]]-Standards, der ausgehend von Großrechnern etwa seit dem Jahr 2000 das [[BIOS (IBM PC)|BIOS]] in [[IBM-PC-kompatibler Computer|PCs]] ersetzte. GPT ist dabei der Nachfolger der Partitionstabelle des [[Master Boot Record]]. GUID-Partitionstabellen können unter Einschränkungen auch auf Computern mit einem BIOS als [[Firmware]] verwendet werden.<ref name="LinuxGPTBoot">{{Literatur |Autor=Thorsten Leemhuis |Titel=Wachstumsprobleme – Besonderheiten beim Zusammenspiel von Linux mit großen Festplatten |Sammelwerk=[[c’t]] |Band=2011 |Nummer=4 |Verlag=[[Verlag Heinz Heise|Heise-Verlag]] |Datum=2011-01-31 |Seiten=170–172 |Online=[https://www.heise.de/artikel-archiv/ct/2011/4/170_kiosk Artikel-Archiv] |Abruf=2020-05-02}} {{" |Text=[…] das häufig als ‚BIOS-Nachfolger‘ deklarierte UEFI [wird] meist in einem Atemzug mit GPT genannt, obwohl sich letztere auch unabhängig davon nutzen lässt – GPT-taugliche Boot-Loader wie der noch junge Grub2 starten Linux problemlos ohne UEFI.}}</ref>

== Aufbau ==
[[Datei:GUID Partition Table Scheme.svg|300px|mini|Schematische Darstellung einer GPT. Jeder LBA-Block entspricht einem Sektor der Festplatte und ist 512 Bytes groß. Negative Zahlen stehen für eine Position vom Ende des Datenträgers an gemessen, wobei LBA −1 der letzte adressierbare Block ist.]]

Entsprechend dem GPT-[[Partitionsschema#Partitionstabelle|Schema]] besteht ein Datenträger aus den folgenden Bereichen:
* Master Boot Record (MBR) in Sektor 0 (dem ersten, 512 Bytes großen [[Datenblock#Datenspeicher|Datenblock]]), dessen spezielle Konfiguration den Einsatz der Platte auch unter MBR-Betriebssystemen erlaubt und vor Veränderungen durch nicht-GPT-taugliche MBR-Partitionierungstools schützt (Schutz-MBR; von {{enS|protective MBR}})
* primäre GUID-Partitionstabelle (GPT), bestehend aus Header und Partitionseinträgen
* [[Partition (Informatik)|Partitionen]]
* sekundäre GPT, bestehend aus Header und Partitionseinträgen

Die sekundäre GUID-Partitionstabelle am Ende des Datenträgers ist teilweise eine Kopie der primären GPT am Anfang des Datenträgers: Die Inhalte der Felder für die Positionen des eigenen und des alternativen GPT Headers sind vertauscht und die Adresse der Partitionstabelle verweist auf die Kopie der Partitionstabelle am Ende der Platte vor dem alternativen Header. Damit haben beide GPT-Header auch eine unterschiedliche [[Zyklische Redundanzprüfung|CRC32]]-[[Prüfsumme]]. Durch die enthaltene [[Redundanz (Technik)|Redundanz]] kann im Fehlerfall die Partitionstabelle wiederhergestellt werden. Da in der GPT eine Prüfsumme eingetragen wird, kann festgestellt werden, ob beide bzw. welche der beiden GPT fehlerhaft sind.

=== {{Anker|Schutz-MBR}}{{Anker|protective MBR}}MBR-Partitionstabelle ===
Im ersten Sektor/[[Datenblock#Datenspeicher|Block]] des Datenträgers ([[Logical Block Addressing|LBA]] 0) befindet sich der MBR mit einer klassischen MBR-Partitionstabelle und einem Eintrag, der den Rest des Datenträgers als belegt kennzeichnet. Für ein Partitionierungstool, das nur MBR-, aber keine GPT-Partitionstabellen lesen kann, erscheint daher der gesamte Platz auf dem Datenträger als belegt. Der MBR einer GPT-Festplatte stellt somit einen Schutz für den Inhalt des Datenträgers dar, falls auf diesen mit Partitionierungstools, die das GPT-Schema nicht kennen, zugegriffen werden soll (daher auch {{enS|protective MBR}}).
Als [[Master Boot Record#Wichtige Partitionstypen mit ihren Kennnummern|Partitionskennung]] wird der Wert EE16 für einen Schutz-MBR (mit nachfolgender GUID-Partitionstabelle) oder EF16 bei einer EFI-Systempartition verwendet.<ref>{{cite web |url=http://www.win.tue.nl/~aeb/partitions/partition_types-1.html |title=List of partition identifiers for PCs |publisher=Technische Universität Eindhoven |accessdate=2012-04-18 |language=en}}</ref>

=== Header der GUID-Partitionstabelle ===
Im zweiten Sektor/Block ([[Logical Block Addressing|LBA]] 1) befindet sich der Header der primären GPT und im letzten Sektor/Block (LBA −1) befindet sich der Header der sekundären Backup-GPT. Der Header selbst beschreibt u. a. die nutzbaren Blöcke des Datenträgers, die Position des eigenen Headers und des sekundären Backup-Headers sowie die Anzahl und Größe der Partitionseinträge. Die EFI-Spezifikationen<ref>{{Webarchiv |url=http://www.uefi.org/home/ |text=uefi.org |wayback=20120415051255}} (U)EFI Specification (englisch)</ref> schreiben ein Minimum von 16.384 Bytes für die Partitionstabelle vor, so dass es Platz für 128 Einträge gibt. Weiterhin werden der Header selbst und die Partitionseinträge mit [[CRC32]]-Prüfsummen abgesichert, die von der [[Firmware]], dem [[Bootloader]] oder dem [[Betriebssystem]] überprüft werden müssen. Wird daher der Header z. B. mit einem [[Hexeditor]] verändert, macht dies die Checksumme ungültig und das System wird instabil oder sogar unbrauchbar.

Im Header der GPT sind folgende Informationen abgelegt:
{| class="wikitable" style="text-align:right;"
|-
! Offset !! Länge !! Inhalt
|-
| 0 || 8 bytes ||style="text-align:left"| Signatur („EFI PART“, <code style="border:none;">45h 46h 49h 20h 50h 41h 52h 54h</code>)
|-
| 8 || 4 bytes ||style="text-align:left"| Revision (<code style="border:none;">00h 00h 01h 00h</code>)
|-
| 12 || 4 bytes ||style="text-align:left"| Header-Größe – [[Byte-Reihenfolge|Little Endian]] (<code style="border:none;">5Ch 00h 00h 00h</code> entspricht 92 bytes)
|-
| 16 || 4 bytes ||style="text-align:left"| Header-CRC32-Prüfsumme (von Offset 0 bis Header-Größe, dieses Feld selbst wird bei der Berechnung auf 0 gesetzt)
|-
| 20 || 4 bytes ||style="text-align:left"| Reservierter Bereich – muss Null (0) sein
|-
| 24 || 8 bytes ||style="text-align:left"| Position des eigenen LBA (dieses Headers)
|-
| 32 || 8 bytes ||style="text-align:left"| Position des Backup-LBA (des anderen Headers)
|-
| 40 || 8 bytes ||style="text-align:left"| Erster benutzbarer LBA für Partitionen (Letzter LBA der primären Partitionstabelle + 1, normalerweise 34)
|-
| 48 || 8 bytes ||style="text-align:left"| Letzter benutzbarer LBA (Erster LBA der sekundären Partitionstabelle – 1, normalerweise Datenträgergröße – 34)
|-
| 56 || 16 bytes ||style="text-align:left"| Datenträger-[[GUID]] (als Referenz siehe auch [[UUID]] bei UNIXe)
|-
| 72 || 8 bytes ||style="text-align:left"| Start-LBA der Partitionstabelle
|-
| 80 || 4 bytes ||style="text-align:left"| Anzahl der Partitionseinträge (Partitionen)
|-
| 84 || 4 bytes ||style="text-align:left"| Größe eines Partitionseintrags (normalerweise 128)
|-
| 88 || 4 bytes ||style="text-align:left"| Partitionstabellen-CRC32-Prüfsumme
|-
| 92 ||style="text-align:center"| * ||style="text-align:left"| Reservierter Bereich; muss mit Nullen, für den Rest des Blocks, belegt sein (420 Bytes bei einem 512-byte LBA)
|}

=== Partitionseintrag ===
Die Partitionseinträge werden im LBA 2 bis LBA 33 (sekundäre GPT: LBA -33 bis LBA -2) abgelegt. Jeder Partitionseintrag umfasst 128 Byte. Somit können pro logischem Block vier Partitionseinträge abgelegt werden. Diese in der Spezifikation vorgeschriebene Mindestanzahl von 32 Sektoren für Partitionseinträge kann bei Bedarf beliebig erhöht werden, so dass die maximal mögliche Anzahl an Partitionen prinzipiell nur durch den zur Verfügung stehenden Plattenplatz beschränkt wird.

Im Partitionseintrag selbst sind folgende Daten hinterlegt:
{| class="wikitable" style="text-align:right;"
|+
! Offset !! Länge !! Inhalt
|-
| 0 || 16 Bytes ||style="text-align:left"| Partitionstyp-GUID
|-
| 16 || 16 Bytes ||style="text-align:left"| Eindeutige Partitions-GUID
|-
| 32 || 8 Bytes ||style="text-align:left"| Beginn der Partition (erster LBA – Little-Endian)
|-
| 40 || 8 Bytes ||style="text-align:left"| Ende der Partition (letzter LBA – inklusive)
|-
| 48 || 8 Bytes ||style="text-align:left"| Attribute (siehe folgende Tabelle)
|-
| 56 || 72 Bytes ||style="text-align:left"| Partitionsname (36 [[UTF-16]]LE-Zeichen)
|-
| insg. || 128 Bytes ||
|}

Die einzelnen Einträge sind verhältnismäßig einfach aufgebaut. Die ersten 16 Bytes beschreiben den Partitionstyp. Die Partitionstyp-GUID für eine EFI-Systempartition ist z. B. {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}. Es folgen 16 Bytes mit der Partitions-GUID. Dann folgen die Nummer des ersten und des letzten LBA-Sektors der Partition, 8 Bytes mit Attributen und der Name der Partition (36 Unicode-Zeichen lang).

Microsoft definiert folgende Attributeinträge:
{| class="wikitable"
|+
! Bit !! Inhalt
|-
|style="text-align:right"| 0 || Systempartition
|-
|style="text-align:right"| 1 || vor EFI verstecken
|-
|style="text-align:right"| 2 || Legacy BIOS bootfähig (analog MBR <code>80h</code> Active flag)<ref>{{Internetquelle |url=http://t13.org/documents/UploadedDocuments/docs2010/e09127r3-EDD-4_Hybrid_MBR_boot_code_annex.pdf |titel=e09127r3 EDD-4 Hybrid MBR boot code annex |abruf=2023-01-17 |format=PDF; 116 kB |archiv-url=https://web.archive.org/web/20120303074339/http://t13.org/documents/UploadedDocuments/docs2010/e09127r3-EDD-4_Hybrid_MBR_boot_code_annex.pdf |archiv-datum=2012-03-03}}</ref>
|-
|style="text-align:right"| 60 || Nur lesen (Read-only)
|-
|style="text-align:right"| 62 || Versteckt (Hidden)
|-
|style="text-align:right"| 63 || Nicht automatisch mounten (= keinen Laufwerksbuchstaben zuweisen)
|}

=== {{Anker|ESP|EFI System Partition|EFI-Systempartition|EFI-System-Partition}}Systempartition ===
Für [[Bootfähiges Medium|startfähige Medien]], die zum [[Booten]] eines Systems verwendet werden können, ist eine spezielle Partition namens {{enS|EFI System Partition}}, kurz ESP, vorgesehen. Eine System-Firmware nach dem EFI-Standard sucht bei externen Medien auf der EFI-Systempartition nach Bootloadern und bietet im EFI-[[Bootmenü]] alle kompatiblen Einträge zur Auswahl an. Bei internen Startmedien, etwa der eingebauten [[Festplatte]], muss ein installiertes System den jeweiligen EFI-Bootloader im NVRAM als Eintrag hinzufügen. Der Standardeintrag lässt sich mit Dienstprogrammen verändern, im Bootmenü werden alle konfigurierten Bootloader angezeigt.

=== Partitionstyp-GUIDs ===
{| class="wikitable zebra"
|-
!colspan="2"|Partitionstyp
!rowspan="2"|ursprüngliches System
!rowspan="2" style="white-space:nowrap"|englische Bezeichnung
!rowspan="2"|Bezeichnung und Beschreibung
|-
! GPT ([[Globally Unique Identifier|GUID]], [[Hexadezimalsystem|hexadezimal]])
! MBR ([[Hexadezimalsystem|hex]])
|-
|style="white-space:nowrap"|<code>00000000-0000-0000-0000-000000000000</code>
|style="text-align:center"| 00
| GPT
| Unused entry
| Eintrag für eine unbenutzte Partition.
|-
|rowspan="14"|<code>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</code>
|style="text-align:center"| 01
|rowspan="14"|{{nowrap|[[IBM Personal Computer|IBM PC]]/}}&ZeroWidthSpace;[[IBM-PC-kompatibler Computer|kompatibel]]
|rowspan="14"|Microsoft basic data
| [[File Allocation Table#FAT12|FAT12]]
|-
|style="text-align:center"| 04
| [[File Allocation Table#FAT16|FAT16]] < 32 MB
|-
|style="text-align:center"| 06
| [[File Allocation Table#FAT16|FAT16]]
|-
|style="text-align:center"| 07
| [[NTFS]] (oder [[High Performance File System|HPFS]])
|-
|style="text-align:center"| 0b
| [[File Allocation Table#FAT32|FAT32]]
|-
|style="text-align:center"| 0c
| [[File Allocation Table#FAT32|FAT32]] [[Logical Block Addressing|LBA]]
|-
|style="text-align:center"| 0e
| [[File Allocation Table#FAT16|FAT16]] [[Logical Block Addressing|LBA]]
|-
|style="text-align:center"| 11
| [[File Allocation Table#FAT12|FAT12]] (versteckt)
|-
|style="text-align:center"| 14
| [[File Allocation Table#FAT16|FAT16]] < 32 MB (versteckt)
|-
|style="text-align:center"| 16
| [[File Allocation Table#FAT16|FAT16]] (versteckt)
|-
|style="text-align:center"| 17
| [[NTFS]] (oder [[High Performance File System|HPFS]]) (versteckt)
|-
|style="text-align:center"| 1b
| [[File Allocation Table#FAT32|FAT32]] (versteckt)
|-
|style="text-align:center"| 1c
| [[File Allocation Table#FAT32|FAT32]] [[Logical Block Addressing|LBA]] (versteckt)
|-
|style="text-align:center"| 1e
| [[File Allocation Table#FAT16|FAT16]] [[Logical Block Addressing|LBA]] (versteckt)
|-
| <code>E3C9E316-0B5C-4DB8-817D-F92DF00215AE</code>
|style="text-align:center"| 0c
| [[Microsoft Windows|Windows]] ([[Extensible Firmware Interface|EFI]])
| Microsoft reserved
| Hybrid-MBR-Typ <code>0x0c</code> entspricht dem von FAT32 LBA
|-
| <code>DE94BBA4-06D1-4D40-A16A-BFD50179D6AC</code>
|style="text-align:center"| 27
| [[Microsoft Windows|Windows]]
| [[Windows-Wiederherstellungsumgebung|Windows RE]]
| [[Wiederherstellungspartition]]<ref>[https://technet.microsoft.com/de-at/library/dd744301(v=ws.10).aspx Empfohlene Konfigurationen für UEFI-basierte Datenträgerpartitionen] unter Windows 7 und Windows Server 2008 R2. Microsoft TechNet; abgerufen am 7. Juli 2015</ref> mit [[Windows-Wiederherstellungsumgebung|Windows Recovery Environment]]<ref>[https://technet.microsoft.com/de-at/library/cc765966(v=ws.10).aspx Was ist Windows RE?] Microsoft TechNet; abgerufen am 4. Juli 2015</ref> (ab [[Microsoft Windows Vista|Vista]], basiert auf [[Microsoft Windows PE|Windows PE]])
|-
| <code>7412F7D5-A156-4B13-81DC-867174929325</code>
|rowspan="2" style="text-align:center"| 30, e1
|rowspan="2"| ONIE
| ONIE boot
|rowspan="2"| Open Network Install Environment (ONIE)<ref name="onieblkdev">{{Toter Link |date=2018-04 |url=https://github.com/onie/onie/blob/master/rootconf/x86_64/sysroot-lib-onie/onie-blkdev-common }}</ref><ref>[http://www.onie.org/ onie.org]</ref>
|-
| <code>D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149</code>
| ONIE config
|-
| <code>C91818F9-8025-47AF-89D2-F030D7000C2C</code>
|style="text-align:center"| 39
| [[Plan 9 (Betriebssystem)|Plan 9]]
| Plan 9
| Vom Betriebssystem Plan 9 verwendete Partition.<ref>[http://man.cat-v.org/9front/8/prep man.cat-v.org]</ref>
|-
| <code>9E1A2D38-C612-4316-AA26-8B49521E5A8B</code>
|style="text-align:center"| 41
| [[PowerPC Reference Platform|PReP]]
| [[PowerPC]] PReP boot
| PReP war der Vorläufer von CHRP bzw. der [[PowerPC Platform]].
|-
| <code>AF9B60A0-1431-4F62-BC68-3311714A69AD</code>
|rowspan="3" style="text-align:center"| 42
|rowspan="3"| [[Microsoft Windows|Windows]]
| Windows LDM data
|rowspan="3"| Der {{lang|en|Logical Disk Manager}} (LDM) ist die Umsetzung eines {{lang|en|[[Logical Volume Manager]]}} unter [[Microsoft Windows NT|Windows NT]], der in Windows 2000 bis Windows 7 vorhanden ist. Ab Windows 8 ist dessen Nachfolger {{lang|en|Storage Spaces}} enthalten.
|-
| <code>5808C8AA-7E8F-42E0-85D2-E1E90434CFB3</code>
| Windows LDM metadata
|-
| <code>E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D</code>
| Windows Storage Spaces
|-
| <code>37AFFC90-EF7D-4E96-91C3-2D7AE055B174</code>
|style="text-align:center"| 75
|
| IBM GPFS
| [[General Parallel File System]] (GPFS)
|-
|style="white-space:nowrap"| <code>FE3A2A5D-4F32-41A7-B725-ACCC3285A309</code>
|rowspan="3" style="text-align:center"| 7f
|rowspan="3"| [[Chromebook]]
| ChromeOS [[Kernel (Betriebssystem)|kernel]]
|rowspan="3"| [[Google Chrome OS]]<ref name="ChromeOSsrcgpth">vboot_reference/firmware/lib/cgptlib/include/gpt.h, ChromeOS-Quelltext von 23. Dezember 2010</ref><ref name="chromiumos-diskformat">[http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format chromium.org]</ref>
|-
| <code>3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC</code>
| ChromeOS [[Stammverzeichnis|root]]
|-
| <code>2E0A753D-9E48-43B0-8337-B15192CB1B5E</code>
| ChromeOS reserved
|-
| <code>0657FD6D-A4AB-43C4-84E5-0933C84B4F4F</code>
|style="text-align:center"| 82
|rowspan="3"| [[Linux]]
| Linux [[Auslagerungsdatei|swap]]
| [[Auslagerungsdatei|Auslagerungspartition]] von Linux. Auch Solaris verwendet auf MBR-Partitionen den Typ <code>0x82</code> als [[Swapping|swap]].
|-
| <code>0FC63DAF-8483-4772-8E79-3D69D8477DE4</code>
|rowspan="2" style="text-align:center"| 83
| Linux filesystem
| Dieser Partitionstyp wird auch als “Linux native” bezeichnet.
|-
| <code>8DA63339-0007-60C0-C436-083AC8230908</code>
| Linux reserved
| Der Hybrid-MBR-Typ entspricht dem von “Linux native”, <code>0x83</code>.
|-
| <code>933AC7E1-2EB4-4F13-B844-0E14E2AEF915</code>
|rowspan="8" style="text-align:center"| 83
|rowspan="9"| [[freedesktop.org]] (Linux)
| Linux [[Benutzerverzeichnis|/home]]
|rowspan="4"| auto-mount für [[systemd]] von freedesktop.org<ref name="systemd-gpt-auto">[http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html freedesktop.org]</ref><ref name="DiscoverablePartitionsSpec">[http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ freedesktop.org]</ref>
|-
| <code>3B8F8425-20E0-4F3B-907F-1A25A76F98E8</code>
| Linux /srv
|-
| <code>7FFEC5C9-2D00-49B7-8941-3EA10A5586B7</code>
| Linux [[dm-crypt]]
|-
| <code>CA7D7CCB-63ED-4C53-861C-1742536059CC</code>
| Linux [[Linux Unified Key Setup|LUKS]]
|-
| <code>44479540-F297-41B2-9AF7-D131D5F0458A</code>
| Linux [[IA-32|x86]]
| [[Stammverzeichnis|root]]-Partition auf [[32-Bit-Architektur|32-Bit]]-[[x86-Prozessor|x86]]-Systemen ([[IA-32]]).
|-
| <code>4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709</code>
| Linux [[x64|x86-64]]
| [[Stammverzeichnis|root]]-Partition auf [[64-Bit-Architektur|64-Bit]]-[[x86-Prozessor|x86]]-Systemen ([[IA-32]] im [[x64]]-Modus).
|-
| <code>69DAD710-2CE4-4E3C-B16C-21A1D49ABED3</code>
| Linux [[ARM-Architektur|ARM32]]
| [[Stammverzeichnis|root]]-Partition auf [[32-Bit-Architektur|32-Bit]]-[[ARM-Architektur|ARM]]-Systemen.
|-
| <code>B921B045-1DF0-41C3-AF44-4C6F280D3FAE</code>
| Linux [[ARM-Architektur|ARM64]]
| [[Stammverzeichnis|root]]-Partition auf [[64-Bit-Architektur|64-Bit]]-[[ARM-Architektur|ARM]]-Systemen (ARMv8).
|-
| <code>993d8d3d-f80e-4225-855a-9daf8ed7ea97</code>
| –
| Linux [[Itanium-Architektur|IA-64]]
| [[Stammverzeichnis|root]]-Partition auf [[Itanium-Architektur|Itanium]]-Systemen (IA-64).
|-
| <code>D3BFE2DE-3DAF-11DF-BA40-E3A556D89593</code>
|style="text-align:center"| 84
| [[Intel]]-[[IBM-PC-kompatibler Computer|PC]]
| Intel Rapid Start
| Was als ''Intel Rapid Start Technology'' bezeichnet wird, ist eigentlich eine Mischform aus [[Bereitschaftsbetrieb]] (S3, {{lang|en|“suspend to RAM”}}) und [[Ruhezustand]] (S4, {{lang|en|“suspend to disk”}}).<ref>[[c’t]] Hotline: [http://heise.de/-2132476 Was ist „Rapid Start Technology“?] aus Heft 7/2014, abgerufen am 9. Juli 2015</ref>
|-
| <code>E6D6D379-F507-44C2-A23C-238F2A3DF928</code>
|style="text-align:center"| 8e
| [[Linux]]
| Linux LVM
| [[Logical Volume Manager]]
|-
|rowspan="3"| <code>734E5AFE-F61A-11E6-BC64-92361F002671</code>
|rowspan="3" style="text-align:center"| -
|rowspan="3"| [[TOS (Betriebssystem)|Atari TOS]]
|rowspan="3"| TOS basic data
| [[File Allocation Table#FAT16|FAT16]] < 32 MB, <code>'GEM'</code>
|-
| [[File Allocation Table#FAT16|FAT16]], <code>'BGM'</code>
|-
| [[File Allocation Table #FAT32|FAT32]], <code>'F32'</code>
|-
| <code>35540011-B055-499F-842D-C69AECA357B7</code>
|style="text-align:center"| -
| [[TOS (Betriebssystem)|Atari TOS]]
| TOS raw data
| XHDI-Typ <code>'RAW'</code>, Details s. XHDI-Spezifikation
|-
| <code>516E7CB4-6ECF-11D6-8FF8-00022D09712B</code>
|rowspan="6" style="text-align:center"| a5
|rowspan="6"| [[FreeBSD]]
| FreeBSD [[Disklabel]]
|
|-
| <code>83BD6B9D-7F41-11DC-BE0B-001560B84F0F</code>
| FreeBSD boot
|
|-
| <code>516E7CB5-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>516E7CB6-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[Unix File System|UFS]]
|
|-
| <code>516E7CBA-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[ZFS (Dateisystem)|ZFS]]
|
|-
| <code>516E7CB8-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD Vinum/[[RAID]]
|
|-
| <code>85D5E45A-237C-11E1-B4B3-E89A8F7FC3A7</code>
|rowspan="6" style="text-align:center"| a5
|rowspan="6"| [[MidnightBSD]]
| MidnightBSD data
|
|-
| <code>85D5E45E-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD boot
|
|-
| <code>85D5E45B-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>0394EF8B-237E-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[Unix File System|UFS]]
|
|-
| <code>85D5E45D-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[ZFS (Dateisystem)|ZFS]]
|
|-
| <code>85D5E45C-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD Vinum
|
|-
| <code>824CC7A0-36A8-11E3-890A-952519AD3F61</code>
|style="text-align:center"| a6
| [[OpenBSD]]
| OpenBSD data
|
|-
| <code>55465300-0000-11AA-AA11-00306543ECAC</code>
|style="text-align:center"| a8
| [[macOS|Mac OS X]]
| Apple [[Unix File System|UFS]]
| Partition, die ein [[Unix File System]] enthält. Entspricht dem [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_UFS</code>.
|-
| <code>516E7CB4-6ECF-11D6-8FF8-00022D09712B</code>
|rowspan="7" style="text-align:center"| a9
| [[FreeBSD]]
| FreeBSD [[Disklabel]]
| FreeBSD, NetBSD, OpenBSD (unter OpenBSD wird MBR-Typ <code>0xa6</code> verwendet<ref name="gptfdisk" />)
|-
| <code>49F48D32-B10E-11DC-B99B-0019D1879648</code>
|rowspan="6"| [[NetBSD]]
| NetBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>49F48D5A-B10E-11DC-B99B-0019D1879648</code>
| NetBSD FFS
|
|-
| <code>49F48D82-B10E-11DC-B99B-0019D1879648</code>
| NetBSD LFS
|
|-
| <code>2DB519C4-B10F-11DC-B99B-0019D1879648</code>
| NetBSD concatenated
|
|-
| <code>2DB519EC-B10F-11DC-B99B-0019D1879648</code>
| NetBSD encrypted
|
|-
| <code>49F48DAA-B10E-11DC-B99B-0019D1879648</code>
| NetBSD [[RAID]]
|
|-
| <code>426F6F74-0000-11AA-AA11-00306543ECAC</code>
|style="text-align:center"| ab
|rowspan="12"| [[macOS]]
| Apple boot
| [[Wiederherstellungspartition]] seit [[Mac OS X Lion]] (10.7, 2011). Enthält ein [[HFS Plus|HFS+]]- oder [[Apple File System|APFS]]-Dateisystem und heißt normalerweise <code>Recovery HD</code>, ist jedoch versteckt.
|-
| <code>48465300-0000-11AA-AA11-00306543ECAC</code>
|rowspan="11" style="text-align:center"| af
| Apple [[HFS (Dateisystem)|HFS]]/[[HFS Plus|HFS+]]
| Partition für das Dateisystem [[HFS Plus|HFS+]], entspricht [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_HFSX</code>. Das ältere [[HFS (Dateisystem)|Hierarchical File System (HFS)]], [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_HFS</code>, findet auf GPT-Partitionen normalerweise keine Verwendung mehr.
|-
| <code>52414944-0000-11AA-AA11-00306543ECAC</code>
| Apple [[RAID]]
| Beherbergt eine Partition aus einem [[RAID]]-Verbund. Entspricht dem [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_RAID</code>.
|-
| <code>52414944-5F4F-11AA-AA11-00306543ECAC</code>
| Apple [[RAID]] offline
| Beherbergt eine aus einem [[RAID]]-Verbund entfernte Partition.
|-
| <code>4C616265-6C00-11AA-AA11-00306543ECAC</code>
| Apple Label
| {{lang|en|“Apple Label”}} ist eine [[Disklabel]]-Variante für [[macOS|Mac OS X]].<ref>Apple Developer: [https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/disklabel.8.html disklabel man page] (englisch), abgerufen am 12. Juli 2015</ref>
|-
| <code>5265636F-7665-11AA-AA11-00306543ECAC</code>
| AppleTV Recovery
| Das [[Apple TV]] verwendet ein Betriebssystem auf Basis von Mac OS X mit einer für Fernseher optimierten Benutzeroberfläche.
|-
| <code>53746F72-6167-11AA-AA11-00306543ECAC</code>
| Apple Core Storage
| Eine ''Core-Storage''-Partition für [[FileVault]] 2 (verschlüsselt). Apple [[Fusion Drive]] verwendet ebenfalls eine Partition dieses Typs.
|-
| <code>B6FA30DA-92D2-4A9A-96F1-871EC6486200</code>
| Apple SoftRAID Status
|rowspan="4"| Apple SoftRAID-Partition.
|-
| <code>2E313465-19B9-463F-8126-8A7993773801</code>
| Apple SoftRAID Scratch
|-
| <code>FA709C7E-65B1-4593-BFD5-E71D61DE9B02</code>
| Apple SoftRAID Volume
|-
| <code>BBBA6DF5-F46F-4A89-8F59-8765B2727503</code>
| Apple SoftRAID Cache
|-
| <code>7C3457EF-0000-11AA-AA11-00306543ECAC</code>
| Apple [[Apple File System|APFS]]
| Partition für das Dateisystem [[Apple File System|APFS]], dem Nachfolger von [[HFS Plus|HFS+]] auf [[macOS]].
|-
| <code>CEF5A9AD-73BC-4601-89F3-CDEEEEE321A1</code>
|style="text-align:center"| b3
| [[QNX]]
| QNX6 Power-Safe
|
|-
| <code>0311FC50-01CA-4725-AD77-9ADBB20ACE98</code>
|style="text-align:center"| bc
| [[Acronis]]
| Acronis Secure Zone
|
|-
| <code>6A82CB45-1DD2-11B2-99A6-080020736631</code>
|style="text-align:center"| be
|rowspan="13"| [[Solaris (Betriebssystem)|Solaris]]
| Solaris boot
|
|-
| <code>6A85CF4D-1DD2-11B2-99A6-080020736631</code>
|rowspan="7" style="text-align:center"| bf
| Solaris [[Stammverzeichnis|root]]
|
|-
| <code>6A898CC3-1DD2-11B2-99A6-080020736631</code>
| Solaris /usr
| Beherbergt bis Solaris 9 üblicherweise das Dateisystem [[Unix File System|UFS]] und ab Solaris 10 [[ZFS (Dateisystem)|ZFS]]. MacZFS<ref>[http://code.google.com/p/maczfs/ MacZFS.org: Official Site for the Free ZFS for Mac OS] (englisch), abgerufen am 9. Juli 2015</ref> verwendet dieselbe GUID.
|-
| <code>6A87C46F-1DD2-11B2-99A6-080020736631</code>
| Solaris [[Auslagerungsdatei|swap]]
|
|-
| <code>6A8B642B-1DD2-11B2-99A6-080020736631</code>
| Solaris backup
|
|-
| <code>6A8EF2E9-1DD2-11B2-99A6-080020736631</code>
| Solaris /var
|
|-
| <code>6A90BA39-1DD2-11B2-99A6-080020736631</code>
| Solaris [[Benutzerverzeichnis|/home]]
|
|-
| <code>6A9283A5-1DD2-11B2-99A6-080020736631</code>
| Solaris alternate sector
|
|-
| <code>6A945A3B-1DD2-11B2-99A6-080020736631</code>
|rowspan="5" style="text-align:center"| bf
|rowspan="5"| Solaris Reserved
|rowspan="5"|
|-
| <code>6A9630D1-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A980767-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A96237F-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A8D2AC7-1DD2-11B2-99A6-080020736631</code>
|-
| <code>75894C1E-3AEB-11D3-B7C1-7B03A0000000</code>
|rowspan="2" style="text-align:center"| c0
|rowspan="2"| [[HP-UX]]
| HP-UX data
|
|-
| <code>E2A1E728-32E3-11D6-A682-7B03A0000000</code>
| HP-UX service
|
|-
| <code>BC13C2FF-59E6-4262-A352-B275FD6F7172</code>
|style="text-align:center"| ea
| [[freedesktop.org]]
| Freedesktop $BOOT
| <ref name="DiscoverablePartitionsSpec" />
|-
| <code>42465331-3BA3-10F1-802A-4861696B7521</code>
|style="text-align:center"| eb
| [[Haiku (Betriebssystem)|Haiku]]
| Haiku [[Be File System|BFS]]
| Obwohl [[BeOS]] selbst keine GUID-Partitionstabelle unterstützte, wird diese Partition von dessen Weiterentwicklung Haiku für ein ''[[Be File System]]'' verwendet.
|-
| <code>BFBFAFE7-A34F-448A-9A5B-6213EB736C22</code>
|rowspan="2" style="text-align:center"| ed
|rowspan="2"| ESP, herstellerspezifisch
| [[Lenovo]] system partition
|rowspan="2"| Herstellerspezifische {{lang|en|EFI System Partition}} (ESP), die von der spezifischen Firmware (UEFI) als ESP identifiziert wird.
|-
| <code>F4019732-066E-4E12-8273-346C5641494F</code>
| [[Sony]] system partition
|-
| <code>C12A7328-F81F-11D2-BA4B-00A0C93EC93B</code>
|rowspan="3" style="text-align:center"| ef
|rowspan="3"| EFI
| EFI System (ESP)
| Diese Partition wird als [[#EFI System Partition|{{lang|en|EFI System Partition}}]] (ESP) bezeichnet. Sie enthält ein FAT-Dateisystem, von dem die Firmware eine ausführbare Datei ([[Portable Executable|PE]]/[[Common Object File Format|COFF]]), z. B. <code>\EFI\BOOT\BOOTX64.EFI</code>, lädt und ausführt. Unter <code>[[GNU Parted|parted]]</code> wird diese Partition mit {{lang|en|“boot flag”}}, also als [[Startpartition]], angezeigt.<ref>[http://www.rodsbooks.com/efi-bootloaders/principles.html Managing EFI Boot Loaders for Linux: Basic Principles] (englisch), Rod Smith, abgerufen am 9. Juli 2015</ref>
|-
| <code>024DEE41-33E7-11D3-9D69-0008C781F39F</code>
| MBR partition scheme
| Diese Partition enthält eine eingebettete vollständige MBR-Partitionstabelle samt Partitionen. Da die enthaltenen Partitionen jedoch keine Hybrid-Partitionen sind, kann darauf nicht aus der GUID-Partitionstabelle zugegriffen werden. Doch ist es damit möglich, eine Partition zu [[Virtualisierung (Informatik)|Virtualisierungszwecken]] an eine [[Virtuelle Maschine]] durchzureichen, die darauf eine vollständige MBR-Partitionstabelle einrichtet und verwendet.
|-
| <code>21686148-6449-6E6F-744E-656564454649</code>
| BIOS boot partition
| Eine Partition, die von [[Grand Unified Bootloader|GRUB]] zum Starten auf [[BIOS (IBM PC)|BIOS]]-basierten [[IBM-PC-kompatibler Computer|PCs]] verwendet wird. Die GUID liest sich <code>!haHdInotNeedEFI</code> in [[Hexadezimal]]darstellung (was in der benötigten [[Little Endian|Little-Endian]]-Form im GPT dann „Hah!IdontNeedEFI“ ergibt).
|-
| <code>4FBD7E29-9D25-41B8-AFD0-062C0CEFF05D</code>
|rowspan="6" style="text-align:center"| f8
|rowspan="6"| [[Ceph]]<ref>[https://github.com/ceph/ceph/blob/9bcc42a3e6b08521694b5c0228b2c6ed7b3d312e/src/ceph-disk#L76-L81 github.com]</ref>
| Ceph OSD
| Ceph Object Storage Daemon
|-
| <code>4FBD7E29-9D25-41B8-AFD0-5EC00CEFF05D</code>
| Ceph [[dm-crypt]] OSD
| Ceph Object Storage Daemon (verschlüsselt)
|-
| <code>45B0969E-9B03-4F30-B4C6-B4B80CEFF106</code>
| Ceph journal
|
|-
| <code>45B0969E-9B03-4F30-B4C6-5EC00CEFF106</code>
| Ceph [[dm-crypt]] journal
|
|-
| <code>89C57F98-2FE5-4DC0-89C1-F3AD0CEFF2BE</code>
| Ceph disk in creation
|
|-
| <code>89C57F98-2FE5-4DC0-89C1-5EC00CEFF2BE</code>
| Ceph [[dm-crypt]] disk in creation
|
|-
| <code>AA31E02A-400F-11DB-9590-000C2911D1B8</code>
|rowspan="2" style="text-align:center"| fb
|rowspan="3"| [[VMware]] ESX
| VMware VMFS
|
|-
| <code>9198EFFC-31C0-11DB-8F78-000C2911D1B8</code>
| VMware reserved
|
|-
| <code>9D275380-40AD-11DB-BF97-000C2911D1B8</code>
|style="text-align:center"| fc
| VMware kcore crash protection
|
|-
| <code>A19D880F-05FC-4D3B-A006-743F0F84911E</code>
|style="text-align:center"| fd
| [[Linux]]
| Linux [[RAID]]
|
|-
|<code>3F82EEBC-87C9-4097-8165-89D6540557C0</code>
|style="text-align:center"| 76
|Emu68/[[AmigaOS]]
|[[Rigid Disk Block]]
|Diese Partition enthält eine eingebettete, vollständige AmigaOS-RDB-Partitionstabelle einschließlich aller Partitionen. Aufgrund der Einschränkungen der RDB darf die Größe dieser Partition 2 TiB nicht überschreiten.
|}

Da bei vielen Systemen eine Überführung von MBR- in GUID-Partitionen möglich ist, gibt es für viele GUID-Partitionstypen einen entsprechenden MBR-Partitionstyp. Auch bei der Verwendung von Hybrid-MBRs werden die entsprechenden Partitionen einmal mit GUID- und einmal mit dazu passendem MBR-Partitionstyp erstellt.

== Konvertierung ==
Es besteht grundsätzlich die Möglichkeit, von der Master-Boot-Record-Partitionstabelle zur GUID-Partitionstabelle zu konvertieren, jedoch wird dabei genügend freier Platz zwischen MBR und erster Partition sowie nach der letzten Partition vorausgesetzt, um die nötige Datenstruktur für die GUID-Partitionstabelle aufnehmen zu können. Unter anderem das Programm ''GPT fdisk'' (besser bekannt als <code>gdisk</code>) bietet diese Möglichkeit.<ref name="gptfdisk_mbr2gpt" /> Auch die Überführung von einigen BSD-Disklabel-Partitionen in GPT ist damit möglich.

== Begrenzungen ==
Die GPT verwendet [[Logical Block Addressing]] (LBA) mit 64 Bit umfassenden Einträgen, sodass – bei einer Sektorengröße von 512 Byte – Festplatten bis zu einer Gesamtkapazität von 8 [[Zebibyte]] adressiert werden können. Die maximale Anzahl möglicher Partitionen hängt von der Größe der Partitionstabelle ab, die laut Spezifikation mindestens für 128 Partitionen Platz bietet. Nicht alle Systeme bieten diese Möglichkeit, jedoch kann z. B. das Partitionierungswerkzeug <code>gdisk</code> eine größere Partitionstabelle erzeugen.<ref>{{Internetquelle |url=http://www.uefi.net/2015/01/guid-partition-table.html |titel=GUID Partition Table |hrsg=UEFI Support |datum=2015-01-26 |format=[[Blog]] |sprache=en |abruf=2018-12-23 |zitat=Advantages of GPT; 3. Arbitrary number of partitions - depends on space allocated for the partition table … By default the GPT table contains space for defining 128 partitions. However if the user wants to define more partitions, he/she can allocate more space to the partition table (currently only gdisk is known to support this feature).}}</ref>

== Hybrid-MBR ==
Ein Hybrid-MBR bezeichnet das Definieren einzelner Partitionen sowohl in der GUID-Partitionstabelle (GPT) als auch in der Partitionstabelle des [[Master Boot Record|Master Boot Record (MBR)]]. Ein Zugriff auf die Partitionen ist dadurch sowohl über GPT als auch über MBR möglich, was [[Multi-Boot-System|Dual-Boot]] zwischen Betriebssystemen ermöglicht, die nur jeweils eine der beiden Partitionstabellen verwenden oder unterstützen.

Im MBR ist normalerweise nur eine den gesamten Datenbereich umfassende Schutzpartition enthalten, was als Schutz-MBR ({{enS|“protective MBR”}}) bezeichnet wird. Bei Hybrid-Partitionierung wird ein und dieselbe Partition sowohl in der GUID- als auch in der MBR-Partitionstabelle definiert: da der Master Boot Record dabei als [[Hybrid]] der eigentlichen GUID-Partitionstabelle auftritt, wird in diesem Fall die Bezeichnung „Hybrid-MBR“ verwendet.

Die Gefahr bei der Hybrid-Partitionierung ist, dass das Verändern nur einer der beiden Partitionstabellen zu groben Partitionierungsfehlern führen kann. Daher muss eine Hybrid-Partitionierung durch dafür vorgesehene Programme erfolgen und darf keinesfalls über Partitionierungswerkzeuge eines Betriebssystems, welches nur eine der beiden Partitionstabellen verwendet, verändert werden.

Die Anzahl der Hybrid-Partitionen ist auf vier gemeinsame Partitionen beschränkt. Das Definieren einer erweiterten MBR-Partition ist nicht möglich, da GPT keine erweiterten Partitionen unterstützt. Umgekehrt gibt es nur Platz für insgesamt vier primäre Partitionen in der Partitionstabelle des Master Boot Record. Da für EFI eine primäre Partition benötigt wird – die EFI System Partition (ESP) – stehen drei Hybrid-Partitionen für Betriebssysteme oder gemeinsame Datenpartitionen zur Verfügung. Es ist die einzig sichere Lösung, mit maximal vier Hybrid-Partitionen (inklusive der ESP) den gesamten nutzbaren Speicherplatz zu partitionieren.

Mit manueller Partitionierung ist es dennoch möglich, nicht alle Partitionen als Hybrid-Partition abzubilden: dann kann zwar das Betriebssystem, das nur den MBR auswertet, nicht auf alle Partitionen zugreifen, jedoch ermöglicht es ausreichend viele gemeinsame Partitionen für einen Dual-Boot-Betrieb. Allerdings fällt in einer solchen Konfiguration der Schutz für GUID-Partitionen, welche nicht auch als MBR-Partitionen existieren, weg. Das Betriebssystem, das nur den MBR auswertet, sieht weiteren vermeintlich unpartitionierten und somit leeren Speicherplatz, der von keiner der MBR-Partitionen beansprucht wird. Es ist Sache des Anwenders, dem Betriebssystem nicht zu gestatten, von diesem Speicherplatz Gebrauch zu machen, da dieser in Wirklichkeit von weiteren GUID-Partitionen genutzt wird, somit Daten enthält und ein irrtümliches Überschreiben zu Datenverlust innerhalb der GUID-Partitionen führt.

Apple nutzt unter [[macOS]] (bis 2016 „OS X“ und bis 2012 „Mac OS X“) mit [[Boot Camp (Software)|Boot Camp]] einen Hybrid-MBR. Wenn Windows gestartet wird, dann geschieht dies über ein {{lang|en|Compatibility Support Module}} (CSM) der Apple-EFI-Firmware, sodass Windows wie bei einem [[IBM-PC-kompatibler Computer|PC]] mit [[BIOS (IBM PC)|BIOS]] die MBR-Partitionstabelle verwendet, nicht aber die GUID-Partitionstabelle. Wird jedoch macOS gestartet, so wird die GUID-Partitionstabelle genutzt. Das [[Festplattendienstprogramm (Apple)|Festplattendienstprogramm]] von macOS erstellt automatisch einen Hybrid-MBR, sobald eine der Partitionen mit einem FAT32-Dateisystem formatiert wird und nicht mehr als insgesamt vier Partitionen auf dem Datenträger vorhanden sind.

== Unterstützung in Betriebssystemen ==
Für Betriebssysteme, die auf der [[Itanium-Architektur]] (auch IA-64 für {{enS|Intel Architecture 64-Bit}}) aufbauen, ist die Unterstützung von GPT zwingend notwendig, da diese Rechner das [[Extensible Firmware Interface]] (EFI) verwenden. Neben den entsprechenden Itanium-Versionen von [[FreeBSD]], [[HP-UX]], [[Linux]], [[NetBSD]], [[OpenVMS]], [[Solaris (Betriebssystem)|Solaris]] und [[Microsoft Windows|Windows]] wird seit der Ablöse des [[BIOS (IBM PC)|PC-BIOS]] durch das [[Unified Extensible Firmware Interface]] (UEFI) auch von allen 64-Bit-PC-Betriebssystemen, „[[x64]]“ bzw. „[[x86-Architektur|x86]]-64“, die GUID-Partitionstabelle unterstützt. Da ab ca. 2005 zunehmend UEFI das PC-BIOS auch auf 32-Bit-[[x86-Prozessor]]en „[[IA-32]]“ ersetzte (wenn auch mit dem BIOS-Kompatibilitätsmodul „CSM“), unterstützen auch die 32-Bit-Varianten der PC-Betriebssysteme GPT, wenn auch oft nicht als [[Systemlaufwerk]] zum [[Booten|Starten]].

Seit der Umstellung der [[Apple]]-[[Macintosh]]-Rechner auf Intel-Prozessoren Anfang 2006 verwendet [[macOS|Mac OS X]] (seit 2016 „macOS“) ebenfalls GPT, da Intel-basierte Macs eine Apple-eigene EFI-Variante verwenden. [[Mac OS X Tiger]] (10.4, 2005) und neuer kann jedoch auch auf der PowerPC-Plattform GPT-Medien verwenden, Firmware-bedingt aber nicht davon [[Booten|starten]].

Die Versionen von [[Microsoft Windows XP|Windows XP]], die noch für die 32-Bit-Intel i386-Architektur entwickelt wurden, können dagegen auf einer GPT-Festplatte nur mit Einschränkungen installiert und betrieben werden. Unter anderem lesen sie nur den MBR, nicht aber die GPT, um Partitionierungsdaten zu erhalten. Durch die Verwendung von hybriden Partitionstabellen können die jeweiligen Partitionen sowohl als MBR- als auch als GPT-Partition eingerichtet werden, allerdings stehen im MBR maximal drei primäre Partitionen zur Verfügung, da dieser nicht mehr als vier Einträge zulässt und die erste Partition bereits für die EFI-Firmware reserviert ist. Umgekehrt werden erweiterte Partitionen des MBR, die als Container mehrere logische Partitionen enthalten können, von GPT nicht mehr unterstützt.

Bis zum Erscheinen von [[Microsoft Windows Vista|Windows Vista]] Anfang 2007 richteten sich die 64-Bit-Windows-Versionen vornehmlich an Server-Betreiber und professionelle Anwender (z. B. CAD oder Grafik/Design). Dazu zählt auch die bereits 2005 erschienene [[Microsoft Windows XP Professional x64 Edition|Windows XP Professional x64 Edition]]. Bei deren Erscheinen war die umfassende GPT-Unterstützung durch entsprechende 64-Bit-Treiber nur bei ausgesuchter Hardware vorhanden. Mit Erscheinen von Vista wurde die Verfügbarkeit von 64-Bit-Treibern generell besser, sodass diese in der Regel ebenfalls die x64-Version von XP unterstützen.

Das Fachmagazin [[c’t]] konnte in der Anfangsphase der Einführung während des Tests einer 4 TB großen mit GPT partitionierten Festplatte feststellen, dass zahlreiche Festplattentreiber namhafter Hersteller beim Schreiben auf Bereiche jenseits von 2 TB die Daten statt an der gewünschten Stelle am Anfang der Festplatte ablegten, so dass es zu massiven Datenverlusten oder gar zum Verlust der Formatierung der Festplatte kam.<ref>''RAID-System: 4 TByte in einem Gehäuse'', In: c’t Nr. 2/2009, S. 54</ref> Das Problem trat anscheinend speziell bei den 32-Bit-Versionen von Windows XP auf, die zwar teilweise schon Unterstützung für GPT mit sich führten, jedoch aufgrund ihres 32-Bit-Treiberdesigns bei der früher üblichen physischen Sektor-Größe von 512 Byte die 2-TB-Grenze nicht überschreiten konnten.<ref>Microsoft TechNet: [http://technet.microsoft.com/de-de/library/cc773223.aspx GUID-Partitionstabelle]</ref> Da der Einsatz solcher Partitionen damals noch hauptsächlich bei Servern anzutreffen war, ergaben sich diese Probleme am ehesten dann, wenn die Festplatten eines solchen Systems mit anderen Rechnern ausgetauscht wurden.

Ein 64-Bit-[[Linux]] kann – ganz ohne UEFI oder gesonderte BIOS-Unterstützung – mit [[GRUB2]] von einer GPT-Partition booten. Es ist also kein UEFI dazu notwendig – die Kopplung von GPT an (U)EFI ist somit nicht zwingend.<ref name="LinuxGPTBoot" />

[[OpenBSD]] unterstützt die Installation auf einer GPT-Partition eines [[x64|x86_64]]-[[UEFI]]-Systems seit Version 5.9<ref>{{cite web|title=OpenBSD 5.9|url=https://www.openbsd.org/59.html|language=en}}</ref>.

== Weblinks ==
* [https://thestarman.pcministry.com/asm/mbr/GPT.htm An Examination of The Microsoft® Windows™ 7, 8 and 10 GPT 'Protective' MBR and EFI Partitions] (englisch)

== Einzelnachweise ==
<references>
<ref name="gptfdisk">
[http://sourceforge.net/projects/gptfdisk/ gptfdisk] auf sourceforge.com (englisch); abgerufen am 4. Juli 2015
</ref>
<ref name="gptfdisk_mbr2gpt">
[http://www.rodsbooks.com/gdisk/mbr2gpt.html Converting to or from GPT.] Rod Smith (englisch); abgerufen am 12. Juli 2015
</ref>
</references>

{{Navigationsleiste Partitionstabellen}}

[[Kategorie:Partitionsschema]]
[[Kategorie:Betriebssystemkomponente]]

GUID Partition Table

2024-12-27T13:44:58Z

Michalsc: Emu68 GUID hinzufügt, samt Erläuterungen

'''GUID Partition Table''' ('''GPT'''), zu deutsch '''GUID-Partitionstabelle''' (von {{enS|[[Globally Unique Identifier]]}}), ist ein Standard für das Format von [[Partitionstabelle]]n auf [[Datenträger]]n wie beispielsweise [[Festplatte]]n. Die Spezifikation ist Teil des [[Unified Extensible Firmware Interface|UEFI]]-Standards, der ausgehend von Großrechnern etwa seit dem Jahr 2000 das [[BIOS (IBM PC)|BIOS]] in [[IBM-PC-kompatibler Computer|PCs]] ersetzte. GPT ist dabei der Nachfolger der Partitionstabelle des [[Master Boot Record]]. GUID-Partitionstabellen können unter Einschränkungen auch auf Computern mit einem BIOS als [[Firmware]] verwendet werden.<ref name="LinuxGPTBoot">{{Literatur |Autor=Thorsten Leemhuis |Titel=Wachstumsprobleme – Besonderheiten beim Zusammenspiel von Linux mit großen Festplatten |Sammelwerk=[[c’t]] |Band=2011 |Nummer=4 |Verlag=[[Verlag Heinz Heise|Heise-Verlag]] |Datum=2011-01-31 |Seiten=170–172 |Online=[https://www.heise.de/artikel-archiv/ct/2011/4/170_kiosk Artikel-Archiv] |Abruf=2020-05-02}} {{" |Text=[…] das häufig als ‚BIOS-Nachfolger‘ deklarierte UEFI [wird] meist in einem Atemzug mit GPT genannt, obwohl sich letztere auch unabhängig davon nutzen lässt – GPT-taugliche Boot-Loader wie der noch junge Grub2 starten Linux problemlos ohne UEFI.}}</ref>

== Aufbau ==
[[Datei:GUID Partition Table Scheme.svg|300px|mini|Schematische Darstellung einer GPT. Jeder LBA-Block entspricht einem Sektor der Festplatte und ist 512 Bytes groß. Negative Zahlen stehen für eine Position vom Ende des Datenträgers an gemessen, wobei LBA −1 der letzte adressierbare Block ist.]]

Entsprechend dem GPT-[[Partitionsschema#Partitionstabelle|Schema]] besteht ein Datenträger aus den folgenden Bereichen:
* Master Boot Record (MBR) in Sektor 0 (dem ersten, 512 Bytes großen [[Datenblock#Datenspeicher|Datenblock]]), dessen spezielle Konfiguration den Einsatz der Platte auch unter MBR-Betriebssystemen erlaubt und vor Veränderungen durch nicht-GPT-taugliche MBR-Partitionierungstools schützt (Schutz-MBR; von {{enS|protective MBR}})
* primäre GUID-Partitionstabelle (GPT), bestehend aus Header und Partitionseinträgen
* [[Partition (Informatik)|Partitionen]]
* sekundäre GPT, bestehend aus Header und Partitionseinträgen

Die sekundäre GUID-Partitionstabelle am Ende des Datenträgers ist teilweise eine Kopie der primären GPT am Anfang des Datenträgers: Die Inhalte der Felder für die Positionen des eigenen und des alternativen GPT Headers sind vertauscht und die Adresse der Partitionstabelle verweist auf die Kopie der Partitionstabelle am Ende der Platte vor dem alternativen Header. Damit haben beide GPT-Header auch eine unterschiedliche [[Zyklische Redundanzprüfung|CRC32]]-[[Prüfsumme]]. Durch die enthaltene [[Redundanz (Technik)|Redundanz]] kann im Fehlerfall die Partitionstabelle wiederhergestellt werden. Da in der GPT eine Prüfsumme eingetragen wird, kann festgestellt werden, ob beide bzw. welche der beiden GPT fehlerhaft sind.

=== {{Anker|Schutz-MBR}}{{Anker|protective MBR}}MBR-Partitionstabelle ===
Im ersten Sektor/[[Datenblock#Datenspeicher|Block]] des Datenträgers ([[Logical Block Addressing|LBA]] 0) befindet sich der MBR mit einer klassischen MBR-Partitionstabelle und einem Eintrag, der den Rest des Datenträgers als belegt kennzeichnet. Für ein Partitionierungstool, das nur MBR-, aber keine GPT-Partitionstabellen lesen kann, erscheint daher der gesamte Platz auf dem Datenträger als belegt. Der MBR einer GPT-Festplatte stellt somit einen Schutz für den Inhalt des Datenträgers dar, falls auf diesen mit Partitionierungstools, die das GPT-Schema nicht kennen, zugegriffen werden soll (daher auch {{enS|protective MBR}}).
Als [[Master Boot Record#Wichtige Partitionstypen mit ihren Kennnummern|Partitionskennung]] wird der Wert EE16 für einen Schutz-MBR (mit nachfolgender GUID-Partitionstabelle) oder EF16 bei einer EFI-Systempartition verwendet.<ref>{{cite web |url=http://www.win.tue.nl/~aeb/partitions/partition_types-1.html |title=List of partition identifiers for PCs |publisher=Technische Universität Eindhoven |accessdate=2012-04-18 |language=en}}</ref>

=== Header der GUID-Partitionstabelle ===
Im zweiten Sektor/Block ([[Logical Block Addressing|LBA]] 1) befindet sich der Header der primären GPT und im letzten Sektor/Block (LBA −1) befindet sich der Header der sekundären Backup-GPT. Der Header selbst beschreibt u. a. die nutzbaren Blöcke des Datenträgers, die Position des eigenen Headers und des sekundären Backup-Headers sowie die Anzahl und Größe der Partitionseinträge. Die EFI-Spezifikationen<ref>{{Webarchiv |url=http://www.uefi.org/home/ |text=uefi.org |wayback=20120415051255}} (U)EFI Specification (englisch)</ref> schreiben ein Minimum von 16.384 Bytes für die Partitionstabelle vor, so dass es Platz für 128 Einträge gibt. Weiterhin werden der Header selbst und die Partitionseinträge mit [[CRC32]]-Prüfsummen abgesichert, die von der [[Firmware]], dem [[Bootloader]] oder dem [[Betriebssystem]] überprüft werden müssen. Wird daher der Header z. B. mit einem [[Hexeditor]] verändert, macht dies die Checksumme ungültig und das System wird instabil oder sogar unbrauchbar.

Im Header der GPT sind folgende Informationen abgelegt:
{| class="wikitable" style="text-align:right;"
|-
! Offset !! Länge !! Inhalt
|-
| 0 || 8 bytes ||style="text-align:left"| Signatur („EFI PART“, <code style="border:none;">45h 46h 49h 20h 50h 41h 52h 54h</code>)
|-
| 8 || 4 bytes ||style="text-align:left"| Revision (<code style="border:none;">00h 00h 01h 00h</code>)
|-
| 12 || 4 bytes ||style="text-align:left"| Header-Größe – [[Byte-Reihenfolge|Little Endian]] (<code style="border:none;">5Ch 00h 00h 00h</code> entspricht 92 bytes)
|-
| 16 || 4 bytes ||style="text-align:left"| Header-CRC32-Prüfsumme (von Offset 0 bis Header-Größe, dieses Feld selbst wird bei der Berechnung auf 0 gesetzt)
|-
| 20 || 4 bytes ||style="text-align:left"| Reservierter Bereich – muss Null (0) sein
|-
| 24 || 8 bytes ||style="text-align:left"| Position des eigenen LBA (dieses Headers)
|-
| 32 || 8 bytes ||style="text-align:left"| Position des Backup-LBA (des anderen Headers)
|-
| 40 || 8 bytes ||style="text-align:left"| Erster benutzbarer LBA für Partitionen (Letzter LBA der primären Partitionstabelle + 1, normalerweise 34)
|-
| 48 || 8 bytes ||style="text-align:left"| Letzter benutzbarer LBA (Erster LBA der sekundären Partitionstabelle – 1, normalerweise Datenträgergröße – 34)
|-
| 56 || 16 bytes ||style="text-align:left"| Datenträger-[[GUID]] (als Referenz siehe auch [[UUID]] bei UNIXe)
|-
| 72 || 8 bytes ||style="text-align:left"| Start-LBA der Partitionstabelle
|-
| 80 || 4 bytes ||style="text-align:left"| Anzahl der Partitionseinträge (Partitionen)
|-
| 84 || 4 bytes ||style="text-align:left"| Größe eines Partitionseintrags (normalerweise 128)
|-
| 88 || 4 bytes ||style="text-align:left"| Partitionstabellen-CRC32-Prüfsumme
|-
| 92 ||style="text-align:center"| * ||style="text-align:left"| Reservierter Bereich; muss mit Nullen, für den Rest des Blocks, belegt sein (420 Bytes bei einem 512-byte LBA)
|}

=== Partitionseintrag ===
Die Partitionseinträge werden im LBA 2 bis LBA 33 (sekundäre GPT: LBA -33 bis LBA -2) abgelegt. Jeder Partitionseintrag umfasst 128 Byte. Somit können pro logischem Block vier Partitionseinträge abgelegt werden. Diese in der Spezifikation vorgeschriebene Mindestanzahl von 32 Sektoren für Partitionseinträge kann bei Bedarf beliebig erhöht werden, so dass die maximal mögliche Anzahl an Partitionen prinzipiell nur durch den zur Verfügung stehenden Plattenplatz beschränkt wird.

Im Partitionseintrag selbst sind folgende Daten hinterlegt:
{| class="wikitable" style="text-align:right;"
|+
! Offset !! Länge !! Inhalt
|-
| 0 || 16 Bytes ||style="text-align:left"| Partitionstyp-GUID
|-
| 16 || 16 Bytes ||style="text-align:left"| Eindeutige Partitions-GUID
|-
| 32 || 8 Bytes ||style="text-align:left"| Beginn der Partition (erster LBA – Little-Endian)
|-
| 40 || 8 Bytes ||style="text-align:left"| Ende der Partition (letzter LBA – inklusive)
|-
| 48 || 8 Bytes ||style="text-align:left"| Attribute (siehe folgende Tabelle)
|-
| 56 || 72 Bytes ||style="text-align:left"| Partitionsname (36 [[UTF-16]]LE-Zeichen)
|-
| insg. || 128 Bytes ||
|}

Die einzelnen Einträge sind verhältnismäßig einfach aufgebaut. Die ersten 16 Bytes beschreiben den Partitionstyp. Die Partitionstyp-GUID für eine EFI-Systempartition ist z. B. {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}. Es folgen 16 Bytes mit der Partitions-GUID. Dann folgen die Nummer des ersten und des letzten LBA-Sektors der Partition, 8 Bytes mit Attributen und der Name der Partition (36 Unicode-Zeichen lang).

Microsoft definiert folgende Attributeinträge:
{| class="wikitable"
|+
! Bit !! Inhalt
|-
|style="text-align:right"| 0 || Systempartition
|-
|style="text-align:right"| 1 || vor EFI verstecken
|-
|style="text-align:right"| 2 || Legacy BIOS bootfähig (analog MBR <code>80h</code> Active flag)<ref>{{Internetquelle |url=http://t13.org/documents/UploadedDocuments/docs2010/e09127r3-EDD-4_Hybrid_MBR_boot_code_annex.pdf |titel=e09127r3 EDD-4 Hybrid MBR boot code annex |abruf=2023-01-17 |format=PDF; 116 kB |archiv-url=https://web.archive.org/web/20120303074339/http://t13.org/documents/UploadedDocuments/docs2010/e09127r3-EDD-4_Hybrid_MBR_boot_code_annex.pdf |archiv-datum=2012-03-03}}</ref>
|-
|style="text-align:right"| 60 || Nur lesen (Read-only)
|-
|style="text-align:right"| 62 || Versteckt (Hidden)
|-
|style="text-align:right"| 63 || Nicht automatisch mounten (= keinen Laufwerksbuchstaben zuweisen)
|}

=== {{Anker|ESP|EFI System Partition|EFI-Systempartition|EFI-System-Partition}}Systempartition ===
Für [[Bootfähiges Medium|startfähige Medien]], die zum [[Booten]] eines Systems verwendet werden können, ist eine spezielle Partition namens {{enS|EFI System Partition}}, kurz ESP, vorgesehen. Eine System-Firmware nach dem EFI-Standard sucht bei externen Medien auf der EFI-Systempartition nach Bootloadern und bietet im EFI-[[Bootmenü]] alle kompatiblen Einträge zur Auswahl an. Bei internen Startmedien, etwa der eingebauten [[Festplatte]], muss ein installiertes System den jeweiligen EFI-Bootloader im NVRAM als Eintrag hinzufügen. Der Standardeintrag lässt sich mit Dienstprogrammen verändern, im Bootmenü werden alle konfigurierten Bootloader angezeigt.

=== Partitionstyp-GUIDs ===
{| class="wikitable zebra"
|-
!colspan="2"|Partitionstyp
!rowspan="2"|ursprüngliches System
!rowspan="2" style="white-space:nowrap"|englische Bezeichnung
!rowspan="2"|Bezeichnung und Beschreibung
|-
! GPT ([[Globally Unique Identifier|GUID]], [[Hexadezimalsystem|hexadezimal]])
! MBR ([[Hexadezimalsystem|hex]])
|-
|style="white-space:nowrap"|<code>00000000-0000-0000-0000-000000000000</code>
|style="text-align:center"| 00
| GPT
| Unused entry
| Eintrag für eine unbenutzte Partition.
|-
|rowspan="14"|<code>EBD0A0A2-B9E5-4433-87C0-68B6B72699C7</code>
|style="text-align:center"| 01
|rowspan="14"|{{nowrap|[[IBM Personal Computer|IBM PC]]/}}&ZeroWidthSpace;[[IBM-PC-kompatibler Computer|kompatibel]]
|rowspan="14"|Microsoft basic data
| [[File Allocation Table#FAT12|FAT12]]
|-
|style="text-align:center"| 04
| [[File Allocation Table#FAT16|FAT16]] < 32 MB
|-
|style="text-align:center"| 06
| [[File Allocation Table#FAT16|FAT16]]
|-
|style="text-align:center"| 07
| [[NTFS]] (oder [[High Performance File System|HPFS]])
|-
|style="text-align:center"| 0b
| [[File Allocation Table#FAT32|FAT32]]
|-
|style="text-align:center"| 0c
| [[File Allocation Table#FAT32|FAT32]] [[Logical Block Addressing|LBA]]
|-
|style="text-align:center"| 0e
| [[File Allocation Table#FAT16|FAT16]] [[Logical Block Addressing|LBA]]
|-
|style="text-align:center"| 11
| [[File Allocation Table#FAT12|FAT12]] (versteckt)
|-
|style="text-align:center"| 14
| [[File Allocation Table#FAT16|FAT16]] < 32 MB (versteckt)
|-
|style="text-align:center"| 16
| [[File Allocation Table#FAT16|FAT16]] (versteckt)
|-
|style="text-align:center"| 17
| [[NTFS]] (oder [[High Performance File System|HPFS]]) (versteckt)
|-
|style="text-align:center"| 1b
| [[File Allocation Table#FAT32|FAT32]] (versteckt)
|-
|style="text-align:center"| 1c
| [[File Allocation Table#FAT32|FAT32]] [[Logical Block Addressing|LBA]] (versteckt)
|-
|style="text-align:center"| 1e
| [[File Allocation Table#FAT16|FAT16]] [[Logical Block Addressing|LBA]] (versteckt)
|-
| <code>E3C9E316-0B5C-4DB8-817D-F92DF00215AE</code>
|style="text-align:center"| 0c
| [[Microsoft Windows|Windows]] ([[Extensible Firmware Interface|EFI]])
| Microsoft reserved
| Hybrid-MBR-Typ <code>0x0c</code> entspricht dem von FAT32 LBA
|-
| <code>DE94BBA4-06D1-4D40-A16A-BFD50179D6AC</code>
|style="text-align:center"| 27
| [[Microsoft Windows|Windows]]
| [[Windows-Wiederherstellungsumgebung|Windows RE]]
| [[Wiederherstellungspartition]]<ref>[https://technet.microsoft.com/de-at/library/dd744301(v=ws.10).aspx Empfohlene Konfigurationen für UEFI-basierte Datenträgerpartitionen] unter Windows 7 und Windows Server 2008 R2. Microsoft TechNet; abgerufen am 7. Juli 2015</ref> mit [[Windows-Wiederherstellungsumgebung|Windows Recovery Environment]]<ref>[https://technet.microsoft.com/de-at/library/cc765966(v=ws.10).aspx Was ist Windows RE?] Microsoft TechNet; abgerufen am 4. Juli 2015</ref> (ab [[Microsoft Windows Vista|Vista]], basiert auf [[Microsoft Windows PE|Windows PE]])
|-
| <code>7412F7D5-A156-4B13-81DC-867174929325</code>
|rowspan="2" style="text-align:center"| 30, e1
|rowspan="2"| ONIE
| ONIE boot
|rowspan="2"| Open Network Install Environment (ONIE)<ref name="onieblkdev">{{Toter Link |date=2018-04 |url=https://github.com/onie/onie/blob/master/rootconf/x86_64/sysroot-lib-onie/onie-blkdev-common }}</ref><ref>[http://www.onie.org/ onie.org]</ref>
|-
| <code>D4E6E2CD-4469-46F3-B5CB-1BFF57AFC149</code>
| ONIE config
|-
| <code>C91818F9-8025-47AF-89D2-F030D7000C2C</code>
|style="text-align:center"| 39
| [[Plan 9 (Betriebssystem)|Plan 9]]
| Plan 9
| Vom Betriebssystem Plan 9 verwendete Partition.<ref>[http://man.cat-v.org/9front/8/prep man.cat-v.org]</ref>
|-
| <code>9E1A2D38-C612-4316-AA26-8B49521E5A8B</code>
|style="text-align:center"| 41
| [[PowerPC Reference Platform|PReP]]
| [[PowerPC]] PReP boot
| PReP war der Vorläufer von CHRP bzw. der [[PowerPC Platform]].
|-
| <code>AF9B60A0-1431-4F62-BC68-3311714A69AD</code>
|rowspan="3" style="text-align:center"| 42
|rowspan="3"| [[Microsoft Windows|Windows]]
| Windows LDM data
|rowspan="3"| Der {{lang|en|Logical Disk Manager}} (LDM) ist die Umsetzung eines {{lang|en|[[Logical Volume Manager]]}} unter [[Microsoft Windows NT|Windows NT]], der in Windows 2000 bis Windows 7 vorhanden ist. Ab Windows 8 ist dessen Nachfolger {{lang|en|Storage Spaces}} enthalten.
|-
| <code>5808C8AA-7E8F-42E0-85D2-E1E90434CFB3</code>
| Windows LDM metadata
|-
| <code>E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D</code>
| Windows Storage Spaces
|-
| <code>37AFFC90-EF7D-4E96-91C3-2D7AE055B174</code>
|style="text-align:center"| 75
|
| IBM GPFS
| [[General Parallel File System]] (GPFS)
|-
|style="white-space:nowrap"| <code>FE3A2A5D-4F32-41A7-B725-ACCC3285A309</code>
|rowspan="3" style="text-align:center"| 7f
|rowspan="3"| [[Chromebook]]
| ChromeOS [[Kernel (Betriebssystem)|kernel]]
|rowspan="3"| [[Google Chrome OS]]<ref name="ChromeOSsrcgpth">vboot_reference/firmware/lib/cgptlib/include/gpt.h, ChromeOS-Quelltext von 23. Dezember 2010</ref><ref name="chromiumos-diskformat">[http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format chromium.org]</ref>
|-
| <code>3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC</code>
| ChromeOS [[Stammverzeichnis|root]]
|-
| <code>2E0A753D-9E48-43B0-8337-B15192CB1B5E</code>
| ChromeOS reserved
|-
| <code>0657FD6D-A4AB-43C4-84E5-0933C84B4F4F</code>
|style="text-align:center"| 82
|rowspan="3"| [[Linux]]
| Linux [[Auslagerungsdatei|swap]]
| [[Auslagerungsdatei|Auslagerungspartition]] von Linux. Auch Solaris verwendet auf MBR-Partitionen den Typ <code>0x82</code> als [[Swapping|swap]].
|-
| <code>0FC63DAF-8483-4772-8E79-3D69D8477DE4</code>
|rowspan="2" style="text-align:center"| 83
| Linux filesystem
| Dieser Partitionstyp wird auch als “Linux native” bezeichnet.
|-
| <code>8DA63339-0007-60C0-C436-083AC8230908</code>
| Linux reserved
| Der Hybrid-MBR-Typ entspricht dem von “Linux native”, <code>0x83</code>.
|-
| <code>933AC7E1-2EB4-4F13-B844-0E14E2AEF915</code>
|rowspan="8" style="text-align:center"| 83
|rowspan="9"| [[freedesktop.org]] (Linux)
| Linux [[Benutzerverzeichnis|/home]]
|rowspan="4"| auto-mount für [[systemd]] von freedesktop.org<ref name="systemd-gpt-auto">[http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html freedesktop.org]</ref><ref name="DiscoverablePartitionsSpec">[http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ freedesktop.org]</ref>
|-
| <code>3B8F8425-20E0-4F3B-907F-1A25A76F98E8</code>
| Linux /srv
|-
| <code>7FFEC5C9-2D00-49B7-8941-3EA10A5586B7</code>
| Linux [[dm-crypt]]
|-
| <code>CA7D7CCB-63ED-4C53-861C-1742536059CC</code>
| Linux [[Linux Unified Key Setup|LUKS]]
|-
| <code>44479540-F297-41B2-9AF7-D131D5F0458A</code>
| Linux [[IA-32|x86]]
| [[Stammverzeichnis|root]]-Partition auf [[32-Bit-Architektur|32-Bit]]-[[x86-Prozessor|x86]]-Systemen ([[IA-32]]).
|-
| <code>4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709</code>
| Linux [[x64|x86-64]]
| [[Stammverzeichnis|root]]-Partition auf [[64-Bit-Architektur|64-Bit]]-[[x86-Prozessor|x86]]-Systemen ([[IA-32]] im [[x64]]-Modus).
|-
| <code>69DAD710-2CE4-4E3C-B16C-21A1D49ABED3</code>
| Linux [[ARM-Architektur|ARM32]]
| [[Stammverzeichnis|root]]-Partition auf [[32-Bit-Architektur|32-Bit]]-[[ARM-Architektur|ARM]]-Systemen.
|-
| <code>B921B045-1DF0-41C3-AF44-4C6F280D3FAE</code>
| Linux [[ARM-Architektur|ARM64]]
| [[Stammverzeichnis|root]]-Partition auf [[64-Bit-Architektur|64-Bit]]-[[ARM-Architektur|ARM]]-Systemen (ARMv8).
|-
| <code>993d8d3d-f80e-4225-855a-9daf8ed7ea97</code>
| –
| Linux [[Itanium-Architektur|IA-64]]
| [[Stammverzeichnis|root]]-Partition auf [[Itanium-Architektur|Itanium]]-Systemen (IA-64).
|-
| <code>D3BFE2DE-3DAF-11DF-BA40-E3A556D89593</code>
|style="text-align:center"| 84
| [[Intel]]-[[IBM-PC-kompatibler Computer|PC]]
| Intel Rapid Start
| Was als ''Intel Rapid Start Technology'' bezeichnet wird, ist eigentlich eine Mischform aus [[Bereitschaftsbetrieb]] (S3, {{lang|en|“suspend to RAM”}}) und [[Ruhezustand]] (S4, {{lang|en|“suspend to disk”}}).<ref>[[c’t]] Hotline: [http://heise.de/-2132476 Was ist „Rapid Start Technology“?] aus Heft 7/2014, abgerufen am 9. Juli 2015</ref>
|-
| <code>E6D6D379-F507-44C2-A23C-238F2A3DF928</code>
|style="text-align:center"| 8e
| [[Linux]]
| Linux LVM
| [[Logical Volume Manager]]
|-
|rowspan="3"| <code>734E5AFE-F61A-11E6-BC64-92361F002671</code>
|rowspan="3" style="text-align:center"| -
|rowspan="3"| [[TOS (Betriebssystem)|Atari TOS]]
|rowspan="3"| TOS basic data
| [[File Allocation Table#FAT16|FAT16]] < 32 MB, <code>'GEM'</code>
|-
| [[File Allocation Table#FAT16|FAT16]], <code>'BGM'</code>
|-
| [[File Allocation Table #FAT32|FAT32]], <code>'F32'</code>
|-
| <code>35540011-B055-499F-842D-C69AECA357B7</code>
|style="text-align:center"| -
| [[TOS (Betriebssystem)|Atari TOS]]
| TOS raw data
| XHDI-Typ <code>'RAW'</code>, Details s. XHDI-Spezifikation
|-
| <code>516E7CB4-6ECF-11D6-8FF8-00022D09712B</code>
|rowspan="6" style="text-align:center"| a5
|rowspan="6"| [[FreeBSD]]
| FreeBSD [[Disklabel]]
|
|-
| <code>83BD6B9D-7F41-11DC-BE0B-001560B84F0F</code>
| FreeBSD boot
|
|-
| <code>516E7CB5-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>516E7CB6-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[Unix File System|UFS]]
|
|-
| <code>516E7CBA-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD [[ZFS (Dateisystem)|ZFS]]
|
|-
| <code>516E7CB8-6ECF-11D6-8FF8-00022D09712B</code>
| FreeBSD Vinum/[[RAID]]
|
|-
| <code>85D5E45A-237C-11E1-B4B3-E89A8F7FC3A7</code>
|rowspan="6" style="text-align:center"| a5
|rowspan="6"| [[MidnightBSD]]
| MidnightBSD data
|
|-
| <code>85D5E45E-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD boot
|
|-
| <code>85D5E45B-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>0394EF8B-237E-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[Unix File System|UFS]]
|
|-
| <code>85D5E45D-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD [[ZFS (Dateisystem)|ZFS]]
|
|-
| <code>85D5E45C-237C-11E1-B4B3-E89A8F7FC3A7</code>
| MidnightBSD Vinum
|
|-
| <code>824CC7A0-36A8-11E3-890A-952519AD3F61</code>
|style="text-align:center"| a6
| [[OpenBSD]]
| OpenBSD data
|
|-
| <code>55465300-0000-11AA-AA11-00306543ECAC</code>
|style="text-align:center"| a8
| [[macOS|Mac OS X]]
| Apple [[Unix File System|UFS]]
| Partition, die ein [[Unix File System]] enthält. Entspricht dem [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_UFS</code>.
|-
| <code>516E7CB4-6ECF-11D6-8FF8-00022D09712B</code>
|rowspan="7" style="text-align:center"| a9
| [[FreeBSD]]
| FreeBSD [[Disklabel]]
| FreeBSD, NetBSD, OpenBSD (unter OpenBSD wird MBR-Typ <code>0xa6</code> verwendet<ref name="gptfdisk" />)
|-
| <code>49F48D32-B10E-11DC-B99B-0019D1879648</code>
|rowspan="6"| [[NetBSD]]
| NetBSD [[Auslagerungsdatei|swap]]
|
|-
| <code>49F48D5A-B10E-11DC-B99B-0019D1879648</code>
| NetBSD FFS
|
|-
| <code>49F48D82-B10E-11DC-B99B-0019D1879648</code>
| NetBSD LFS
|
|-
| <code>2DB519C4-B10F-11DC-B99B-0019D1879648</code>
| NetBSD concatenated
|
|-
| <code>2DB519EC-B10F-11DC-B99B-0019D1879648</code>
| NetBSD encrypted
|
|-
| <code>49F48DAA-B10E-11DC-B99B-0019D1879648</code>
| NetBSD [[RAID]]
|
|-
| <code>426F6F74-0000-11AA-AA11-00306543ECAC</code>
|style="text-align:center"| ab
|rowspan="12"| [[macOS]]
| Apple boot
| [[Wiederherstellungspartition]] seit [[Mac OS X Lion]] (10.7, 2011). Enthält ein [[HFS Plus|HFS+]]- oder [[Apple File System|APFS]]-Dateisystem und heißt normalerweise <code>Recovery HD</code>, ist jedoch versteckt.
|-
| <code>48465300-0000-11AA-AA11-00306543ECAC</code>
|rowspan="11" style="text-align:center"| af
| Apple [[HFS (Dateisystem)|HFS]]/[[HFS Plus|HFS+]]
| Partition für das Dateisystem [[HFS Plus|HFS+]], entspricht [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_HFSX</code>. Das ältere [[HFS (Dateisystem)|Hierarchical File System (HFS)]], [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_HFS</code>, findet auf GPT-Partitionen normalerweise keine Verwendung mehr.
|-
| <code>52414944-0000-11AA-AA11-00306543ECAC</code>
| Apple [[RAID]]
| Beherbergt eine Partition aus einem [[RAID]]-Verbund. Entspricht dem [[Apple Partition Map|APM]]-Partitionstyp <code>Apple_RAID</code>.
|-
| <code>52414944-5F4F-11AA-AA11-00306543ECAC</code>
| Apple [[RAID]] offline
| Beherbergt eine aus einem [[RAID]]-Verbund entfernte Partition.
|-
| <code>4C616265-6C00-11AA-AA11-00306543ECAC</code>
| Apple Label
| {{lang|en|“Apple Label”}} ist eine [[Disklabel]]-Variante für [[macOS|Mac OS X]].<ref>Apple Developer: [https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/disklabel.8.html disklabel man page] (englisch), abgerufen am 12. Juli 2015</ref>
|-
| <code>5265636F-7665-11AA-AA11-00306543ECAC</code>
| AppleTV Recovery
| Das [[Apple TV]] verwendet ein Betriebssystem auf Basis von Mac OS X mit einer für Fernseher optimierten Benutzeroberfläche.
|-
| <code>53746F72-6167-11AA-AA11-00306543ECAC</code>
| Apple Core Storage
| Eine ''Core-Storage''-Partition für [[FileVault]] 2 (verschlüsselt). Apple [[Fusion Drive]] verwendet ebenfalls eine Partition dieses Typs.
|-
| <code>B6FA30DA-92D2-4A9A-96F1-871EC6486200</code>
| Apple SoftRAID Status
|rowspan="4"| Apple SoftRAID-Partition.
|-
| <code>2E313465-19B9-463F-8126-8A7993773801</code>
| Apple SoftRAID Scratch
|-
| <code>FA709C7E-65B1-4593-BFD5-E71D61DE9B02</code>
| Apple SoftRAID Volume
|-
| <code>BBBA6DF5-F46F-4A89-8F59-8765B2727503</code>
| Apple SoftRAID Cache
|-
| <code>7C3457EF-0000-11AA-AA11-00306543ECAC</code>
| Apple [[Apple File System|APFS]]
| Partition für das Dateisystem [[Apple File System|APFS]], dem Nachfolger von [[HFS Plus|HFS+]] auf [[macOS]].
|-
| <code>CEF5A9AD-73BC-4601-89F3-CDEEEEE321A1</code>
|style="text-align:center"| b3
| [[QNX]]
| QNX6 Power-Safe
|
|-
| <code>0311FC50-01CA-4725-AD77-9ADBB20ACE98</code>
|style="text-align:center"| bc
| [[Acronis]]
| Acronis Secure Zone
|
|-
| <code>6A82CB45-1DD2-11B2-99A6-080020736631</code>
|style="text-align:center"| be
|rowspan="13"| [[Solaris (Betriebssystem)|Solaris]]
| Solaris boot
|
|-
| <code>6A85CF4D-1DD2-11B2-99A6-080020736631</code>
|rowspan="7" style="text-align:center"| bf
| Solaris [[Stammverzeichnis|root]]
|
|-
| <code>6A898CC3-1DD2-11B2-99A6-080020736631</code>
| Solaris /usr
| Beherbergt bis Solaris 9 üblicherweise das Dateisystem [[Unix File System|UFS]] und ab Solaris 10 [[ZFS (Dateisystem)|ZFS]]. MacZFS<ref>[http://code.google.com/p/maczfs/ MacZFS.org: Official Site for the Free ZFS for Mac OS] (englisch), abgerufen am 9. Juli 2015</ref> verwendet dieselbe GUID.
|-
| <code>6A87C46F-1DD2-11B2-99A6-080020736631</code>
| Solaris [[Auslagerungsdatei|swap]]
|
|-
| <code>6A8B642B-1DD2-11B2-99A6-080020736631</code>
| Solaris backup
|
|-
| <code>6A8EF2E9-1DD2-11B2-99A6-080020736631</code>
| Solaris /var
|
|-
| <code>6A90BA39-1DD2-11B2-99A6-080020736631</code>
| Solaris [[Benutzerverzeichnis|/home]]
|
|-
| <code>6A9283A5-1DD2-11B2-99A6-080020736631</code>
| Solaris alternate sector
|
|-
| <code>6A945A3B-1DD2-11B2-99A6-080020736631</code>
|rowspan="5" style="text-align:center"| bf
|rowspan="5"| Solaris Reserved
|rowspan="5"|
|-
| <code>6A9630D1-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A980767-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A96237F-1DD2-11B2-99A6-080020736631</code>
|-
| <code>6A8D2AC7-1DD2-11B2-99A6-080020736631</code>
|-
| <code>75894C1E-3AEB-11D3-B7C1-7B03A0000000</code>
|rowspan="2" style="text-align:center"| c0
|rowspan="2"| [[HP-UX]]
| HP-UX data
|
|-
| <code>E2A1E728-32E3-11D6-A682-7B03A0000000</code>
| HP-UX service
|
|-
| <code>BC13C2FF-59E6-4262-A352-B275FD6F7172</code>
|style="text-align:center"| ea
| [[freedesktop.org]]
| Freedesktop $BOOT
| <ref name="DiscoverablePartitionsSpec" />
|-
| <code>42465331-3BA3-10F1-802A-4861696B7521</code>
|style="text-align:center"| eb
| [[Haiku (Betriebssystem)|Haiku]]
| Haiku [[Be File System|BFS]]
| Obwohl [[BeOS]] selbst keine GUID-Partitionstabelle unterstützte, wird diese Partition von dessen Weiterentwicklung Haiku für ein ''[[Be File System]]'' verwendet.
|-
| <code>BFBFAFE7-A34F-448A-9A5B-6213EB736C22</code>
|rowspan="2" style="text-align:center"| ed
|rowspan="2"| ESP, herstellerspezifisch
| [[Lenovo]] system partition
|rowspan="2"| Herstellerspezifische {{lang|en|EFI System Partition}} (ESP), die von der spezifischen Firmware (UEFI) als ESP identifiziert wird.
|-
| <code>F4019732-066E-4E12-8273-346C5641494F</code>
| [[Sony]] system partition
|-
| <code>C12A7328-F81F-11D2-BA4B-00A0C93EC93B</code>
|rowspan="3" style="text-align:center"| ef
|rowspan="3"| EFI
| EFI System (ESP)
| Diese Partition wird als [[#EFI System Partition|{{lang|en|EFI System Partition}}]] (ESP) bezeichnet. Sie enthält ein FAT-Dateisystem, von dem die Firmware eine ausführbare Datei ([[Portable Executable|PE]]/[[Common Object File Format|COFF]]), z. B. <code>\EFI\BOOT\BOOTX64.EFI</code>, lädt und ausführt. Unter <code>[[GNU Parted|parted]]</code> wird diese Partition mit {{lang|en|“boot flag”}}, also als [[Startpartition]], angezeigt.<ref>[http://www.rodsbooks.com/efi-bootloaders/principles.html Managing EFI Boot Loaders for Linux: Basic Principles] (englisch), Rod Smith, abgerufen am 9. Juli 2015</ref>
|-
| <code>024DEE41-33E7-11D3-9D69-0008C781F39F</code>
| MBR partition scheme
| Diese Partition enthält eine eingebettete vollständige MBR-Partitionstabelle samt Partitionen. Da die enthaltenen Partitionen jedoch keine Hybrid-Partitionen sind, kann darauf nicht aus der GUID-Partitionstabelle zugegriffen werden. Doch ist es damit möglich, eine Partition zu [[Virtualisierung (Informatik)|Virtualisierungszwecken]] an eine [[Virtuelle Maschine]] durchzureichen, die darauf eine vollständige MBR-Partitionstabelle einrichtet und verwendet.
|-
| <code>21686148-6449-6E6F-744E-656564454649</code>
| BIOS boot partition
| Eine Partition, die von [[Grand Unified Bootloader|GRUB]] zum Starten auf [[BIOS (IBM PC)|BIOS]]-basierten [[IBM-PC-kompatibler Computer|PCs]] verwendet wird. Die GUID liest sich <code>!haHdInotNeedEFI</code> in [[Hexadezimal]]darstellung (was in der benötigten [[Little Endian|Little-Endian]]-Form im GPT dann „Hah!IdontNeedEFI“ ergibt).
|-
| <code>4FBD7E29-9D25-41B8-AFD0-062C0CEFF05D</code>
|rowspan="6" style="text-align:center"| f8
|rowspan="6"| [[Ceph]]<ref>[https://github.com/ceph/ceph/blob/9bcc42a3e6b08521694b5c0228b2c6ed7b3d312e/src/ceph-disk#L76-L81 github.com]</ref>
| Ceph OSD
| Ceph Object Storage Daemon
|-
| <code>4FBD7E29-9D25-41B8-AFD0-5EC00CEFF05D</code>
| Ceph [[dm-crypt]] OSD
| Ceph Object Storage Daemon (verschlüsselt)
|-
| <code>45B0969E-9B03-4F30-B4C6-B4B80CEFF106</code>
| Ceph journal
|
|-
| <code>45B0969E-9B03-4F30-B4C6-5EC00CEFF106</code>
| Ceph [[dm-crypt]] journal
|
|-
| <code>89C57F98-2FE5-4DC0-89C1-F3AD0CEFF2BE</code>
| Ceph disk in creation
|
|-
| <code>89C57F98-2FE5-4DC0-89C1-5EC00CEFF2BE</code>
| Ceph [[dm-crypt]] disk in creation
|
|-
| <code>AA31E02A-400F-11DB-9590-000C2911D1B8</code>
|rowspan="2" style="text-align:center"| fb
|rowspan="3"| [[VMware]] ESX
| VMware VMFS
|
|-
| <code>9198EFFC-31C0-11DB-8F78-000C2911D1B8</code>
| VMware reserved
|
|-
| <code>9D275380-40AD-11DB-BF97-000C2911D1B8</code>
|style="text-align:center"| fc
| VMware kcore crash protection
|
|-
| <code>A19D880F-05FC-4D3B-A006-743F0F84911E</code>
|style="text-align:center"| fd
| [[Linux]]
| Linux [[RAID]]
|
|-
|<code>3F82EEBC-87C9-4097-8165-89D6540557C0</code>
|76
|Emu68/[[AmigaOS]]
|[[Rigid Disk Block]]
|Diese Partition enthält eine eingebettete, vollständige AmigaOS-RDB-Partitionstabelle einschließlich aller Partitionen. Aufgrund der Einschränkungen der RDB darf die Größe dieser Partition 2 TiB nicht überschreiten.
|}

Da bei vielen Systemen eine Überführung von MBR- in GUID-Partitionen möglich ist, gibt es für viele GUID-Partitionstypen einen entsprechenden MBR-Partitionstyp. Auch bei der Verwendung von Hybrid-MBRs werden die entsprechenden Partitionen einmal mit GUID- und einmal mit dazu passendem MBR-Partitionstyp erstellt.

== Konvertierung ==
Es besteht grundsätzlich die Möglichkeit, von der Master-Boot-Record-Partitionstabelle zur GUID-Partitionstabelle zu konvertieren, jedoch wird dabei genügend freier Platz zwischen MBR und erster Partition sowie nach der letzten Partition vorausgesetzt, um die nötige Datenstruktur für die GUID-Partitionstabelle aufnehmen zu können. Unter anderem das Programm ''GPT fdisk'' (besser bekannt als <code>gdisk</code>) bietet diese Möglichkeit.<ref name="gptfdisk_mbr2gpt" /> Auch die Überführung von einigen BSD-Disklabel-Partitionen in GPT ist damit möglich.

== Begrenzungen ==
Die GPT verwendet [[Logical Block Addressing]] (LBA) mit 64 Bit umfassenden Einträgen, sodass – bei einer Sektorengröße von 512 Byte – Festplatten bis zu einer Gesamtkapazität von 8 [[Zebibyte]] adressiert werden können. Die maximale Anzahl möglicher Partitionen hängt von der Größe der Partitionstabelle ab, die laut Spezifikation mindestens für 128 Partitionen Platz bietet. Nicht alle Systeme bieten diese Möglichkeit, jedoch kann z. B. das Partitionierungswerkzeug <code>gdisk</code> eine größere Partitionstabelle erzeugen.<ref>{{Internetquelle |url=http://www.uefi.net/2015/01/guid-partition-table.html |titel=GUID Partition Table |hrsg=UEFI Support |datum=2015-01-26 |format=[[Blog]] |sprache=en |abruf=2018-12-23 |zitat=Advantages of GPT; 3. Arbitrary number of partitions - depends on space allocated for the partition table … By default the GPT table contains space for defining 128 partitions. However if the user wants to define more partitions, he/she can allocate more space to the partition table (currently only gdisk is known to support this feature).}}</ref>

== Hybrid-MBR ==
Ein Hybrid-MBR bezeichnet das Definieren einzelner Partitionen sowohl in der GUID-Partitionstabelle (GPT) als auch in der Partitionstabelle des [[Master Boot Record|Master Boot Record (MBR)]]. Ein Zugriff auf die Partitionen ist dadurch sowohl über GPT als auch über MBR möglich, was [[Multi-Boot-System|Dual-Boot]] zwischen Betriebssystemen ermöglicht, die nur jeweils eine der beiden Partitionstabellen verwenden oder unterstützen.

Im MBR ist normalerweise nur eine den gesamten Datenbereich umfassende Schutzpartition enthalten, was als Schutz-MBR ({{enS|“protective MBR”}}) bezeichnet wird. Bei Hybrid-Partitionierung wird ein und dieselbe Partition sowohl in der GUID- als auch in der MBR-Partitionstabelle definiert: da der Master Boot Record dabei als [[Hybrid]] der eigentlichen GUID-Partitionstabelle auftritt, wird in diesem Fall die Bezeichnung „Hybrid-MBR“ verwendet.

Die Gefahr bei der Hybrid-Partitionierung ist, dass das Verändern nur einer der beiden Partitionstabellen zu groben Partitionierungsfehlern führen kann. Daher muss eine Hybrid-Partitionierung durch dafür vorgesehene Programme erfolgen und darf keinesfalls über Partitionierungswerkzeuge eines Betriebssystems, welches nur eine der beiden Partitionstabellen verwendet, verändert werden.

Die Anzahl der Hybrid-Partitionen ist auf vier gemeinsame Partitionen beschränkt. Das Definieren einer erweiterten MBR-Partition ist nicht möglich, da GPT keine erweiterten Partitionen unterstützt. Umgekehrt gibt es nur Platz für insgesamt vier primäre Partitionen in der Partitionstabelle des Master Boot Record. Da für EFI eine primäre Partition benötigt wird – die EFI System Partition (ESP) – stehen drei Hybrid-Partitionen für Betriebssysteme oder gemeinsame Datenpartitionen zur Verfügung. Es ist die einzig sichere Lösung, mit maximal vier Hybrid-Partitionen (inklusive der ESP) den gesamten nutzbaren Speicherplatz zu partitionieren.

Mit manueller Partitionierung ist es dennoch möglich, nicht alle Partitionen als Hybrid-Partition abzubilden: dann kann zwar das Betriebssystem, das nur den MBR auswertet, nicht auf alle Partitionen zugreifen, jedoch ermöglicht es ausreichend viele gemeinsame Partitionen für einen Dual-Boot-Betrieb. Allerdings fällt in einer solchen Konfiguration der Schutz für GUID-Partitionen, welche nicht auch als MBR-Partitionen existieren, weg. Das Betriebssystem, das nur den MBR auswertet, sieht weiteren vermeintlich unpartitionierten und somit leeren Speicherplatz, der von keiner der MBR-Partitionen beansprucht wird. Es ist Sache des Anwenders, dem Betriebssystem nicht zu gestatten, von diesem Speicherplatz Gebrauch zu machen, da dieser in Wirklichkeit von weiteren GUID-Partitionen genutzt wird, somit Daten enthält und ein irrtümliches Überschreiben zu Datenverlust innerhalb der GUID-Partitionen führt.

Apple nutzt unter [[macOS]] (bis 2016 „OS X“ und bis 2012 „Mac OS X“) mit [[Boot Camp (Software)|Boot Camp]] einen Hybrid-MBR. Wenn Windows gestartet wird, dann geschieht dies über ein {{lang|en|Compatibility Support Module}} (CSM) der Apple-EFI-Firmware, sodass Windows wie bei einem [[IBM-PC-kompatibler Computer|PC]] mit [[BIOS (IBM PC)|BIOS]] die MBR-Partitionstabelle verwendet, nicht aber die GUID-Partitionstabelle. Wird jedoch macOS gestartet, so wird die GUID-Partitionstabelle genutzt. Das [[Festplattendienstprogramm (Apple)|Festplattendienstprogramm]] von macOS erstellt automatisch einen Hybrid-MBR, sobald eine der Partitionen mit einem FAT32-Dateisystem formatiert wird und nicht mehr als insgesamt vier Partitionen auf dem Datenträger vorhanden sind.

== Unterstützung in Betriebssystemen ==
Für Betriebssysteme, die auf der [[Itanium-Architektur]] (auch IA-64 für {{enS|Intel Architecture 64-Bit}}) aufbauen, ist die Unterstützung von GPT zwingend notwendig, da diese Rechner das [[Extensible Firmware Interface]] (EFI) verwenden. Neben den entsprechenden Itanium-Versionen von [[FreeBSD]], [[HP-UX]], [[Linux]], [[NetBSD]], [[OpenVMS]], [[Solaris (Betriebssystem)|Solaris]] und [[Microsoft Windows|Windows]] wird seit der Ablöse des [[BIOS (IBM PC)|PC-BIOS]] durch das [[Unified Extensible Firmware Interface]] (UEFI) auch von allen 64-Bit-PC-Betriebssystemen, „[[x64]]“ bzw. „[[x86-Architektur|x86]]-64“, die GUID-Partitionstabelle unterstützt. Da ab ca. 2005 zunehmend UEFI das PC-BIOS auch auf 32-Bit-[[x86-Prozessor]]en „[[IA-32]]“ ersetzte (wenn auch mit dem BIOS-Kompatibilitätsmodul „CSM“), unterstützen auch die 32-Bit-Varianten der PC-Betriebssysteme GPT, wenn auch oft nicht als [[Systemlaufwerk]] zum [[Booten|Starten]].

Seit der Umstellung der [[Apple]]-[[Macintosh]]-Rechner auf Intel-Prozessoren Anfang 2006 verwendet [[macOS|Mac OS X]] (seit 2016 „macOS“) ebenfalls GPT, da Intel-basierte Macs eine Apple-eigene EFI-Variante verwenden. [[Mac OS X Tiger]] (10.4, 2005) und neuer kann jedoch auch auf der PowerPC-Plattform GPT-Medien verwenden, Firmware-bedingt aber nicht davon [[Booten|starten]].

Die Versionen von [[Microsoft Windows XP|Windows XP]], die noch für die 32-Bit-Intel i386-Architektur entwickelt wurden, können dagegen auf einer GPT-Festplatte nur mit Einschränkungen installiert und betrieben werden. Unter anderem lesen sie nur den MBR, nicht aber die GPT, um Partitionierungsdaten zu erhalten. Durch die Verwendung von hybriden Partitionstabellen können die jeweiligen Partitionen sowohl als MBR- als auch als GPT-Partition eingerichtet werden, allerdings stehen im MBR maximal drei primäre Partitionen zur Verfügung, da dieser nicht mehr als vier Einträge zulässt und die erste Partition bereits für die EFI-Firmware reserviert ist. Umgekehrt werden erweiterte Partitionen des MBR, die als Container mehrere logische Partitionen enthalten können, von GPT nicht mehr unterstützt.

Bis zum Erscheinen von [[Microsoft Windows Vista|Windows Vista]] Anfang 2007 richteten sich die 64-Bit-Windows-Versionen vornehmlich an Server-Betreiber und professionelle Anwender (z. B. CAD oder Grafik/Design). Dazu zählt auch die bereits 2005 erschienene [[Microsoft Windows XP Professional x64 Edition|Windows XP Professional x64 Edition]]. Bei deren Erscheinen war die umfassende GPT-Unterstützung durch entsprechende 64-Bit-Treiber nur bei ausgesuchter Hardware vorhanden. Mit Erscheinen von Vista wurde die Verfügbarkeit von 64-Bit-Treibern generell besser, sodass diese in der Regel ebenfalls die x64-Version von XP unterstützen.

Das Fachmagazin [[c’t]] konnte in der Anfangsphase der Einführung während des Tests einer 4 TB großen mit GPT partitionierten Festplatte feststellen, dass zahlreiche Festplattentreiber namhafter Hersteller beim Schreiben auf Bereiche jenseits von 2 TB die Daten statt an der gewünschten Stelle am Anfang der Festplatte ablegten, so dass es zu massiven Datenverlusten oder gar zum Verlust der Formatierung der Festplatte kam.<ref>''RAID-System: 4 TByte in einem Gehäuse'', In: c’t Nr. 2/2009, S. 54</ref> Das Problem trat anscheinend speziell bei den 32-Bit-Versionen von Windows XP auf, die zwar teilweise schon Unterstützung für GPT mit sich führten, jedoch aufgrund ihres 32-Bit-Treiberdesigns bei der früher üblichen physischen Sektor-Größe von 512 Byte die 2-TB-Grenze nicht überschreiten konnten.<ref>Microsoft TechNet: [http://technet.microsoft.com/de-de/library/cc773223.aspx GUID-Partitionstabelle]</ref> Da der Einsatz solcher Partitionen damals noch hauptsächlich bei Servern anzutreffen war, ergaben sich diese Probleme am ehesten dann, wenn die Festplatten eines solchen Systems mit anderen Rechnern ausgetauscht wurden.

Ein 64-Bit-[[Linux]] kann – ganz ohne UEFI oder gesonderte BIOS-Unterstützung – mit [[GRUB2]] von einer GPT-Partition booten. Es ist also kein UEFI dazu notwendig – die Kopplung von GPT an (U)EFI ist somit nicht zwingend.<ref name="LinuxGPTBoot" />

[[OpenBSD]] unterstützt die Installation auf einer GPT-Partition eines [[x64|x86_64]]-[[UEFI]]-Systems seit Version 5.9<ref>{{cite web|title=OpenBSD 5.9|url=https://www.openbsd.org/59.html|language=en}}</ref>.

== Weblinks ==
* [https://thestarman.pcministry.com/asm/mbr/GPT.htm An Examination of The Microsoft® Windows™ 7, 8 and 10 GPT 'Protective' MBR and EFI Partitions] (englisch)

== Einzelnachweise ==
<references>
<ref name="gptfdisk">
[http://sourceforge.net/projects/gptfdisk/ gptfdisk] auf sourceforge.com (englisch); abgerufen am 4. Juli 2015
</ref>
<ref name="gptfdisk_mbr2gpt">
[http://www.rodsbooks.com/gdisk/mbr2gpt.html Converting to or from GPT.] Rod Smith (englisch); abgerufen am 12. Juli 2015
</ref>
</references>

{{Navigationsleiste Partitionstabellen}}

[[Kategorie:Partitionsschema]]
[[Kategorie:Betriebssystemkomponente]]