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
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.
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.
Is there a workaround for non-automated installs?
Updated release note text, removed "or BIOSraid" as --initlabel won't help with for disks with stale BIOSraid metadata.
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.
(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
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)
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.