UEFI-Firmware erkennt GPT-Partitionstabelle nicht

Die UEFI-Firmware meines ASRock FM2A75 Pro4 erkennt die GPT-Partitionstabellen meiner SATA-Festplatten nicht, wie der mapEFI-Shell-Befehl zeigt:

Device mapping table
  fs0     :Removable HardDisk - Alias hd15f0b blk0 
           PciRoot(0x0)/Pci(0x13,0x2)/USB(0x5,0x0)/HD(1,MBR,0x599b0b48,0x800,0x771800)
  blk0    :Removable HardDisk - Alias hd15f0b fs0 
           PciRoot(0x0)/Pci(0x13,0x2)/USB(0x5,0x0)/HD(1,MBR,0x599b0b48,0x800,0x771800)
  blk1    :HardDisk - Alias (null)
           PciRoot(0x0)/Pci(0x11,0x0)/Sata(0x1,0x0)/HD(1,MBR,0x00000000,0x1,0xffffffff)
  blk2    :HardDisk - Alias (null)
           PciRoot(0x0)/Pci(0x11,0x0)/Sata(0x2,0x0)/HD(1,MBR,0x00000000,0x1,0xffffffff)
  blk3    :BlockDevice - Alias (null)
           PciRoot(0x0)/Pci(0x11,0x0)/Sata(0x0,0x0)
  blk4    :BlockDevice - Alias (null)
           PciRoot(0x0)/Pci(0x11,0x0)/Sata(0x1,0x0)
  blk5    :BlockDevice - Alias (null)
           PciRoot(0x0)/Pci(0x11,0x0)/Sata(0x2,0x0)
  blk6    :Removable BlockDevice - Alias (null)
           PciRoot(0x0)/Pci(0x13,0x2)/USB(0x5,0x0)
  hd15f0b :Removable HardDisk - Alias fs0 blk0 
           PciRoot(0x0)/Pci(0x13,0x2)/USB(0x5,0x0)/HD(1,MBR,0x599b0b48,0x800,0x771800)

Ein Dump des Anfangs der ersten Platte lautet:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  45 46 49 20 50 41 52 54  00 00 01 00 00 02 00 00  |EFI PART........|
00000210  fc 8c f5 67 00 00 00 00  01 00 00 00 00 00 00 00  |...g............|
00000220  af d9 30 46 02 00 00 00  00 08 00 00 00 00 00 00  |..0F............|
00000230  8e d9 30 46 02 00 00 00  4d a7 05 30 c3 6b 10 4a  |..0F....M..0.k.J|
00000240  b3 de d9 8b 01 7f bd 45  02 00 00 00 00 00 00 00  |.......E........|
00000250  80 00 00 00 80 00 00 00  e2 cd 84 66 00 00 00 00  |...........f....|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  28 73 2a c1 1f f8 d2 11  ba 4b 00 a0 c9 3e c9 3b  |(s*......K...>.;|
00000410  f2 68 35 6f f8 53 5f 40  b4 91 e5 eb e1 76 6a f9  |[email protected].|
00000420  00 08 00 00 00 00 00 00  ff 27 03 00 00 00 00 00  |.........'......|
00000430  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000480  79 d3 d6 e6 07 f5 c2 44  a2 3c 23 8f 2a 3d f9 28  |y......D.<#.*=.(|
00000490  ea e7 0d a6 47 50 84 48  ab 8a 73 3e b3 99 e3 a8  |....GP.H..s>....|
000004a0  00 28 03 00 00 00 00 00  8e d9 30 46 02 00 00 00  |.(........0F....|
000004b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  eb 3c 90 6d 6b 66 73 2e  66 61 74 00 02 04 01 00  |.<.mkfs.fat.....|

Die Festplatten wurden mit cfdisk von util-linux partitioniert und funktionieren einwandfrei mit Linux.

Die Ausgabe sgdisk -v /dev/sdaist:

No problems found. 0 free sectors (0 bytes) available in 0
segments, the largest of which is 0 (0 bytes) in size.

Nach einem Vergleich des Verhaltens mit dem von mir zuvor verwendeten parted scheint das fehlerhafte UEFI Partitionstabellen mit einer Header-Länge von 512 abzulehnen, was der Standard zulässt:

Größe des GPT-Headers in Byte. Die HeaderSize muss größer oder gleich 92 und kleiner oder gleich der logischen Blockgröße sein.

Nach der Änderung von util-linux zur Verwendung einer Headergröße von 92 und der Neuerstellung meiner Partitionen mit fdisk erkennt UEFI nun meine Partitionen.

Es ist in neueren Util-Linux-Versionen (ab 2.26-rc1) "behoben":

Kay berichtete, dass Windows 8.1 GPT, das von libfdisk erstellt wurde, nicht erkennt, aber wie erwartet funktioniert.

Es scheint (gemäß dem Header-Hexdump), dass das Problem das HeaderSize-GPT-Feld ist, in dem libfdisk 512 (Header + reservierter Bereich) verwendet, aber parted 92 verwendet. Beide sind nach dem aktuellen EFI-Standard ziemlich gültig, aber 92 ist wahrscheinlich rückständiger kompatibel.

Ich habe auch Stellen im Code gefunden, an denen der libfdisk gpt-Treiber inkonsistent ist und manchmal alle Sektoren und manchmal nur sizeof (gpt_header) verwendet. Die richtige Lösung besteht darin, den gesamten Sektor (in den auf Null gesetzten Speicher) zu lesen und später den gesamten Sektor erneut auf das Gerät zu schreiben.

libfdisk: (gpt) Bereinigung der Headergröße