various mishandlings of corrupt GPT

[Chris Murphy]

On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones <rjones at redhat.com> wrote:

> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>> So that's why I ask if it makes sense to have an fsck for GPT disks.
> 
> Sounds sensible.  The "fsck" would just check the checksums of primary
> & secondary tables, and if an error in either (but not both) is
> detected it would restore from the other one?

Yes. I think the exception to fixing would be if the MBR is clearly not a protective MBR, i.e. it does not at all have an 0xEE entry. In that case, I'd say leave the stale GPT info alone as the disk is MBR not GPT.

There are some challenges interpreting hybrid MBRs correctly, because there's no standard here. So if the MBR contains an 0xEE entry and at least one additional entry, we could safely fix an invalid GPT with information from the valid GPT so long as the entries in the MBR and the valid GPT agree. If they don't, all bets are off and we probably shouldn't touch anything.

>  Does such an "fsck"
> tool exist already or would you just run gdisk (doesn't appear
> to be automatic)?

Does not exist as far as I know. Much of this code is in parted, including recognizing stale GPTs (a formerly GPT disk that's repartitioned MBR; which does not wipe out the old GPT information).


Chris Murphy