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

Previous Next

Package: parted;

Reported by: "Brian C. Lane" <bcl <at> redhat.com>

Date: Wed, 26 Mar 2014 18:34:06 UTC

Severity: normal

Tags: patch

Full log


Message #38 received at 17108 <at> debbugs.gnu.org (full text, mbox):

From: Phillip Susi <psusi <at> ubuntu.com>
To: "Brian C. Lane" <bcl <at> redhat.com>
Cc: 17108 <at> debbugs.gnu.org
Subject: Re: [PATCH] libparted: Check AlternateLBA against LBA-1
Date: Fri, 28 Mar 2014 13:31:18 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/28/2014 1:02 PM, Brian C. Lane wrote:
> 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.

It doesn't assume the pte will start right after LastUsableLBA.  What
it does is to use LastUsableLBA to infer that AlternateLBA was
perfectly correct, before the disk was grown.

> 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.

There is flexibility here just as there is for LastUsableLBA.  If the
user chooses not to fix the table so things are where they should be,
then we need to respect that.

> With these changes are you trying to keep the backup at the wrong
> place AND change the LastUsableLBA? If so, that is incorrect
> behavior.

The purpose is to keep the backup where it is if the user says to
ignore the "error" and if the "error" is that the disk has grown, then
just say the disk has grown, without first complaining that the backup
is in the "wrong" place ( since it is in fact, in the right place if
you are going by the old size of the disk ).

In other words, if we know that the backup being in the wrong place is
purely a side effect of the disk growing, then don't treat it as a
separate error; it will be handled as part of the disk growing error.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTNbHmAAoJEI5FoCIzSKrwYEkIAIMxb7P5U97aw3PbemMDOhwg
GuOlE7/6FHZRbEtAzXJM6VGiKB/td+WnGoijbjiR+LcC6qEMJdhoFHWvLE9GNMy3
F4sFZKSglQmQhKexRl0m6MDVH6F15GLruDjBCwAJz92C3V6PCMQ59OKNECf/WgrR
JwwcH2F9Z00cLTOQ0JrCRKI25HiIaNBP8ytHue14fauIWEfNyFVKlpFUeAHcaQWT
nuMF+sFn5HuNsrOcwUjjn4HGlQ/tI1jiz+0ym1wB0E9dSM5/2oTEU8C3l5wq53FI
HZfb8XfwA6FLqA49Nezc2xxr0B8ZUiDrUM6pPRVqE8F2h+avBdq22kXpc2u34HU=
=NDOt
-----END PGP SIGNATURE-----




This bug report was last modified 11 years and 77 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.