bug#27709: parted does not produce Protective MBR for GPT correctly

[Pali Rohár]

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
address@hidden

signature.asc
Description: This is a digitally signed message part.