On Tue, 26 Apr 2016, Karel Zak wrote:
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
'best bet' in a kernel is not enough :) Which is why userland tools can fix
and/or do any sort of crazy stuff with the backup and recover the primary etc etc.
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.
Yes, from find_valid_gpt():
* If the Primary GPT header is not valid, the Alternate GPT header
* is not checked unless the 'gpt' kernel command line option is passed.
* This protects against devices which misreport their size, and forces
* the user to decide to use the Alternate GPT.
... so users are at least forced in some way to think about this.
It seems like bad (and dangerous) idea to silently ignore corrupted
primary GTP header and boot from such device.
Yeah, there's no way in hell I trust a backup gpt in kernel space.
We simply have no way of distinguishing between good and bad devices.
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.
And this only illustrates the ambiguity of the backup.
Thanks,
Davidlohr
--
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
