Re: various mishandlings of corrupt GPT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> 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
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux