Bug 238969 - Kickstart LVM partitioning fails when using --grow
Kickstart LVM partitioning fails when using --grow
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-04 05:08 EDT by Janne Blomqvist
Modified: 2008-09-04 02:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-05 11:43:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 224635 None None None Never

  None (edit)
Description Janne Blomqvist 2007-05-04 05:08:56 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
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 05:10:59 EDT
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 13:02:46 EDT
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 07:23:37 EST
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 11:43:07 EST
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 02:56:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.