Bug 141644 - clearpart fails on cciss drives
clearpart fails on cciss drives
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 12:53 EST by Graham Biswell
Modified: 2014-08-14 21:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-21 15:09:47 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)
Kickstart file used by the customer (2.78 KB, text/plain)
2005-01-24 16:35 EST, Olivier Renault
no flags Details

  None (edit)
Description Graham Biswell 2004-12-02 12:53:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

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.
"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):


How reproducible:
Always

Steps to Reproduce:
1. try changing the partition table from kickstart on  a cciss drive.
3.
    

Additional info:
Comment 1 Jeremy Katz 2004-12-02 13:41:28 EST
Please provide the full ks.cfg being used as well as how it fails when
it doesn't do what they expect.
Comment 2 Olivier Renault 2005-01-24 16:35:59 EST
Created attachment 110159 [details]
Kickstart file used by the customer
Comment 3 Olivier Renault 2005-01-24 16:41:40 EST
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. 
Comment 4 Wayne Pascoe 2005-02-10 07:00:20 EST
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.

Comment 5 ed2019 2005-04-05 08:21:42 EDT
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.
Comment 6 Jeremy Katz 2005-09-21 15:09:47 EDT
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.
Comment 8 Buchan Milne 2006-07-03 11:47:55 EDT
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*
Comment 9 Greg A 2009-04-13 08:05:26 EDT
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.

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