Bug 194238 - Parted segfaults because of extended devices with GPT partition table
Parted segfaults because of extended devices with GPT partition table
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: parted (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-06 11:06 EDT by Jimmy Olsen
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0275
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:34:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
source code for command to dump the GPT headers (2.41 KB, text/plain)
2006-08-07 17:52 EDT, Riaan van Niekerk
no flags Details
Patch that fixes the segfault. (552 bytes, patch)
2006-08-10 10:02 EDT, Josef Bacik
no flags Details | Diff
mail to bug-parted@gnu.org with patches to fix both problems (7.17 KB, text/plain)
2006-08-14 09:24 EDT, Riaan van Niekerk
no flags Details
new patch to fix problem#2 (2.73 KB, patch)
2006-08-16 18:19 EDT, Riaan van Niekerk
no flags Details | Diff
Patch to fix this problem for RHEL4 (3.43 KB, patch)
2006-08-18 11:33 EDT, Josef Bacik
no flags Details | Diff

  None (edit)
Description Jimmy Olsen 2006-06-06 11:06:30 EDT
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
Comment 1 Jimmy Olsen 2006-06-08 08:58:41 EDT
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).
Comment 2 Riaan van Niekerk 2006-08-07 05:05:30 EDT
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.
Comment 4 Riaan van Niekerk 2006-08-08 02:05:41 EDT
(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
Comment 5 David Cantrell 2006-08-08 13:41:41 EDT
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.
Comment 6 Riaan van Niekerk 2006-08-10 04:08:00 EDT
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.
Comment 7 Josef Bacik 2006-08-10 10:01:19 EDT
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.
Comment 8 Josef Bacik 2006-08-10 10:02:11 EDT
Created attachment 133949 [details]
Patch that fixes the segfault.
Comment 9 Riaan van Niekerk 2006-08-14 09:24:07 EDT
Created attachment 134137 [details]
mail to bug-parted@gnu.org with patches to fix both problems
Comment 11 David Cantrell 2006-08-16 15:11:34 EDT
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.
Comment 12 Riaan van Niekerk 2006-08-16 18:19:31 EDT
Created attachment 134353 [details]
new patch to fix problem#2
Comment 13 Riaan van Niekerk 2006-08-16 18:54:13 EDT
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.
Comment 14 David Cantrell 2006-08-17 11:22:44 EDT
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.
Comment 15 David Cantrell 2006-08-17 14:04:32 EDT
The parted-1.7.1-12 package in tomorrow's rawhide also has all of these fixes if
anyone can test that.
Comment 16 Riaan van Niekerk 2006-08-17 16:51:32 EDT
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?
Comment 18 Josef Bacik 2006-08-18 11:33:43 EDT
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.
Comment 19 Riaan van Niekerk 2006-08-18 11:40:23 EDT
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?).
Comment 20 RHEL Product and Program Management 2006-08-18 15:42:01 EDT
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.
Comment 21 Jay Turner 2006-08-20 21:42:12 EDT
QE ack for 4.5.
Comment 25 David Cantrell 2006-08-21 11:50:06 EDT
Hotfix available as parted-1.6.19-11.EL from this URL:

http://people.redhat.com/dcantrel/rhel/parted/
Comment 28 David Cantrell 2007-01-31 15:08:25 EST
This was taken care of in August, but I never moved the bug to MODIFIED state:

* Wed Aug 16 2006 David Cantrell <dcantrell@redhat.com> - 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.
Comment 32 Red Hat Bugzilla 2007-05-01 13:34:32 EDT
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

Note You need to log in before you can comment on or make changes to this bug.