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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
