various mishandlings of corrupt GPT

Chris Murphy lists at colorremedies.com
Tue Nov 5 04:58:02 UTC 2013


On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian <jbastian at redhat.com> wrote:

> On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
>> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian <jbastian at redhat.com> wrote:
>>> I have a system that corrupts the backup GPT on every reboot.
>> 
>> Certain RAID implementations write metadata at the end of the disk and
>> step on the backup GPT in this manner. But that was on computers with
>> BIOS firmware that weren't GPT aware. UEFI firmware obviously should
>> be GPT aware so it'd be quite a bungling if its firmware RAID were
>> writing metadata where the backup GPT goes. But it's worth seeing if
>> the firmware is up to date.
> 
> 
> Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I
> checked my system UEFI settings and indeed it was configured for RAID.
> I switched it to AHCI and that solved the problem!  No more backup GPT
> corruption!
> 
> I switched it back to RAID just to be sure and the backup GPT was
> corrupt again.
> 
> I guess I'll leave it in AHCI since I wasn't using the hardware RAID
> anyway.


What ought to happen, with the feature enabled, is the combined devices appear as a logical device that's then partitioned. This puts the GPT in the proper location for the logical device. It so happens the primary GPT in the logical device is the same location as for the physical devices, so if the logical device breaks, the physical devices have a primary GPT that's intact. The backup GPT for the logical device is in the correct location for only the logical device, it will be too far "in" on the physical device which has the IMSM RAID metadata at the end of the physical device instead.

Chris Murphy


More information about the devel mailing list