[parted-devel] Offset GPT partition entries

Derek Foreman derek at collabora.co.uk
Fri Apr 5 17:48:25 UTC 2013


On 04/03/2013 05:54 PM, Elliott, Robert (Server Storage) wrote:
> You're trying to lay out the disk as:
> LBA 0		protective or hybrid MBR (required to be here)
> LBA 1		GPT Header (required to be here)
> LBA 2		restricted for some other purpose
> LBA 3..m-1 	GPT Partition Entry Array   (size m-3)
> LBA m		First Usable LBA
> ...
> LBA n-(m-3)-2	Last Usable LBA
> LBA n-(m-3)-1..n-1 	GPT Partition Entry Array  (size m-3)
> LBA n			Alternate GPT Header (required to be here)
>
> LBAs 0, 1, and n have fixed content; the other content can float.

Right - though for my use case the restricted area is more like 600 sectors.

> The UEFI GPT specification allows for gaps between:
> - the GPT Header and the GPT Partition Entry Array
> - the GPT Partition Entry Array and the First Usable LBA
> - the Last Usable LBA and the alternate GPT Partition Entry Array
> - the alternate GPT Partition Entry Array and the alternate GPT Header
> but doesn't remember the gaps used by one GPT in the other GPT.
>
> If the primary GPT Header goes bad and the primary GPT is rewritten
> by copying the alternate GPT Header and alternate GPT Partition
> Entry Array back into the primary location, how would software know that it is
> not supposed to place the Partition Entry Array at LBA 2?  The software doing
> this may or may not understand the special case.

A very good point I'd not thought of.  I don't think U-Boot currently 
does anything with the alternate header, so I didn't consider that.

> There is no rule in the UEFI GPT specification that there be the same spacing
> between the alternate GPT Header and the alternate GPT Partition Entry Array
> and the alternate Header as there is between the primary GPT Header and the
> primary GPT Partition Entry Array, but that might be a way to communicate
> this need. We could try to add such a rule if that's the only viable solution.

That seems to be a good idea to me.  I can't think of any better way to 
"back up" that offset information.  It's a little wasteful of space though.

>> +++ b/libparted/labels/gpt.c
>>     last_usable_if_grown
>> -    = (disk->dev->length - 2 -
>> +    = (disk->dev->length - gpt->PartitionEntryLBA -
>>         ((PedSector) (PED_LE32_TO_CPU (gpt->NumberOfPartitionEntries)) *
>>          (PedSector) (PED_LE32_TO_CPU (gpt->SizeOfPartitionEntry)) /
>>          disk->dev->sector_size));
>
> Does this leave room for the alternate GPT (Header and Partition Entry
> Array)?  It seems to be missing a "2 *" factor.

Actually a bug in the initial patch...  I shouldn't have changed that 
line at all.  using gpt->PartitionEntryLBA directly was also a bad move.

I've rewritten the patch to make the gap be the same for both primary 
and alternate partition entries, and fixed up some other fairly ugly 
problems that would allow creating partitions that overlap with the 
partition tables.

I'll post that shortly

Thanks,
Derek



More information about the parted-devel mailing list