Re: GPT Table broken on a Raid1

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

 



On Sep 22, 2012, at 4:07 PM, John Robinson wrote:

> On 22/09/2012 19:45, Chris Murphy wrote:
>> On Sep 22, 2012, at 9:31 AM, John Robinson wrote:
>>> I don't think there's anything wrong here.
>>> 
>>> The kernel sees the whole discs, sda and sdb, and complains that the GPT partition table looks wrong becase the second copy isn't at the end of the discs. That's correct, at the end of the raw discs is the IMSM metadata.
>> 
>> OK so sda and sdb shouldn't have been partitioned in the first place, is what that tells me.
> 
> That's not what I'm saying. I'm saying that sda and sdb weren't partitioned in the first place.

I disagree, it appears they were partitioned, but we'll see when the OP posts back the results from gdisk. The kernel messages in the very first post seems to imply it was partitioned (at least, at one time) or there wouldn't be an sdb1, sdb2, sdb3, etc.

>From the first post:
> Sep 17 09:54:27 techz kernel: [    1.204710]  sdb: sdb1 sdb2 sdb3 sdb4 sdb5 
> sdb6

> I'm saying that when the Linux kernel boots, and the AHCI driver starts, it sees the IMSM member discs as raw discs, which get probed for partitions. The GPT partition probe spots one of the copies of the GPT partition, but can't find the other one because the IMSM metadata's there.

The IMSM metadata will go at the end of the PHYSICAL disk. If you partition the virtual disk, i.e. the array, /dev/md/imsm0, then the GPT alternate header goes at the end of the virtual disk, NOT the end of the physical disk.

Besides, if what you say is true, as soon as he GPT partitioned the array, if the secondary GPT header stepped on IMSM metadata, then the array would instantly break. That's not what happened. 

> 
> 
> The error messages that Günther saw are a false positive and harmless

I think so too, but are the result of the raw disks being previously partitioned. Possibly even they are stale GPTs that should have been nuked before getting started with IMSM RAID.

> - or at least, harmless until someone starts telling him to go messing around rewriting the contents of the raw drives underneath md by deleting the misidentified partition tables, the effect of which is likely to be to damage his partitions inside the IMSM array and/or destroy the IMSM array metadata.

There's every reason to believe the primary GPT header on /dev/sda and /dev/sdb is a.) intact and b.) is in LBA 1 and c.) Cannot also include IMSM metadata. So removing that header would thus make obliterate the GPT on the physical disks and he'd stop getting the error message. If he's really bothered by what is in effect a harmless error message because that (stale) GPT doesn't matter anyway.

Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux