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

Previous Next

Full log

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)]

Previous Next

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