Description of problem: After having extended a SAN device with a GPT partition and rebooting box in question, parted coredumps when attempting to create a new backup partition table: Version-Release number of selected component (if applicable): parted-1.6.19-1.EL-x86_64 How reproducible: 100% Steps to Reproduce: 1. Create a GPT partition on a device. 2. Extend the device (make it larger) 3. "parted <device> print" 4. Type "Fix" Actual results: Segmentation fault. Expected results: That parted should fix the issue, and then let me change the partition table normally. Additional info: This seems to be a bug in parted. A claimed fix has been posted to the parted-bugs list, but I do not know if it was applied: http://www.mail-archive.com/bug-parted@gnu.org/msg00779.html
After some more digging, this seems to be another bug than the one linked to in my original post, even though it looks very similar. The patch in the post did not resolve my problem, and neither did downloading and trying versions 1.7.0 and 1.7.1 of parted. In other words, this problem is not fixed in parted's latest releases, nor is there a known patch (at least that I know of).
I also have this problem. I saw two variants on two different systems though (both parted-1.6.19-1.EL-x86_64): a) parted segfaults and parted still does not allow me to print the GPT partition table b) parted segfaults but afterwards, prints the partition table Both log something similar (but not identical) in the /var/log/messages a) kernel: parted[26302]: segfault at 0000000000000000 rip 0000003cee26f952 rsp 0000007fbffff1d8 error 4 b) kernel: parted[8458]: segfault at 0000000000000000 rip 000000354246f952 rsp 0000007fbffff218 error 4 Since (b) segfaulted before/after fixing the partition table, we are unsure if the partition table is actually usable and in a consistent state (e.g. if the backup partitin table has been properly created). After rebooting the system, it sees the LUN and partition 1. System b) is a production environemnt, where I need to add partitions. I will be adding one soon and update this bugzilla with my findings.
(due to the risks of running a buggy parted against a production LUN, I decided against it, until I can test in a non-production environment) This bug is very well documented in http://lists.gnu.org/archive/html/bug-parted/2006-08/msg00004.html The author of the mail used a program he wrote called readit/read-gpt (source code attached in comment #3. It shows the problem as twofold: Problem 1 An exception when parted recognises that the backup GPT header is not in the correct place and tries to move it: (in the case of parted-1.6.19-1.EL-x86_64 it is a segmentation fault, which may or may not move the backup GPT header to the end of the disk) Problem 2 Having relocated the GPT headers, I cannot utilise the additional space made available in the resized LUN: the LastUsableLBA value is not changed from the old end-of-disk to the new end-of-disk. (I was not able to test this, but based on the output of read-gpt, I have a strong indication that adding additional partitions into the space added by the LUN extension will not succeed) # gpt header dump for Problem 1 # run against test environment where the partition table was not moved ./read-gpt /dev/emcpowera Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 3435132328 MyLBA 1 Alt-LBA 188743679 <--- old size, 90GB FirstUsableLBA 34 LastUsableLBA 188743646 <--- old size, 90GB DiskGUID PartitionEntryLBA 2 NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1846927894 Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 3601388745 MyLBA 188743679 <--- old size, 90GB Alt-LBA 1 FirstUsableLBA 34 LastUsableLBA 188743646 <--- old size, 90GB DiskGUID PartitionEntryLBA 188743646 <--- old size, 90GB NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1846927894 # gpt header dump for Problem 2 # run against our production environment, where the backup gpt table was moved to the end of the disk ./read-gpt /dev/emcpowera Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 558351487 MyLBA 1 Alt-LBA 15975883391 <--- new size, 8TB FirstUsableLBA 34 LastUsableLBA 5045015774 <--- original size, 2.5TB (wrong) DiskGUID PartitionEntryLBA 2 NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 625116575 Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 2767479513 MyLBA 15975883391 <--- new size, 8TB Alt-LBA 1 FirstUsableLBA 34 LastUsableLBA 5045015774 <--- original size, 2.5TB (wrong) DiskGUID PartitionEntryLBA 15975883358 <--- new size, 8TB NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 625116575
I think this problem has already been addressed in the parted-1.6.19-9.EL package. Try that out on a test system, if you can: http://people.redhat.com/dcantrel/rhel/parted/ Let me know if it works for you. parted-1.6.19-4.EL is slated for inclusion in RHEL4U4, and it's closed for updates, so I will have to wait until it ships before doing an update to ship parted-1.6.19-9.EL or higher. I'm mostly interested to see if my GPT fixes solve your problem or if it's something different.
I tested parted-1.6.19-9.EL on my test environment. It still segfaults. I was provided another package via my open service request, which managed to fix Problem 1 (failure to move GPT to end of disk) but still displays Problem 2 (failure to update LastUsableLBA to new end-of-disk value). The SRPM for that version of parted is parted-1.6.19-1.EL.IT99356.test.src.rpm. Do you have a mechanism of simulating a grown LUN? e.g. creating a simulated disk using dd, then growing it and testing various versions of parted against that? We are currently using a real SAN, and setting up the test environment (and resetting it after a test) is exceedingly cumbersome.
Ok this is the patch I applied to fix the segfault, and this is how the table looks after the fix [vega:/home/riaan]# ./read-gpt /dev/emcpowera Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 605972964 MyLBA 1 Alt-LBA 377487359 <- updated FirstUsableLBA 34 LastUsableLBA 188743646 <- not updated DiskGUID PartitionEntryLBA 2 NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1846927894 Signature EFI PART Revision 0x00010000 HeaderSize 92 HeaderCRC32 4118027129 MyLBA 377487359 <- updated Alt-LBA 1 FirstUsableLBA 34 LastUsableLBA 188743646 <- not updated DiskGUID PartitionEntryLBA 377487326 <- updated NumberOfPartitionEntries 128 SizeOfPartitionEntry 128 PartitionEntryArrayCRC32 1846927894 I'm thinking about doing the following change @@ -730,7 +730,7 @@ _generate_header (PedDisk* disk, int alt } gpt->FirstUsableLBA = PED_CPU_TO_LE64 (gpt_disk_data->data_area.start); - gpt->LastUsableLBA = PED_CPU_TO_LE64 (gpt_disk_data->data_area.end); + gpt->LastUsableLBA = PED_CPU_TO_LE64 (disk->dev->length - 1); gpt->DiskGUID = gpt_disk_data->uuid; gpt->NumberOfPartitionEntries = PED_CPU_TO_LE32 (gpt_disk_data->entry_count); But I dont know much about gpt headers and I'm afraid this might be dangerous.
Created attachment 133949 [details] Patch that fixes the segfault.
Created attachment 134137 [details] mail to bug-parted with patches to fix both problems
OK, I need some clarification on patches. The attachment in comment #9 is against parted-1.7.0 and mentions SuSE Linux 8 or SLES8. This bug was opened against RHEL-4, which does not have parted-1.7.x. Is this problem occurring on RHEL-4 systems? If so, I'll have to backport this fix to parted-1.6.19. Please clarify.
Created attachment 134353 [details] new patch to fix problem#2
Yes, the bug for me is on RHEL 4 u3/u4 (i386/x86_64) version of parted-1.6.19 (which has the exact same behaviour ast 1.7.0. even after the patch in #9 . The segfault fix works for me. However, Problem/bug #2 as per Comment #3 (not updating the LastUsableLBA) still persists. As per the author's admission in e-mail to me, the patch to parted-1.7.0/libparted/labels/gpt.c does not work for systems displaying problem #2 only. He provided a new patch (comment#12) which does work for me with LVM. I was also provided via RH GSS test package 1155677065-parted-1.6.19-1.EL.IT99536.test3.i386.rpm which works for me with LVM. I know things are a bit confusing, since I am trying both community provided patches to 1.7.0 as well as Red Hat-provided test binaries on 1.6.19. If the patch used to compile the above RPM does not contain Darren's code, perhaps you may want to look at it, or have Darren look at yours (ignore this if you are collaborating already) I will be trying the Red Hat-provided test binary on a real SAN tomorrow.
OK, I have built a new RPM for RHEL-4 systems incorporating the patches discussed here (but backported to parted-1.6.19). Find them here: http://people.redhat.com/dcantrel/rhel/parted/ The packages are all for the parted-1.6.19-10.EL build. Try them on a RHEL-4 system and let me know if they correct your problem. I will be making the same updates to rawhide too.
The parted-1.7.1-12 package in tomorrow's rawhide also has all of these fixes if anyone can test that.
The fix works for me. read-gpt shows the exact same results for the PTs of these three permutations: a) parted (1.7.0, since it offers sector-based granularity) /dev/emcpowera mklabel gpt ; mkpart primary) b) parted (1.6.19 from comment #14) /dev/emcpowerb print Fix (to fix Problem#1), Ignore (Problem #2), then rerun to Fix Problem #2) c) parted (1.7.0 with patch from comment #12) /dev/emcpowerb print Fix (to fix Problem#1), Ignore (Problem #2), then rerun to Fix Problem #2) I picked up the following anomalous behaviour (not sure if this is cosmetic or actually problematic): At the "Name" field/column, parted 1.6.19 does not show the original (1st) partition as "primary" for LUNs of which the partition table was fixed using the patch. Where the partition table was recreated (emcpowera), partition 1 has a "Name" of "primary". Parted 1.6.19-10.EL [vega:/home/riaan/parted-1.7.0/parted]# parted /dev/emcpowera print Disk geometry for /dev/emcpowera: 0.000-38912.000 megabytes Disk label type: gpt Minor Start End Filesystem Name Flags 1 0.017 19455.983 primary 2 19455.984 38911.983 primary [vega:/home/riaan/parted-1.7.0/parted]# parted /dev/emcpowerb print Disk geometry for /dev/emcpowerb: 0.000-38912.000 megabytes Disk label type: gpt Minor Start End Filesystem Name Flags 1 0.017 19455.983 2 19455.984 38911.983 primary [vega:/home/riaan/parted-1.7.0/parted]# parted /dev/emcpowerc print Disk geometry for /dev/emcpowerc: 0.000-38912.000 megabytes Disk label type: gpt Minor Start End Filesystem Name Flags 1 0.017 19455.983 2 19455.984 38911.983 primary Parted 1.7.0 (patched) shows Name as primary under all circumstances. [vega:/home/riaan/parted-1.7.0/parted]# ./parted /dev/emcpowera print Disk /dev/emcpowera: 40.8GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 20.4GB 20.4GB primary 2 20.4GB 40.8GB 20.4GB primary Information: Don't forget to update /etc/fstab, if necessary. [vega:/home/riaan/parted-1.7.0/parted]# ./parted /dev/emcpowerb print Disk /dev/emcpowerb: 40.8GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 20.4GB 20.4GB primary 2 20.4GB 40.8GB 20.4GB primary Information: Don't forget to update /etc/fstab, if necessary. [vega:/home/riaan/parted-1.7.0/parted]# ./parted /dev/emcpowerc print Disk /dev/emcpowerc: 40.8GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 20.4GB 20.4GB primary 2 20.4GB 40.8GB 20.4GB primary Information: Don't forget to update /etc/fstab, if necessary. I have two more grown LUNs attached to a RHEL 4 host I can use to test. Would it help you if I build that rawhide SRPM on RHEL 4 and test it against a grown LUN?
Created attachment 134450 [details] Patch to fix this problem for RHEL4 Ok since this is a RHEL4 bug we need a patch that applies agaisnt RHEL4's parted. The patch that I'm attatching applies to RHEL4's parted, and fixes the segfault problem and the resize problem for the GPT. David this is what needs to be applied to the RHEL4 package, sorry about all the cross chatter thats been going on, hope this clears up the confusion.
The binaries in http://people.redhat.com/dcantrel/rhel/parted/ worked for me. Were they patched with the patch from Comment #18? If not, how are they different from the Comment $18 patch? Is there anything else I can/should test on RHEL 4 x86_64 attached to SAN (e.g. rawhide parted SRPM recompiled for RHEL 4?).
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
QE ack for 4.5.
Hotfix available as parted-1.6.19-11.EL from this URL: http://people.redhat.com/dcantrel/rhel/parted/
This was taken care of in August, but I never moved the bug to MODIFIED state: * Wed Aug 16 2006 David Cantrell <dcantrell> - 1.6.19-10.EL - Expand error buffer to 8192 bytes in vtoc_error() - Do not apply O_DIRECT patch on S/390 or S/390x platforms - Update LastUsableLBA on GPT-labeled disks after LUN resize (#194238) - Fix exception when backup GPT table is not in the correction location and parted tries to move it (#194238) Moving bug to MODIFIED state.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0275.html