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): RHEL5.2-Server-20080219.nightly How reproducible: 100% 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 autopart Why is anaconda looking at anything besides sda?
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.
(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.
(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.
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?
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.
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.
Think I have it working now. Here is my current build running on the newport system: [root@newport ~]# hostname newport [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.
Created attachment 298091 [details] parted-1.8.1-bitness.patch
Will be fixed in parted-1.8.1-16.el5.
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-2008-0322.html