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