On Mon, Apr 25, 2016 at 06:06:46PM -0700, Julius Werner wrote:
> The GUID Partiton Table layout maintains two synonymous partition tables
> on a block device, one starting in sector 1 and one in the very last
> sectors of the block device. This is useful if one of the tables gets
> accidentally corrupted (e.g. through a partial write because of an
> unexpected power loss).
>
> Linux normally only boots if the primary GPT is valid. It will not even
> try to find the alternative GPT to an invalid primary one unless the
> "gpt" command line option forces more aggressive detection. This doesn't
> really make any sense... if the "gpt" option is not set, the code
> validates the protective or hybrid MBR in sector 0 anyway before it even
> starts looking for the actual GPTs. If we get to the point where a valid
> proctective or hybrid MBR was found but the primary GPT was not found
> (valid), checking the alternative GPT is our best bet: we know that this
> block device is meant to use GPT (because any other partitioning system
> would've presumably overwritten sector 0), and we know that if the
> alternative GPT is valid it should contain more accurate information
> than parsing the protective/hybrid MBR with msdos_partition() would
> yield (which would otherwise be what happens next).
I guess "force_gpt" (and "gpt" on kernel command line) exists to force
users to think and care about a reason why the device has unreadable
(broken) primary GPT header.
It seems like bad (and dangerous) idea to silently ignore corrupted
primary GTP header and boot from such device.
And note that alternative GPT header and the end of the device is a
just guess. The proper location of the alternative header is specified
with-in primary header (pgpt->alternate_lba). The header at the end of
the device (as used for "force_gpt") is a fallback solution only.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
