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

[jnqnfe]

On Wed, 2015-02-18 at 23:27 -0500, Phillip Susi wrote:
> All of the error messages shown in the logs you sent so far involve
> the raw disks ( sdb, etc ) rather than the raid array.  You certainly
> should not be running fdisk or parted on the raw disk, and responding
> to the error messages by saying it should fix the problem ( since the
> problem is only a result of looking at an individual disk instead of
> the whole array ).

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.

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?
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.

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.

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
'parted -l'. Perhaps I am wrong and parted is not actually messing up
the actual partition data on the disk (I haven't examined the disk),
perhaps it is simply generating and storing information about this
phantom device in the file system somewhere, which fdisk is then picking
up on. So, what is going on here?

> You stated that parted modified the disk when you didn't tell it to,
> but did not show exactly what command you gave that lead to this, and
> more importantly, what if any, error messages parted threw and how you
> responded to them.

To be more clear, parted seems to be creating some phantom 'sdb1'
device, which then fdisk isn't happy with. As described above, I have no
idea why parted is creating this. I do not know absolutely that it is
parted that created it, but it does consistently appear after using
parted, which makes it pretty likely. I also do not know for certain
that this device is something actually being written to disk, or whether
it is being saved into the filesystem, but it is being stored somewhere
for fdisk to then discover and complain about, and this persists across
reboots.

As already stated, the necessary details of what I did are described in
my previous message. Here is a small amount of additional detail
however:
1) When checking fdisk, I specifically ran 'fdisk -l'. To then generate
the output files I simply ran 'fdisk -l > fdisk1 2>&1'. I then edited
the output file in gedit to remove details about other disks that would
be irrelevant.
2) For parted output, I similarly ran 'parted -l' and 'parted -l >
parted1 2>&1' respectively, and edited the output files with gedit as
with fdisk.
3) See initial bug report for further detail (e.g. list of and order of
actions taken). I have excluded from this nothing that should be at all
relevant, I mean I may have had my mail client open but as I say, I am
excluding nothing that should be at all relevant.
4) As already described, the only errors that occurred are those that
are present in the output files attached to the initial bug report. I
responded to them only as exactly described in the initial bug report,
i.e. I saved output from 'fdisk -l' and 'parted -l' into files to attach
to the bug report, as described above and previously.