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

[Phillip Susi]

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

On 2/20/2015 12:17 PM, jnqnfe wrote:
> What? I very carefully went through every one of them before
> sending to ensure that only information about the array (md126) and
> the array members (sdb and sdc) were included. I have just checked
> back over every one of those files attached to the original bug
> report and none of them contain any info about sda.

I'm sorry; I misread what you said.  I thought you said you had
removed the information about the individual disks that were members
of the array.

>> sdb1 shows up in fdisk2.
> 
> Yes, but please review the initial bug report for when I created
> each of the output files. I ran three tests using different tools
> to create the GPT headers, first with gparted, then with parted,
> then with fdisk. Before each test I deleted and recreated the RAID
> array to try and achieve a fresh start (which checking fdisk and
> parted info after doing so confirmed was a successful means of
> resetting things). Files fdisk1 and parted1 demonstrate the state
> of things directly after recreating the RAID array, without yet
> attempting to write the partition table.

Yes, at this point the disk is blank.

> So, fdisk2 and parted2 show the state of things after using gparted
> to write a GPT table to the array, and thus this phantom sdb1
> device exists, which fdisk doesn't like.

At this point the array contains a protective MBR that lists one
partition of type ee that occupies the whole array.  Fdisk looks at
sdb and sees the same thing.  Following the MBR is the GPT, part of
which is missing from sdb, so fdisk treats it as corrupt, and falls
back to printing only the MBR.

> So the phantom sdb1 device was not there when only fdisk was used 
> (fdisk4), but does appear after using parted, whether using parted
> to create the partition table (fdisk 2, fdisk3), or as in the last
> test, only to view information (parted -l) after using fdisk
> (fdisk5).

I see now.  I think you are running into a cache aliasing issue here.
 That is to say, that the MBR of sdb was read into the cache while the
drive was still blank, and when parted creates the gpt on the array,
it does in fact create that protective mbr partition, but fdisk does
not see it on sdb yet, since it is still holding the cached data from
earlier.  Note that at this point fdisk reports that there is no
partition table of any kind, not just no sdb1.  If you run blockdev
- --flushbufs and then repeat the fdisk -l, sdb1 should show up.

> Okay, I am aware that a protective MBR may be written alongside the
> GPT tables and that the protective MBR may contain a partition
> entry covering the entire disk. So you're suggesting that this may
> be what this phantom sdb1 device is? Interesting.

Yes, that is exactly what sdb1 is.  You can see from the ID field
being ee.

> But, what is the explanation for it not appearing in fdisk ouput
> after using fdisk to create the GPT tables in test #3? And
> furthermore what is the explanation for it then suddenly appearing
> after then running 'parted -l'? And if that is the case then that
> would imply that fdisk also may not be properly paying attention to
> the fact that these are array members.

parted flushes the disk cache when opening it to make sure that it is
reading the correct data.  After that, fdisk also now sees it.

> If fdisk is setting the protective MBR partition to the size of a
> member disk, rather than the size of the array, that would explain
> the fdisk error not showing up after using fdisk to create the
> partition tables. And if parted is doing the opposite, setting the
> array size here, that would explain the presence of the error in
> fdisk output after using parted to do it. Which if so, begs the
> question, which is right? Should fdisk be changed to use the array
> size (alongside paying proper attention to array membership of
> course), or should parted be using the disk size?

Both of them are using the size of the array, which they should since
that is the "disk" as far as they are concerned.


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

iQEcBAEBAgAGBQJU55UUAAoJENRVrw2cjl5RM8UH/0tBf2Kz1MfNkZeOuMG4nfRV
fx5iYdI0I5Zm5SEB1fYXJcKLwxfNb5h0sBs+BskmVcnJZioMm3foo9uHetFip4kA
2zBZfXmgI5akFbkYYq2H7q0wxwU4tDecCGOn9cOUeTA0GNCci4W/f6TfKugk504E
aUzoQMh+qN8Fxycj1p+efa7voRgYiUjC8aaEUmswYRLdfgxKKLkhOKYZY31Kk3Qf
i5zbLjeUrLPARlmUGOc2ON0ljzLm/QJ3p40iCTFVaJ9dQrUumLiH4bUc53rXY72S
XAYeaCTim2gKTcGJD6VKMTa/EVlwjWgBPb12FsnFtha/Gv/oilahGVqz5cZlRro=
=3W21
-----END PGP SIGNATURE-----