bug#17108: [PATCH 1/4] libparted: Check AlternateLBA against LBA-1

[Brian C. Lane]

On Wed, Mar 26, 2014 at 10:25:03PM -0400, Phillip Susi wrote:
> On 03/26/2014 01:56 PM, Brian C. Lane wrote:
> > commit 9e9588c71e introduced a problem with how the backup gpt 
> > partition's location was checked, and where it was re-written. It
> > was using LastUsableLBA plus an offset based on the number of
> > partition entries. This will not always match up with the end of
> > the disk. eg. during t0210 where the number of partitions is set to
> > 9 instead of 128.
> 
> I mentioned recently that t0210 was failing, but when I looked it it,
> it looked to me like the script was broken and was underflowing a
> variable, causing it to write the backup to a location near 2 TiB,
> rather than at the end of the much smaller "disk".  In other words,
> the script initially creates a 2M loop file, and after running
> gpt-header-munge on it, it is now a 2 TiB file.  This is clearly an
> error in gpt-heade-munge, rather than parted.

I haven't seen any evidence of that, and that isn't what's happening
here.

> 
> > The only way to check the AlternateLBA is against the size of the
> > disk. If it isn't in LBA - 1 then it is in the wrong place.
> 
> While this is true, the patch below regresses what I fixed before,
> which is that if the AlternateLBA says it does not go at the end of
> the disk, and we don't fix that, then we write it to the end of the
> disk anyhow.  This is incorrect.  If we don't fix AlternateLBA to
> point to the right location relative to the end of the disk, then we
> need to actually write the backup to where AlternateLBA says it is,
> even if that isn't where it should be.  With this patch, we write the
> backup to where it should be, but the header now claims it is in
> another location.

Ok, I'll check to make sure that isn't the case -- I thought the
location was updated when it was rewritten, but I'll double check.

But the basic problem here is that you are making calculations that are
invalid, as revealed by the failing test. You cannot count on the
AlternateLBA always being at the block after LastUsableLBA+Partition
entries. This *may* be true, but it isn't guaranteed to be true.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)