[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27709: parted does not produce Protective MBR for GPT correctly
From: |
Pali Rohár |
Subject: |
bug#27709: parted does not produce Protective MBR for GPT correctly |
Date: |
Mon, 13 Aug 2018 21:52:50 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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
address@hidden
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#27709: parted does not produce Protective MBR for GPT correctly,
Pali Rohár <=