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

Hatayama, Daisuke d.hatayama at jp.fujitsu.com
Mon Nov 19 01:27:04 GMT 2018


Hi Brian and John,

> From: parted-devel
> [mailto:parted-devel-bounces+d.hatayama=jp.fujitsu.com at alioth-lists.debian
> .net] On Behalf Of Brian C. Lane
> Sent: Saturday, November 17, 2018 3:45 AM
> 
> On Wed, Nov 07, 2018 at 07:11:05AM +0000, Hatayama, Daisuke wrote:
> > Currently, no primary/backup GPT is restored when one of them is
> > corrupted due to the commit 432a33115c50005bbe96a09d55edc7d034715ec8.
> >
> > According to the description of the commit, the purpose of the commit
> > is to deal with corruption of pMBR due to another issue during
> > clobbering, but there seems no such issue because now
> > ped_disk_clobber() avoids pMBR to clobber.
> 
> I am opposed to this change. I think the current behavior is safer, and
> makes sense. Doing a print should not make changes to the disk, and when

I also think print should not make any changes to the disk.

But I also think it important to fix regression of restoring the
primary/backup GPTs headers.

The design of this patch set is not always to allow restoring the
primary/backup GPT headers for print command but when and only when
there is explicit confirmation from users.
Don't perform the restoring when there is no confirmation from users
such as in the script mode.

There is the 2/2 patch in this patch set and please also read it here:

    [parted-devel] [PATCH 2/2] gpt_read: don't restore the primary/backup GPT in script mode
    https://alioth-lists.debian.net/pipermail/parted-devel/2018-November/005331.html

If you still think print command should not modify data on the disk even in the
interactive mode with explicit user confirmation, I'll make next patch set that
tries to allow restoring the primary/backup GPT headers only for the commands
that are not read-only.
But then I will need suggestion on how to modify parted data structure to
pass information of the currently executed command to gpt_read().

> one or the other header is corrupt (but not both) things still work
> correctly.

Currently, no restoring of the primary/backup GPT headers is performed
in the interactive mode even when there is explicit confirmation from users
and the command being executed is the one that is not read-only.

For example:

    # LANG=C parted ./prGPTcorrupt.bin "rescue 0 1"
    Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
    parted: invalid token: 0
    OK/Cancel? OK
    Start? 0
    End? 1%
    Error: Can't have a partition outside the disk!
    Error: Can't have a partition outside the disk!
    Error: Can't have a partition outside the disk!
    ...<snip>...

    # LANG=C parted -s ./prGPTcorrupt.bin print
    Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
    Model:  (file)
    Disk /root/work/parted_work/prGPTcorrupt.bin: 524kB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags:
    
    Number  Start  End  Size  File system  Name  Flags

Do you say this behavior is correct?

> 
> The header *will* be fixed when you make an explicit change to the disk.

What I think problematic is a regression of the feature.

Thanks.
HATAYAMA, Daisuke





More information about the parted-devel mailing list