Red Hat Bugzilla – Bug 238969
Kickstart LVM partitioning fails when using --grow
Last modified: 2008-09-04 02:56:35 EDT
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
"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.
Fails on RHEL5, the same partitioning section used to work on RHEL4.
See the thread I started at
Unfortunately that thread sort of petered out without any conclusion.
I forgot to mention, might be related to fedora bug 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.