Bug 498360 - `clearpart --all --initlabel` does not suppress warning about unreadable partition tables.
`clearpart --all --initlabel` does not suppress warning about unreadable part...
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-29 23:57 EDT by George Goh
Modified: 2009-05-26 17:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-26 17:04:26 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)

  None (edit)
Description George Goh 2009-04-29 23:57:51 EDT
Description of problem:
Anaconda raises an error when a system with one or more uninitialized disks is provisioned using a kickstart file, even with the switch `clearpart --all --initlabel`.

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


How reproducible:
Always

Steps to Reproduce:
1. Use a new disk or zero out an existing one.
2. Use a kickstart file with the 'clearpart --all --initlabel' option.
  
Actual results:
Kickstart installation halts with the pop up message:
"The partition table on device X was unreadable. To create new partitions..."

Expected results:
Kickstart installation should proceed with no error messages.

Additional info:
This is a duplicate bug from Fedora 7 [1].
Current RHEL5 branch of anaconda, showing affected line.

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=359351
[2] - http://git.fedorahosted.org/git/anaconda.git?p=anaconda.git;a=blob;f=partedUtils.py;h=4b14329b5c397ccf4bbd0fb27adac137850f101c;hb=rhel5-branch#l1107
Comment 1 Chris Lumens 2009-05-26 17:04:26 EDT
Due to the massive storage rewrite we've undertaken for F11, this should be fixed in that release as well as in RHEL6.  If you require this fix in an update release of RHEL5, please talk to your support representative who will raise it through the appropriate channels so we can work on scheduling, capacity, etc.

Note that in order to do something for RHEL5, we will have to come up with a new fix as the storage code is so different as to make backports impossible.

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