On Saturday 15 July 2017 13:51:04 Pali Rohár wrote:
> Bug report originally reported to gparted:
> https://bugzilla.gnome.org/show_bug.cgi?id=784976
> 
> But from second comment it appears that real problem is in parted,
> because gparted only used parted. See:
> 
> # truncate -s 10G /tmp/gpt
> # parted /tmp/gpt
> GNU Parted 3.2
> Using /tmp/gpt
> Welcome to GNU Parted! Type 'help' to view a list of commands.
> (parted) mklabel gpt                                                      
> Warning: The existing disk label on /tmp/gpt will be destroyed and all data on
> this disk
> will be lost. Do you want to continue?
> Yes/No? yes                                                               
> (parted) quit                                                             
> # dd if=/tmp/gpt bs=1 count=16 skip=446 2>/dev/null | xxd
> 00000000: 0000 0100 eefe ffff 0100 0000 ffff 3f01  ..............?.
> 
> Original bug report:
> 
> According to _UEFI Specification 2.6_, section _5 GUID Partition Table (GPT)
> Disk Layout_, subsection _5.2.3 Protective MBR_, Table 17. _Protective MBR
> Partition Record protecting the entire disk_, **StartingCHS** is 0x000200
> (**0/0/2**) and **EndingCHS** is 0xFFFFFF (**1023/255/63**) if it is not
> possible to represent last logical block as C-H-S.
> 
> But When creating new GPT partition table via gparted StartingCHS is 0/0/1 and
> EndingCHS is 1023/254/63 which is incorrect.
> 
> Please make gparted compliant to UEFI/GPT specification.
> 
> Test to reprocude:
> $ truncate -s 10G /tmp/gpt
> $ sudo ./src/gpartedbin /tmp/gpt
> (now create new GPT partition table in menu and exit)
> $ dd if=/tmp/gpt bs=1 count=16 skip=446 2>/dev/null | xxd
> 0000000: 0000 0100 eefe ffff 0100 0000 ffff 3f01  ..............?.
> 
> StartingCHS is 0x000100 (1st byte - 4th byte) which means 0/0/1
> EndingCHS is 0xfeffff (5th byte - 8th byte) which means 1023/254/63
> 
> When creating new gpt partition table with gdisk, Protective MBR is filled
> correctly:
> $ truncate -s 10G /tmp/gpt2
> $ printf "o\ny\nw\ny" | gdisk /tmp/gpt2
> $ dd if=/tmp/gpt2 bs=1 count=16 skip=446 2>/dev/null | xxd
> 0000000: 0000 0200 eeff ffff 0100 0000 ffff 3f01  ..............?.
> 
> StartingCHS is 0x000200 (1st byte - 4th byte) which means 0/0/2
> EndingCHS is 0xffffff (5th byte - 8th byte) which means 1023/255/63
> 
> Btw, same problem had fdisk from util-linux...
> https://github.com/karelzak/util-linux/issues/485

It looks like that problem with StartingCHS was fixed in commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=df6770d213b60320426a3ee0bed118d063b40fc5

But problem with EndingCHS is not fixed yet. Below is a patch which fix
also EndingCHS, to be set to 0xFFFFFF value as required by UEFI Specification.

diff --git a/libparted/labels/gpt.c b/libparted/labels/gpt.c
index 4f922b2..6f92a34 100644
--- a/libparted/labels/gpt.c
+++ b/libparted/labels/gpt.c
@@ -1144,7 +1144,7 @@ _write_pmbr (PedDevice *dev, bool pmbr_boot)
   pmbr->Signature = PED_CPU_TO_LE16 (MSDOS_MBR_SIGNATURE);
   pmbr->PartitionRecord[0].OSType = EFI_PMBR_OSTYPE_EFI;
   pmbr->PartitionRecord[0].StartSector = 2;
-  pmbr->PartitionRecord[0].EndHead = 0xFE;
+  pmbr->PartitionRecord[0].EndHead = 0xFF;
   pmbr->PartitionRecord[0].EndSector = 0xFF;
   pmbr->PartitionRecord[0].EndTrack = 0xFF;
   pmbr->PartitionRecord[0].StartingLBA = PED_CPU_TO_LE32 (1);

-- 
Pali Rohár
pali.rohar@gmail.com