Re: GPT Table broken on a Raid1

On 24-09-12 7:35 PM, Chris Murphy wrote:

Further, it seems increasingly clear as I'm reading the UEFI spec on
GPT, that IMSM is incompatible with GPT. The GPT alternate header by
spec is expected at the end of the disk, but then IMSM also demands
to be in basically the exact same location. And yet Intel is shipping
UEFI hardware, which require GPT disks, with IMSM on board that also
requires metadata in the same location? How is this not a WTF
moment?

It isn't. It's just RAID setup with the superblock at the end of the 
disk- as soon as RAID1 is activated, the RAID volume you see is just a 
bit smaller than the raw disksize, and the GPT alternate header is at 
the right place- at the end of the RAID volume.

The thing is that the Linux kernel detects the GPT partition table on 
the raw disks before the RAID1 volume is assembled. More of a cosmetical 
bug.

People have argued before that the kernel should do no partitiontable 
discovery at all, and just leave it to userspace. That's what kpartx is 
for, for example. In that case, with a correctly ordered and configured 
stack, the disks would get detected, any whole-disk RAID volumes would 
get assembled, and only then partition detection would be done. But I 
think that never got popular because of all the "I want to boot a kernel 
without an initramfs" people.

Mike.