GNU bug report logs - #27709
parted does not produce Protective MBR for GPT correctly

Previous Next

To reply to this bug, email your comments to 27709 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pali Rohár <pali.rohar <at> gmail.com>
To: bug-parted <at> gnu.org
Subject: parted does not produce Protective MBR for GPT correctly
Date: Sat, 15 Jul 2017 13:51:04 +0200

[Message part 1 (text/plain, inline)]

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

-- 
Pali Rohár
pali.rohar <at> gmail.com

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 27709 <at> debbugs.gnu.org (full text, mbox):

From: Pali Rohár <pali.rohar <at> gmail.com>
To: 27709 <at> debbugs.gnu.org
Subject: Re: bug#27709: parted does not produce Protective MBR for GPT
 correctly
Date: Mon, 13 Aug 2018 21:52:50 +0200

[Message part 1 (text/plain, inline)]

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 <at> gmail.com

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.