Description of problem: With a kickstart partitioning section like clearpart --all --initlabel part /boot --fstype=ext3 --size=100 --asprimary part pv.01 --size=1 --grow volgroup vg01 pv.01 logvol / --vgname=vg01 --fstype=ext3 --size=15000 --name=rootLV logvol swap --vgname=vg01 --fstype=swap --recommended --name=swapLV logvol /tmp --vgname=vg01 --fstype=ext3 --size=5000 --name=tmpLV logvol /scratch --vgname=vg01 --fstype=ext3 --size=1 --grow --name=scratchLV the kickstart installation fails. During the partitioning stage anaconda throws an exception "lvcreate failed for swapLV", and the installation is aborted. Swithing to another VT and looking at the LV:s that anaconda has created, it seems that the problem is that the scratchLV has been created before swapLV, and due to the --grow option it grows to fill all the space, without leaving enough space left for swapLV. Changing the kickstart file by setting a fixed size for scratchLV and removing --grow makes the the kickstart succeed. This is all on a "normal" desktop computer with a single SATA drive. Version-Release number of selected component (if applicable): RHEL 5, i386. Sorry, don't know the anaconda version number. How reproducible: Fails on RHEL5, the same partitioning section used to work on RHEL4. Additional info: See the thread I started at https://www.redhat.com/archives/rhelv5-list/2007-April/msg00059.html Unfortunately that thread sort of petered out without any conclusion.
I forgot to mention, might be related to fedora bug 224635, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224635
I'm not quite sure how, but it does appear that Peter's fix for 224635 takes care of this bug as well. This will be fixed in the next release of RHEL. However if you need this fix in an update release of RHEL5, please talk to your support representative who will raise it through the appropriate channels. Thanks for the bug report.
Sory Chris, I'm having a hard time with a couple things - - the severity - this KILLS kickstart installs in any environment where your disks aren't identical. I now have to precisely define every disk profile or I'm screwed. In a production deployment environment this is a CRITICAL functionality, deserving of something more than a "medium" severity - Red Hat beats users over the head about reading the release notes - here's a thought: MAKE AN NOTE ABOUT THIS ISSUE IN THE RELEASE NOTES!!! Red Hat owes me 4 hours pay. Additional search terms for those being brow-beaten with this issue: insufficient free extents
Sorry you are experiencing this problem. If you can please test out Fedora 9, you can help us to determine whether or not this issue is truly fixed, and we can make sure that it does not occur in RHEL6. However, bugzilla is not a support tool. If you require this fix in an update release of RHEL5, you'll need to raise it through a support representative who will help to make sure it follows the correct procedure. While this is a bit complicated, it helps us to control the quantity of stuff in update releases and makes sure we don't overwhelm our development and QA teams. Thanks for your consideration.
I know it's not pretty, but you probably could in most cases work around this issue by initially createting the LV with a fixed minimal size and then in the %post section run lvextend.