[parted-devel] [PATCH 1/2] gpt_read: reintroduce restoring the primary/backup GPT when corruption

[Phillip Susi]

On 11/19/2018 8:15 AM, Hatayama, Daisuke wrote:
> I figured out what you guys are saying now.
> 
> The following commands call ped_disk_commit() meaning that the GPT
> header is ultimately updated in each of the following commands.
> 
>   - cp
>   - mkfs
>   - mkpart
>   - mkpartfs
>   - move
>   - name
>   - resize
>   - mklabel
>   - rm
>   - set

cp, mkfs, mkpartfs, and move were removed in parted 3.0.

> So, there is no explicit recovery for these commands in gpt_read() but
> restoring is done in a whole part of each command. OTOH, read-only sub
> commands such as print don't call ped_disk_commit() thus naturally GPT
> headers are never restored.

Right.

> I agree to this design but there are still the remaining two issues:
> 
> 1) There is still possibility of retoring the GPT headers is performed
>    via read-only sub-commands here:

Yes, but there you have the option to either leave it the way it is or
fix it, and the default is to leave it where it is.

> 2) The UEFI spec says that software MUST report whenever it restores a
>    GPT:
> 
>       If the primary GPT is corrupt, software must check the last LBA
>       of the device to see if it has a valid GPT Header and point to a
>       valid GPT Partition Entry Array. If it points to a valid GPT
>       Partition Entry Array, then software should restore the primary
>       GPT if allowed by platform policy settings (e.g. a platform may
>       require a user to provide confirmation before restoring the
>       table, or may allow the table to be restored
>       automatically). Software must report whenever it restores a GPT.
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is talking about UEFI firmware so doesn't really matter to us.  It
is also talking about any time the machine is booted up, not when the
user is trying to modify the partition table.

>     However, there is now no explicit report message indicating that
>     parted command has performed restoring the primary/backup GPT
>     headers.

It does tell you that it is corrupt, though I suppose it doesn't
explicitly tell you that it will be corrected when the table is written
back, though I'm not sure why that level of detail would be needed.

>     I thought the following messages are used for both user confirmation
>     and report:
> 
> 	Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
> 	Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
> 
>     but they are output also via print command where restoring GPTs is
>     not performed. Users cannot use these messages as report message.

They report the corruption, not correction.  Correction does, and indeed
*must* happen when the table is written.

>     parted command need to output report message for that purpose when
>     ped_disk_commit() is successfully done in each of the above 10
>     commands.

No, it doesn't.  There is absolutely no reason why parted should tell
the user "you asked me to write this partition table, and I'm doing so
correctly!"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/parted-devel/attachments/20181119/48fa63b3/attachment-0001.sig>