Red Hat Bugzilla – Bug 141644
clearpart fails on cciss drives
Last modified: 2014-08-14 21:43:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Description of problem:
When building systems with kickstart on HP DLT380 internal disks. The
customer is trying to clear the partition table for just the internal
drives. "clearpart --all" works but they dont want to use this as the
systems will be connected to a SAN, they need to specify the drives to
"clearpart --drives cciss/c0d0" does not clear the existing partition
table so the install fails. It does not generate any error message.
Attempts to create the /dev/cciss/c0d0 device node in %pre fails, as
it already exists.
If the required partitions are created prior to the install, clearpart
not run & the partitions are then created, the install works.
Specifying the full path name for the drive to clearpart also doesnt work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try changing the partition table from kickstart on a cciss drive.
Please provide the full ks.cfg being used as well as how it fails when
it doesn't do what they expect.
Created attachment 110159 [details]
Kickstart file used by the customer
The customer have found another problem with Anaconda / Satelite. He
is editing the kickstart file via the satelite server. Here is the
issue is reporting.
This is reliably reproducable as follows:
- Create kickstart
- Set options, removing --all from clearpart line and update kickstart
At this point, if I view the kickstart, I still see a clearpart line
there, but with no options. I now edit advanced options to remove this
by deselecting the checkbox next to clearpart and clicking the Update
Viewing the kickstart now shows no mention of clearpart. This is as
expected and as required.
However, if I now try to edit any of the options, I see that --all is
back in the clearpart box. If I change any options on this page such
as the root password or timezone, clearpart --all is back in the
kickstart. To stop this, every time I make an edit to the options I
have to remove --all from the clearpart box, then go into advanced
options and deselect clearpart.
Turning clearpart on with a default of --all seems to be the default
behaviour every time I edit the options for a kickstart, regardless of
whether or not it is being used in my kickstart. This is incredibly
dangerous, as if this default is enabled.
If instead of --all in the options box, we have a --drives xxx line,
then our preference is not overwritten.
This comment is in response to comment #1
When we use the kickstart provided as an attachment here, the
partition table on /dev/cciss/c0d0 is not cleared before new
partitions are created.
As all primary partitions are already in use, and several of the
partitions being created have the --asprimary flag set, the partition
If I modify the kickstart and remove the --asprimary flag and reduce
the size that the logical volume uses in the original installation,
then additional partitions are created without first clearing the
partition table. This leaves me with two /boot, two swap and two /
This bug affects us as well. Not on a san, bug instead have a large external
raid array, which we don't want to be reformatting every time we kickstart.
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product. If you have further information, feel free to
add to the report and reopen.
This is still present in RHEL 4 ES update 3, and is quite irritating for anyone
using HP ProLiant's with externally attached storage.
How to reproduce:
-use "clearpart --device=cciss/c0d0 --all"
Using "clearpart --all" does work, but is dangerous in a SAN-attached (or
otherwise externally attached) situation. The workarounds available in this
situation are not really desirable:
-disconnect the fibre when kickstarting (not practical when the server farm is
-run something in %pre to kill the partition table
and pray that you don't wipe the 1TB production GFS filesystem on /dev/sd*
This issue is STILL present in RHEL5 update 2. If a prior install exists on a Proliant server anacanda does NOT remove the existing partisions on cciss/c0d0. I would be happy to provide any information necessary to prove this.
The work around we have in place is to destroy the hardware RAID devices and recreate them differently (RAID 1 to RAID 5). We then pick different logical volume sizes. We then switch back to RAID 1 w/ hot spare and create the volumes with sizes we really want and it works.