3 ms·
Good technical response! Is the part you quoted the one that's relevant here though? As per my post, gdisk reports "corrupt GPT" (due to CRC mismatch). In sect
by nh2 8y ago
Good technical response!
Is the part you quoted the one that's relevant here though? As per my post, gdisk reports "corrupt GPT" (due to CRC mismatch). In section 5.3.2 you posted, it says:
> 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.
So wouldn't the spec-compliant behaviour be to "provide confirmation before restoring", or at the very least, "must report whenever it restores a GPT"?
- rwmj 8y agoYes I believe you are right. It's possible the ASRock firmware did "report" this - I guess it doesn't need to ask for confirmation however ... arrgh. Did the ASRock firmware provide any "report" or feedback about what it was doing?
- nh2 8y agoNo, it didn't report anything. After cycling to the shop and buying a couple TB disks to make extra backups before messing with headers, I created new superblocks (you can tell `mdadm --create` to pick up existing data). I then repeated the repairing and subsequent re-deletion by the mainboard on boot around 10 times, in order to ensure it's reproducible before I post on their forums. I did not spot it outputting any kind of message about it.
- deleted 8y ago[deleted]