Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 530465

Summary: assertion failures in gpt_read() and _parse_header() during install
Product: Red Hat Enterprise Linux 5 Reporter: Bjorn Helgaas <bjorn.helgaas>
Component: partedAssignee: Hans de Goede <hdegoede>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: bugzilla, ddumas, doug.chapman, rlerch
Target Milestone: rc   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
anaconda sometimes crashes while attempting to install on a disk containing partitions or filesystems used by other operating systems. To workaround this issue, clear the existing partition table using the command: clearpart --initlabel [disks] (BZ#530465)
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-05 16:46:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 540752    
Attachments:
Description Flags
console log of installation failure none

Description Bjorn Helgaas 2009-10-22 22:07:45 UTC
Created attachment 365792 [details]
console log of installation failure

Installing RHEL5.3 on HP ia64 server results in the attached assertion failures during disk partitioning.

I suspect this is related to the previous contents of the disk.  I don't know yet what was on the disk.  We've seen failures like this before, so this is likely a duplicate, but I couldn't find reports in bugzilla.

HP internal defect report QXCR1000979961

Comment 1 Denise Dumas 2009-11-05 16:46:29 UTC
Yes there are several known weakness-es in RHEL-5 parted's gpt reading code,
the problem is that fixing these requires some major changes and that is considered too de-stabilizing for a RHEL-5.x release.

For automated installs you can work around anaconda on crashing on certain
(bad) gpt tables by specifying:
clearpart --initlabel [disks]

Which will force writing a new partition table without ever looking at the old
one.

Since the changes required to fix this are to unstabilizing, I'm closing this
as wontfix. 

But we will add a release note for RHEL5.5 describing this workaround.

Comment 2 Denise Dumas 2009-11-05 16:46:29 UTC
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Anaconda cannot always recognize and erase previous content on reused disks, and will occasionally crash when encountering unrecognized formats. When installing onto disks that were previously used e.g. for other operating systems or BIOSRaid, you can work around this issue by specifying:
clearpart --initlabel [disks]

This will force writing a new partition table without ever looking at the old one.

Comment 3 Bjorn Helgaas 2009-11-05 18:53:28 UTC
Is there a workaround for non-automated installs?

Comment 4 Hans de Goede 2009-11-06 07:54:28 UTC
Updated release note text, removed "or BIOSraid" as --initlabel won't help with for disks with stale BIOSraid metadata.

Comment 5 Hans de Goede 2009-11-06 07:54:28 UTC
Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,4 +1,4 @@
-Anaconda cannot always recognize and erase previous content on reused disks, and will occasionally crash when encountering unrecognized formats. When installing onto disks that were previously used e.g. for other operating systems or BIOSRaid, you can work around this issue by specifying:
+Anaconda cannot always recognize and erase previous content on reused disks, and will occasionally crash when encountering unrecognized formats. When installing onto disks that were previously used e.g. for other operating systems, you can work around this issue by specifying:
 clearpart --initlabel [disks]
 
 This will force writing a new partition table without ever looking at the old one.

Comment 6 Hans de Goede 2009-11-06 08:03:33 UTC
(In reply to comment #3)
> Is there a workaround for non-automated installs?  

You can go to tty2 while at the welcome screen and then
manual run a parted new label command for example:
 
parted /dev/sda mklabel gpt

Comment 7 Ryan Lerch 2010-03-19 00:10:06 UTC
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,4 +1,5 @@
-Anaconda cannot always recognize and erase previous content on reused disks, and will occasionally crash when encountering unrecognized formats. When installing onto disks that were previously used e.g. for other operating systems, you can work around this issue by specifying:
+anaconda sometimes crashes while attempting to install on a disk containing partitions or filesystems used by other operating systems. To workaround this issue, clear the existing partition table using the command:
+
 clearpart --initlabel [disks]
 
-This will force writing a new partition table without ever looking at the old one.+(BZ#530465)

Comment 9 Philip Rowlands 2012-12-03 13:31:12 UTC
Is clearpart --all --initlabel not an acceptable workaround for this problem?

I'm still seeing crashes on RHEL5.9 beta due to gpt_read() failing, despite having "clearpart -all --initlabel" in the kickstart file.

I tried replacing it with "clearpart --initlabel --drives=cciss/c0d0", but still anaconda crashes instead of unconditionally wiping the disk.