|Summary:||'interactive' token in kickstart attempts autopartition|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Need Real Name <jmesterh>|
|Component:||anaconda||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike McLean <mikem>|
|Target Milestone:||---||Keywords:||FutureFeature, Reopened|
|Fixed In Version:||5.0.0||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-08-15 15:34:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Need Real Name 2005-04-14 14:59:41 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Description of problem: We are trying to make a 'guided' installation of RHEL 4 for our campus subscription which will set defaults for the installer based on our network, using an embedded ks.cfg on a cdrom. We want to specify a set of package groups in the ks.cfg file, but still allow the user to check/uncheck groups as they wish. This would require the 'interactive' keyword so that the installer does not skip package selection entirely. However, if you insert the token 'interactive' in the ks.cfg, the installer will die at the first screen with the error "Partitioning failed: Could not allocate partitions as primary partitions." and then reboots. It appears that for some reason the installer is trying to autopartition?! Even if there is no partitioning information in the ks.cfg. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a ks.cfg file with the token 'interactive' in the header. 2. Boot RHEL 4 disc 1, with an url pointing to that ks.cfg Actual Results: The installer's first screen gives the error "Partitioning failed: Could not allocate partitions as primary partitions." and reboots the system, on systems that have a disk with a non-empty partition table. Expected Results: The installer should have gone to the partitioning option screens like a regular install. Additional info:
Comment 2 Jeremy Katz 2005-04-14 21:21:59 UTC
kickstart implies auto-partitioning with the partitioning information given in the kickstart config. Sorry, side effect of the implementation. If you specify a default in the ks.cfg (with a clearpart line), then people should be able to modify what gets created.
Comment 3 Steve 2007-01-03 14:43:57 UTC
Hmm, This is the first time I have reopened a bug and then attached the relevant issue tracker. Seems like just attaching the issue-tracker ticket does not automatically submit all the IT notes to the bugzilla. So, I'm pasting those here individually.
Comment 4 Steve 2007-01-03 14:44:57 UTC
Paritioning modes differ from when using a kickstart in "interactive" mode vs. no kickstart install from CD media. The kickstart.py file in /mnt/runtime/usr/lib/anaconda is skipping the partitionmethod and partitionmethodsetup methods if self.interactive (which comes from "interactive" set in the kickstart)... this causes a problem when there are partitions using the whole disk (i.e. a "dual boot" configuration) or a previous install when all disk space is used. The CD media install lets them use Disk Druid and wipe away / change any partitions for dual boot or clean install. Other .img files are probably the same way with the same kickstart.py file. In the kickstart.py file from netstg2.img (RHEL4U4), the line numbers in question are 1381-1382. Commenting these two lines fixes the problem for us in our test environment. Not having those lines commented causes an error message to pop up stating "Could not allocate requested partitions: Partitioning failed: Could not allocate partitions as primary partitions. Press 'OK' to reboot your system." Is there a reason these two lines are commented out? A user (knowledgeable user) under the current setup would have to either do ALT-F2 from the install, which gets them to a shell and then run fdisk... or use the full CD install media, stopping after it lets them repartition the drive and then load the boot media and specify to use the kickstart file again. Not very user friendly!
Comment 5 Steve 2007-01-03 14:45:34 UTC
I don't believe this is something that the anaconda maintainers are going to fix. It appears someone else ran into this with RHEL4 in the following bugzilla and our maintainer gave them a workaround. Let me know if this will / won't work in your situation: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154842
Comment 6 Steve 2007-01-03 14:46:26 UTC
Kent, Unfortunately, specifying a default partitioning in the ks.cfg (with a clearpart line) is not a work-around when there is no free disk space or enough free disk space, and no partition should be deleted without user selection. Again, installing from CDs works fine in this situation, but we have not found a solution for a kickstart install without modifying netstg2.img for text installs and stage2.img for graphics installs. That's not a viable option when using the distribution on the RHNSS because a satellite sync wipes out the modifications made to the images. Giacomo
Comment 7 Steve 2007-01-03 14:46:57 UTC
Hi, Giacomo Aside from modifying kickstart.py, I havent found a way to get around this yet, either without issuing a clearpart which, like you said, wipes the disk. I'll see what engineering has to say. Thanks.
Comment 8 Steve 2007-01-03 14:48:00 UTC
This appears to have been a problem for a while, but I'm doubt this is something that we're going to fix in anaconda. If you try to do an interactive kickstart, and there are partitions using the whole disk, the user is presented with the error: "Could not allocate requested partitions: Partitioning failed: Could not allocate partitions as primary partitions. Press 'OK' to reboot your system." ..instead of being presented with the partitioning option screens like a regular install. The only way the customer was able to work around it was to comment out lines 1381 and 1382 of the kickstart.py file in netstg2.img and stage2.img. Doing that will allow the users to change their partitions however they wanted. According to BZ 154842, the error apparently is a side effect of the kickstart implementation and the suggested workaround was to use "clearpart" in the ks.cfg. This won't work if the customer wishes to preserve any existing partitions. So, are there any other workarounds that may work besides modifying the kickstart.py files in stage2 / netstg2.img (which, the customer claims, get overwritten during a sat-sync) or issuing a clearpart? Steps to Reproduce: 1. Create a ks.cfg file using the interactive option (I've attached one that reproduced for me). 2. Boot up cd 1 and point to the ks.cfg file. If possible, make sure the system has a previous installation on it where all disk space is used. You should get the error: "Partitioning failed: Could not allocate partitions as primary partitions." and reboots the system, on systems that have a disk with a non-empty partition table."
Comment 9 Steve 2007-01-03 14:48:34 UTC
Escalating. Engineering: This sounds like a reasonable request. I would argue against the earlier comment in the bugzilla, because the 'interactive' token implies that the installer should prompt for details that are missing in the ks.cfg. An example of this behavior is when the installer prompts for the network info. when the attached ks.cfg is used for network based (http in this case) installation. With the 'interactive' token, the absence of a clear partitioning scheme in the kickstart file should imply a prompt for partitioning details. I have not looked at the anaconda code much, but if engineering thinks this should be doable without disrupting too much, I would gladly try providing a patch.
Comment 10 Steve 2007-01-03 14:49:59 UTC
Created attachment 144706 [details] ks.cfg with missing partitioning scheme
Comment 12 Kent Baxley 2007-01-31 13:42:56 UTC
Created attachment 147017 [details] partition error from interactive install
Comment 18 RHEL Product and Program Management 2007-05-09 11:24:47 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Comment 19 Chris Lumens 2007-07-10 15:06:40 UTC
We don't have the resources for fixing this in 4.6, so I'm NAKing.
Comment 24 Jeff Bastian 2008-03-27 21:16:32 UTC
*** Bug 424221 has been marked as a duplicate of this bug. ***