Bug 433681 - Assertion (last_usable_if_grown > first_usable) at gpt.c:688 in function _parse_header() failed.
Assertion (last_usable_if_grown > first_usable) at gpt.c:688 in function _par...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: parted (Show other bugs)
ppc64 Linux
high Severity high
: rc
: ---
Assigned To: David Cantrell
Brock Organ
: Regression, TestBlocker
Depends On:
  Show dependency treegraph
Reported: 2008-02-20 15:21 EST by Nate Straz
Modified: 2008-05-21 12:56 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0322
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 12:56:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
parted-1.8.1-bitness.patch (783 bytes, patch)
2008-03-14 18:08 EDT, David Cantrell
no flags Details | Diff

  None (edit)
Description Nate Straz 2008-02-20 15:21:43 EST
Description of problem:

When trying to install on ppc with a GPT labelled disk connected, I get the
following stack trace.

Backtrace has 20 calls on stack:
  20: /usr/lib/libparted-1.8.so.0(ped_assert+0xb0) [0xecaf1a0]
  19: /usr/lib/libparted-1.8.so.0 [0xecf4c84]
  18: /usr/lib/libparted-1.8.so.0(ped_disk_new+0xc0) [0xecb9200]
  17: /usr/lib/python2.4/site-packages/partedmodule.so [0xe547610]
  16: /usr/lib/libpython2.4.so.1.0(PyCFunction_Call+0x1b0) [0xfee86c0]
  15: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3e9c) [0xff30f8c]
  14: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  13: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  12: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  11: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  10: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  9: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3cf8) [0xff30de8]
  8: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x93c) [0xff328fc]
  7: /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x396c) [0xff30a5c]
  6: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x93c) [0xff328fc]
  5: /usr/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x44) [0xff329e4]
  4: /usr/lib/libpython2.4.so.1.0 [0xff554ac]
  3: /usr/lib/libpython2.4.so.1.0(PyRun_SimpleFileExFlags+0x1dc) [0xff56f5c]
  2: /usr/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0xb0) [0xff577b0]
  1: /usr/lib/libpython2.4.so.1.0(Py_Main+0x9dc) [0xff5ee4c]
Parted exceptions can't be handled in command line mode!
Assertion (last_usable_if_grown > first_usable) at gpt.c:688 in function
_parse_header() failed.

The disk in question is /dev/sdc which is a 10TB LUN with a GPT label.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Label disk with GPT
2. reinstall node
Actual results:
See above

Expected results:
anaconda should be able to understand GPT labels on ppc.

Additional info:

The partitioning section of my kickstart file is:
clearpart --initlabel --drives=sda

Why is anaconda looking at anything besides sda?
Comment 1 Nate Straz 2008-02-20 15:44:04 EST
I ran through the install again without the "cmdline" option and there doesn't
appear to be a way to get a dump from anaconda at this point.  I can "Ignore" or
"Cancel" but neither stops the install process.
Comment 2 David Cantrell 2008-02-20 15:45:57 EST
(In reply to comment #0)
> Why is anaconda looking at anything besides sda?

Because we look for any other filesystem labels on the system so we can avoid
those when we label our filesystems.
Comment 3 Nate Straz 2008-02-21 12:38:57 EST
(In reply to comment #2)
> Because we look for any other filesystem labels on the system so we can avoid
> those when we label our filesystems.

Does anaconda have to stop the installation process when it finds a GPT label
for this?  I haven't had any problems reading GPT labels on any platform.
Comment 4 David Cantrell 2008-02-21 14:52:17 EST
No, you just hit an error for your particular set up.  Not sure what's causing
it.  We support GPT labels (we have to, that's the only way to go on
Itanium...and on x86 Mac systems).

Can you give me any more information on how to reproduce your problem?  How was
the 10TB GPT disk provisioned?  Some external source?
Comment 5 Nate Straz 2008-02-21 15:01:40 EST
It is a 10TB LUN from a FC RAID attached via a LightPulse FC HBA.  The GPT label
was applied with parted, pyparted to be more specific.  I think there was just
one large partition on the LUN at the time of that install.
Comment 6 Nate Straz 2008-03-11 15:22:26 EDT
Arg, I ran into a similar problem on a new x86_64 cluster with SAN storage
attached which I haven't touched yet.

Parted exceptions can't be handled in command line mode!
/dev/sde contains GPT signatures, indicating that it has a GPT table.  However,
it does not have a valid fake msdos partition table, as it should.  Perhaps it
was corrupted -- possibly by a program that doesn't understand GPT partition
tables.  Or perhaps you deleted the GPT table, and are now using an msdos
partition table.  Is this a GPT partition table?

My kickstart file only references /dev/sda.  I appreciate your attempt not to
duplicate file system labels, but aborting the install for a partition you can't
read seems silly to me.  If anaconda can't read the partition, surely the system
won't when it boots without anaconda.
Comment 9 David Cantrell 2008-03-14 17:55:21 EDT
Think I have it working now.  Here is my current build running on the newport system:

[root@newport ~]# hostname
[root@newport ~]# uname -a
Linux newport 2.6.18-84.el5 #1 SMP Fri Feb 29 16:31:54 EST 2008 ppc64 ppc64 ppc64 GNU/Linux
[root@newport ~]# parted /dev/sdc print

Model: WINSYS SA3478 (scsi)
Disk /dev/sdc: 10.5TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  10.5TB  10.5TB                          

Information: Don't forget to update /etc/fstab, if necessary.             

[root@newport ~]# 

The problem was with the calculation of the last_usable_if_grown value in libparted's GPT code.  A set of 
macros has been present in the code for a while to deal with large 64-bit values and that was resulting 
in incorrect values.

Attaching a patch to this bug report for my own record keeping.
Comment 10 David Cantrell 2008-03-14 18:08:15 EDT
Created attachment 298091 [details]
Comment 11 David Cantrell 2008-03-17 16:12:35 EDT
Will be fixed in parted-1.8.1-16.el5.
Comment 15 errata-xmlrpc 2008-05-21 12:56:09 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.


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