[Parted-maintainers] Bug#778712: libparted2: Breakage of RAID GPT header

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/19/2015 2:24 PM, jnqnfe wrote:
> Firstly, I am not running fdisk or parted on the raw member disks,
> I am simply running generic 'fdisk -l' and 'parted -l' commands,
> which return information about all disks. To simplify matters I
> removed information about other disks in my system from the output
> I supplied, leaving only that pertaining to the array and array
> member disks.

You did not; the output you supplied listed both sda and sdb.

> I disagree that the problems reported against the member disks
> should just be ignored.
> 
> Why does parted think and report that one of the member disks has 
> corrupt GPT tables? 1) The array was setup with 16KB block
> striping, which is surely plenty to contain the entire MBR block
> and primary GPT table within the one member disk; so it's not like
> this results from part of the GPT header being on one disk and the
> rest on another, which otherwise would understandably result in
> such an error. Unless I am wrong and this is happening, why does
> parted think there is a corruption?

The GPT is 16 KiB but starts on sector 2, hence the last 2 sectors
fall onto the second disk.

> 2) Why is parted examining GPT headers of member disks at all? It
> should recognise that these disks are members of a RAID array and
> thus skip looking for and reading partition headers on it,
> otherwise it just results in confusion for the user (and
> potentially other issues if it changes anything). Parted's
> behaviour should be changed here accordingly to skip seeking this
> information on array members.

Because parted does not know anything about raid.  I suppose it might
be nice if it could detect it and ignore those drives, but doing so
would require adding a dependency on udev or blkid.  I'll mull the
idea over.

> Furthermore, if you look at the fdisk output I supplied, you
> should notice that when I created the partition table with fdisk,
> everything was initially fine; no 'dev/sdb1' device exists (see
> fdisk4). However after running 'parted -l' to see what parted makes
> of the result of using fdisk, and then re-running 'fdisk -l' (I
> just happened to do so to be certain everything was fine, and found
> to my surprise it was not), you can see that now all of a sudden a
> /dev/sdb1' device exists.

sdb1 shows up in fdisk2.

> The 'GPT PMBR size mismatch' error reported by fdisk is related to
> this device, which per its name is apparently a sub-component of
> one of the array member disks, but I did not create any partition,
> and this device does not appear in lsblk output. So where does this
> 'sdb1' device come from? As just stated, it does not exist after
> purely creating the partition table with fdisk, but it does
> suddenly exist after running

The moment you created the GPT table on the raid array, it included
the protective MBR partition, and that is what fdisk is reporting
since the GPT is corrupt ( when viewed through the lens of the single
disk ).  lsblk uses the blkid database which does recognize that the
disks are array components and filters them out.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU50+6AAoJENRVrw2cjl5RgMAIAIKdSLrH8xyAOGgILnFkaMC3
Y0nWrjnH6ZZvxF4WgFCgRkmPAt0Er2BTYTd0PTMd81mMRndoWJNfiQ+J5L8GTxCb
jekarQWgpnGuUfhuUGJxg23IoTUhCXsbIiOu8kcbYTfI3WmXD5ZWEK2ZA+Y9XAaU
rWIajfIfcngeQKaZXL6TdKGslKfaOfdIyAn4AyAGuRP7SwyaHNu9RQyXo4xayjm1
006WmHNAIk0CtOMkPIPjH018+jmj3rnAqBIXc2R6wBZ6QjBdTmch2iRqYln99OR9
wJ6Jso9SWARM+pa3Yh2smFdWJPTFTHe9pY3xmFKtAOP7KGF5vQVJ9wC1w+ss7Ao=
=dSiK
-----END PGP SIGNATURE-----