On Thu, Mar 27, 2014 at 08:05:14PM -0400, Phillip Susi wrote:
> t0210-gpt-resized-partition-entry-array failed because gpt-header-munge
> did not relocate the LastUsableLBA to agree with the smaller table size.
> This caused parted to complain that the backup was not at the end of the
> disk ( as indicated by LastUsableLBA ), when in fact, it was. Accept
> the current AlternateLBA if it is *either* in the right place relative
> to LastUsableLBA, or the last sector of the disk.
> ---
> libparted/labels/gpt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libparted/labels/gpt.c b/libparted/labels/gpt.c
> index 42b0360..971c1c0 100644
> --- a/libparted/labels/gpt.c
> +++ b/libparted/labels/gpt.c
> @@ -991,7 +991,8 @@ gpt_read (PedDisk *disk)
> disk->dev->sector_size);
>
> gpt_disk_data->AlternateLBA = PED_LE64_TO_CPU
> (primary_gpt->AlternateLBA);
> - if (PED_LE64_TO_CPU (primary_gpt->AlternateLBA) != gpt_disk_end)
> + if (gpt_disk_data->AlternateLBA != gpt_disk_end &&
> + gpt_disk_data->AlternateLBA != disk->dev->length - 1)
> {
> if (ped_exception_throw
> (PED_EXCEPTION_ERROR,
> --
> 1.8.3.2
>
No, this would still set the new end to gpt_disk_end which is the
calculation I was complaining about. You cannot assume that the PTE will
start right after LastUsableLBA, you have to use the backup's
PartitionEntryLBA for any calculations related to that.
When the new backup is written it *must* be written to disk->dev->length
- 1, there is no flexibility there. And because the
gpt_disk_data->data_area is initialized to the disk size it will
automatically update the LastUsableLBA when it rewrites the headers.
With these changes are you trying to keep the backup at the wrong place
AND change the LastUsableLBA? If so, that is incorrect behavior.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
