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
Kickstart button.

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 
creation fails.

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 / 
partitions.

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
remote)
or
-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.