Bug 238969

Summary:	Kickstart LVM partitioning fails when using --grow
Product:	Red Hat Enterprise Linux 5	Reporter:	Janne Blomqvist <blomqvist.janne>
Component:	anaconda	Assignee:	Chris Lumens <clumens>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0	CC:	djuran
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-05 16:43:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Janne Blomqvist 2007-05-04 09:08:56 UTC

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.

Comment 1 Janne Blomqvist 2007-05-04 09:10:59 UTC

I forgot to mention, might be related to fedora bug 224635,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224635

Comment 2 Chris Lumens 2007-05-07 17:02:46 UTC

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.

Comment 3 Don Vanco 2008-02-05 12:23:37 UTC

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

Comment 4 Chris Lumens 2008-02-05 16:43:07 UTC

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.

Comment 5 David Juran 2008-09-04 06:56:35 UTC

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.