GNOME Bugzilla – Bug 784976
gparted does not produce Protective MBR for GPT correctly
Last modified: 2017-08-13 17:27:16 UTC
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
GParted uses libparted (part of GNU Parted) for manipulation of disk partitions. Using your steps I get the same result using parted (the command line tool) directly: # 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 ..............?. This bug will need reporting with the GNU Parted project. The GNU Parted bug reporting email list and archive can be found here: https://www.gnu.org/software/parted/lists.shtml As such I am closing this bug as RESOLVED, NOTGNOME.
parted bug is reported there: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27709