Bug#778712: libparted2: Breakage of RAID GPT header
On Fri, 2015-02-20 at 15:59 -0500, Phillip Susi wrote: It also shows no GPT either, because it is still seeing the stale cached data where there is nothing on the drive but zeros. Sure, yes. The fdisk4 output does show GPT info for the RAID device (md126) it just modified, so it is presumably flushing info for only that RAID device upon writing the change (or simply combining the new info it has with the already retrieved cache data), and not bothering to flush anything else. Since the execution of 'fdisk -l' after using fdisk to create the GPT tables does not seem to have flushed the cache of the array members, I would conclude that fdisk does not automatically flush the caches when it feels there may be no point, and thus per your description of parted's behavior, parted must indeed have been responsible for flushing the cache and allowing fdisk to then gain a fresh view of things upon the second run of it. It may be fair to say that in many/most cases there indeed would be no point in fdisk just flushing this info for every disk; even here it would not actually be a problem if only it recognised these disks as members of a RAID array and thus completely ignored them as far as reading partition tables goes. Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb, since it isn't operating on /dev/sdb. When you run parted -l, it walks every disk in the system and as part of reading from each one, flushes the cache, thus, /dev/sdb has its cache flushed, and reads the new partition table from the disk. Yeah. I previously had no idea that caching would be involved here. Going back over those fdisk outputs I do notice now that for sdb it is outputting Disklabel type: dos when the cache has been flushed. Again, thanks for the help, and patience. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-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- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
On Fri, 2015-02-20 at 10:16 -0500, Phillip Susi wrote: 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. 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. Do please note that in some of them sdc has been output before sdb, so perhaps you didn't look carefully enough and misread sdc for sda in these cases? I really don't know otherwise why on earth you think I've sent info about sda. The GPT is 16 KiB but starts on sector 2, hence the last 2 sectors fall onto the second disk. Okay, I'll take your word on that and thus that explains sufficiently why parted things there's corruption. 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. Okay. I do think that it would be a very good idea for parted to do this. We can put that stuff to one side then and focus on this phantom sdb1 device... 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. 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. 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. Starting afresh, I then did the same thing but using parted. You can see the state of things afterwards in fdisk3 and parted3. Again, as you can see in fdisk3, this phantom sdb1 device exists which fdisk doesn't like. No difference from using gparted. Finally I started things afresh once more and used fdisk to create the GPT partition table. The state of things after this according to fdisk (which I checked first) and which you can see in fdisk4 shows no sign of this phantom sdb1 device. So everything seems fine at this point according to fdisk. I then checked the state of things with parted, which you can see in file parted4. Then I checked fdisk one more time, and that phantom sdb1 device is back, as can be seem in fdisk5. 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). As I said in my last email, I am not outright claiming that parted is definitely directly responsible for creating this phantom device, but it is a pretty damning coincidence that it has so far only appeared after running parted. 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. 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. 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
Bug#778712: libparted2: Breakage of RAID GPT header
Control: severity -1 normal Control: close -1 thanks On Fri, 2015-02-20 at 15:12 -0500, Phillip Susi wrote: 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. No problem. 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. Yes, I'm with you. 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. I agree now that this might just be an fdisk caching issue, but I don't think this bit is quiet as you describe. The actions taken and results were as follows: 1) RAID array recreated. 2) fdisk used to create GPT table on md126. 3) fdisk -l, showing no issues and no info from MBR. 4) parted -l, pointing out corrupt GPT table. 5) fdisk -l, now showing info from the MBR and the error. So on the basis that fdisk is writing the same protected MBR that parted does, it seems fdisk is failing to flush it's cache and see the problem when asked to display info immediately following creation of the partition tables. Then, either parted triggered a cache flush (shared cache I presume?), or else fdisk managed to flush the cache the second time around. So in conclusion, this whole confusing mess resulted from a combination of: 1) parted being incapable of understanding RAID array membership. 2) fdisk also being incapable of understanding RAID array membership. 3) fdisk failing to flush a cache of partition info. I'll reduce the severity of this bug report and close it now then. Thank you for helping get to the bottom of this. I will try to do a little further testing tomorrow to try and nail down more precise details of the caching behaviour, and then report that along against fdisk with a request for fdisk to also add understanding of RAID array membership. Thanks again :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/2015 3:44 PM, jnqnfe wrote: I agree now that this might just be an fdisk caching issue, but I don't think this bit is quiet as you describe. The actions taken and results were as follows: 1) RAID array recreated. 2) fdisk used to create GPT table on md126. 3) fdisk -l, showing no issues and no info from MBR. It also shows no GPT either, because it is still seeing the stale cached data where there is nothing on the drive but zeros. 4) parted -l, pointing out corrupt GPT table. 5) fdisk -l, now showing info from the MBR and the error. So on the basis that fdisk is writing the same protected MBR that parted does, it seems fdisk is failing to flush it's cache and see the problem when asked to display info immediately following creation of the partition tables. Then, either parted triggered a cache flush (shared cache I presume?), or else fdisk managed to flush the cache the second time around. So in conclusion, this whole confusing mess resulted from a combination of: 1) parted being incapable of understanding RAID array membership. 2) fdisk also being incapable of understanding RAID array membership. 3) fdisk failing to flush a cache of partition info. Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb, since it isn't operating on /dev/sdb. When you run parted -l, it walks every disk in the system and as part of reading from each one, flushes the cache, thus, /dev/sdb has its cache flushed, and reads the new partition table from the disk. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU56AZAAoJENRVrw2cjl5RrtEIAJ+RgE2yKuIY+a3YeuF9ctyT xfZi6Uzdcz2UfaM1iWvJzdd6IUDgnDztajO4RYgl/XlMjS6efXtO3YixKsUI1Ajt 1Iv4rhPt2Asd+yFCX8fNkA6aGhvTGuHBvf21uWfUZRv05NC8ck7ro8d21RObQDsk KX5/c/PW3GTJDq1OrQsYygFCoFOocc5w60bu3vcHbGU7WPp561FTrQ4R4Sk1oZaH ln7W+QtfV+wYg7DnjvdMh2YRrIGfk3IoV4GibIFkn+6X5numGBs/O9/f8Q+4DyJC naMHOTQAGdzF5VxlNukeCkC7JlWPzEV1sFzxlB/DRhzb/F1Y8MGKCsLZexHEmSE= =kD25 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-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- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
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 21'. 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 21' 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-dist-requ...@lists.debian.org with a subject of
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/18/2015 4:05 PM, jnqnfe wrote: Background = I have a 'fake-raid' RAID0 array, created from two HDDs using my motherboard firmware. This is not used for root, just data. FYI, unless you have to dual boot with windows, you should avoid using fakeraid and stick with conventional linux software raid, which is much better supported. sdb and sdc are the RAID members here and the RAID device is md126. Then you need to only manipulate md126 and ignore sdb and sdc. Most of what you seem to be reporting involves looking directly at the individual disks, which you must not do as that will present a partial/corrupt view of the raid array. In other words, if the first few sectors of the raid array map to sdb, then sdb will appear to have a partition table in its sector 0 that describes a disk that is twice the size, since this partition table is actually describing the raid array and not the individual disk. The one thing you mention that I can't write off as user error is but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Can you provide more details here? Exactly what command did you run and what changed before vs. after? Parted should not be modifying anything on the disk unless you tell it to. Normally it will throw a warning telling you something is wrong with the disk and ask if you want it to fix it and you have to answer fix for it to modify the disk. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU5QWEAAoJENRVrw2cjl5RwnkH/0jvimRzKxUZjFait+KVZQgW gq2m6MVJYiDZLX3ajGZj2mxQNVu2RFqDn+YwqAWeDtrQEj/B0TXJC3RbBJpoN3Ao 5kH+lU2Z+YihRDpQMst8VGt1MVA6izcapN1uVeJOcLB2wICSGd0WcjAn8ROSnZNS o/7hXLh7dhxQZT+2HsTpmWa6pLEVvyBeQ8u2giNB0w8he75qv4/AxCFYAdVqhr4Y nNfC9zzCtcOGExu12GyigEpWUPlxUcyGsYzaQRR2hG1Vv7LKBsDBsok3qAag033E DyhyCWDj8NJk1WQIW2ZyVjhcskSyl59Oatd7X3TGSqr2L7yaHV+QAA5Cng+A9fw= =WuvR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
Package: libparted2 Version: 3.2-6 Severity: grave libparted2 breaks my RAID GPT header! There appears to be a disagreement between parted and fdisk as to the correct size. fdisk is happy after creating a GPT partition table, but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Having done so however parted is still not happy and now neither is fdisk. Letting parted create the partition table just leaves both unhappy, reporting the same issues. In testing reproducibility of my issue here I deleted and recreated the array, and proceeded to test as documented below, which explains things more clearly. **Please pay particular attention to what happened at the very end of test #3, which is why I marked this as severity grave! I would appreciate a quick turnaround on this issue, so I can get on with actually using this RAID array without fear of breaking it simply by running parted -l or opening gparted. Background = I have a 'fake-raid' RAID0 array, created from two HDDs using my motherboard firmware. This is not used for root, just data. sdb and sdc are the RAID members here and the RAID device is md126. fdisk -l and parted -l output (cut down to only the devices in question) generated during this procedure is attached. Test#1 - gparted = 1) Deleted and recreated the RAID array (in MB firmware). 2) Checked fdisk -l and parted -l (see fdisk1 and parted1 output files). fdisk is happy, parted only complains about unrecognised disk labels. 3) In gparted, with device md126 selected, I asked it to create a GPT partition table. This was done with no errors reported. gparted shows warnings for both sdb and sdc. The warning for sdc is just an unrecognised disk label warning, but the warning against sdb is: Both the primary and backup GPT tables are corrupt.! Checking fdisk -l, I see an GPT PMBR size mismatch error. I created the fdisk2 and parted2 files at this stage. For some reason fdisk now sees a device '/dev/sdb1', with size equal to that of the full array. I had not created any partitions yet. Test#2 - parted = 1) Deleted and recreated the RAID array (in MB firmware). 2) Checked fdisk and parted to make sure things had been reset correctly, they were. 3) Ran: sudo parted /dev/md126 mktable GPT This ran with no errors directly reported. 4) Checked parted -l, which reported the same corruption issue above (see parted3). 5) Checked fdisk -l, which reported the GPT PMBR size mismatch error as before (see fdisk3). Test#3 - fdisk = 1) Deleted and recreated the RAID array (in MB firmware). 2) Checked fdisk and parted to make sure things had been reset correctly, they were. 3) Ran: sudo fdisk /dev/md126 g (create a new empty GPT partition table) v (verify) - no errors, looked good to me w (write) - no errors: The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. 4) Checked fdisk -l output, which looks absolutely fine (see fdisk4). 5) Checked parted -l. This still complains about a corrupt GPT header. (See parted4). 6) Happened to check fdisk -l again, how it's reporting the GPT PMBR size mismatch error from before (See fdisk5). So it seems that the parted -l command here seems to have tried to forcibly correct the issue it was unhappy with, breaking what fdisk seemed to have done correctly. Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md126: 1.8 TiB, 2000381018112 bytes, 3906994176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 16384 bytes / 32768 bytes GPT PMBR size mismatch (3906994175 != 1953525167) will be corrected by w(rite). Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x Device Boot StartEndSectors Size Id Type /dev/sdb1 1 3906994175 3906994175 1.8T ee GPT Disk /dev/md126: 1.8 TiB, 2000381018112 bytes, 3906994176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 16384 bytes / 32768 bytes Disklabel type: gpt
Bug#778712: libparted2: Breakage of RAID GPT header
On Wed, 2015-02-18 at 16:35 -0500, Phillip Susi wrote: On 2/18/2015 4:05 PM, jnqnfe wrote: Background = I have a 'fake-raid' RAID0 array, created from two HDDs using my motherboard firmware. This is not used for root, just data. FYI, unless you have to dual boot with windows, you should avoid using fakeraid and stick with conventional linux software raid, which is much better supported. Fine, fair enough, I am not dual booting so I may switch as you suggest. Thanks for the tip. sdb and sdc are the RAID members here and the RAID device is md126. Then you need to only manipulate md126 and ignore sdb and sdc. Most of what you seem to be reporting involves looking directly at the individual disks, which you must not do as that will present a partial/corrupt view of the raid array. In other words, if the first few sectors of the raid array map to sdb, then sdb will appear to have a partition table in its sector 0 that describes a disk that is twice the size, since this partition table is actually describing the raid array and not the individual disk. I am not doing anything at all to the member disks, I am only manipulating the array (mb126) and providing the ouput of fsdisk -l / parted -l (with unnecessary info about other disks removed). The one thing you mention that I can't write off as user error is but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Can you provide more details here? Exactly what command did you run and what changed before vs. after? Parted should not be modifying anything on the disk unless you tell it to. Normally it will throw a warning telling you something is wrong with the disk and ask if you want it to fix it and you have to answer fix for it to modify the disk. I did only exactly as described in my previous message, nothing more, nothing less. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/2015 05:15 PM, jnqnfe wrote: Then you need to only manipulate md126 and ignore sdb and sdc. Most of what you seem to be reporting involves looking directly at the individual disks, which you must not do as that will present a partial/corrupt view of the raid array. In other words, if the first few sectors of the raid array map to sdb, then sdb will appear to have a partition table in its sector 0 that describes a disk that is twice the size, since this partition table is actually describing the raid array and not the individual disk. I am not doing anything at all to the member disks, I am only manipulating the array (mb126) and providing the ouput of fsdisk -l / parted -l (with unnecessary info about other disks removed). 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 ). The one thing you mention that I can't write off as user error is but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Can you provide more details here? Exactly what command did you run and what changed before vs. after? Parted should not be modifying anything on the disk unless you tell it to. Normally it will throw a warning telling you something is wrong with the disk and ask if you want it to fix it and you have to answer fix for it to modify the disk. I did only exactly as described in my previous message, nothing more, nothing less. 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJU5WZLAAoJENRVrw2cjl5RIEwIAKgjCMaHtYDruSejfB5I60F9 opO+FGClLTJPML6ggREF8hDM+K7eFpWCa4buWTvKUBix1oNjeLvWJVfu5XoSIQbt A+XX+YyBGjYuXXApXUV5W1A9P/beKhAGzs0anAZu6pZEirCcxQINjexjPua8PlZM PSuEppd/Bpmnw26CK/h2lrFNHJs1c9vzcnLOwMlT0ZzVXVAFFK90z8cxVo/kSvVb z5Sp5NtD/WWcdc5nTs6m1yEgs/3E/G3OB9VUF3+2c9dwXj5FXnEzAMAKN+g2ZKAO zI2TGFQpITPRkP7ij+0XpqH/YaWYLAHGbb0peIbsQHpDuBX+yT16Q3E93Sg56oU= =2m/O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
