Description of problem: i'm using the following partition layout when trying to kickstart a virtual machine with an 8GB disk: zerombr yes clearpart --all --drives=sda --initlabel partition /boot --size=200 --ondisk=sda --asprimary partition swap --size=200 --ondisk=sda partition pv.00 --size=1 --ondisk=sda --grow volgroup vg00 pv.00 logvol / --vgname=vg00 --size=2500 --name=vol_root logvol /tmp --vgname=vg00 --size=500 --name=vol_tmp logvol /var --vgname=vg00 --size=2500 --name=vol_var logvol /opt --vgname=vg00 --size=1 --name=vol_opt --grow anaconda throws an error when trying to create var_vol: "/usr/src/build/761796-i386/install//usr/lib/anaconda/fsset.py", line 2061, in setupDevice raise SystemError, "lvcreate failed for %s" %(self.name,) SystemError: lvcreate failed for vol_var i take a look at the kickstart environment, and notice that vol_opt is getting created before vol_var, and it has grown to 2.19GB. because it takes up this disk space, there is not enough space left on the device for vol_var and anaconda raises the error. that is, "lvm lvdisplay" at the kickstart shell shows: LV Name /dev/vg00/vol_root LV Size 2.47 GB LV Name /dev/vg00/vol_opt LV Size 2.19 GB LV Name /dev/vg00/vol_tmp LV Size 512.00 MB including /boot and swap, that leaves less that the requested 2.5GB for /var. i'm curious why the partitions aren't created in the order specified, or at least why any partition using --grow which also doesn't use --maxsize is allowed to be created before all other partitions with defined sizes. Version-Release number of selected component (if applicable): whichever anaconda comes on the boot media for RHEL4u3,AS,i386 (don't have the machine in front of me, sorry). first found there, also exists in RHEL4u4,AS,i386. haven't tested x86_64 or RHEL5 yet. unfortunately i can't email or attach the full anaconda error log or kickstart configuration file. i work for a customer who has an intranet with no external connection, and their security policy doesn't allow data to be copied in and out without a hard-to-acquire waiver. for the same reason, i do not have access to Internet email during the day so i can only respond to any questions in the evenings.
I can attest that this bug still exists in the RHEL 5 i386 installer. I too am using a virtual machine (VMWare Workstation 5) with an 8.5 GB hard disk. What's funny is that the same kickstart worked on RHEL 4.5. Here's the relevant section of my kickstart: clearpart --all part /boot --size=100 part swap --recommended part pv.01 --size=1 --grow volgroup clipvg pv.01 logvol /var --vgname=clipvg --size=1000 --name=var logvol /home --vgname=clipvg --size=1000 --name=home logvol / --vgname=clipvg --size=1 --name=root --grow Here is the output from anaconda when it fails: 10:07:11 INFO : moving (1) to step enablefilesystems 10:07:13 INFO : Running kickstart %%traceback script(s) 10:07:13 INFO : All kickstart %%traceback script(s) have been run 10:07:13 CRITICAL: Traceback (most recent call first): File "/usr/lib/anaconda/fsset.py", line 2418, in setupDevice raise SystemError, "lvcreate failed for %s" %(self.name,) File "/usr/lib/anaconda/fsset.py", line 1711, in createLogicalVolumes entry.device.setupDevice(chroot, vgdevice = vg) File "/usr/lib/anaconda/packages.py", line 148, in turnOnFilesystems anaconda.id.fsset.createLogicalVolumes(anaconda.rootPath) File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext self.moveStep() File "/usr/lib/anaconda/text.py", line 588, in run anaconda.dispatch.gotoNext() File "/usr/bin/anaconda", line 970, in ? anaconda.intf.run(anaconda) SystemError: lvcreate failed for var Switching to the shell and running "lvm lvdisplay" shows that "home" and "root" were created, but not "var".
For now, a workaround is to make your --size values multiples of the physical extent size. So instead of 500, use 512. Instead of 1000, use 1024. This is due to a bug in our LVM handling where we don't take into account the extra physical extent required when the LVM tools round these sizes up. It looks pretty tough to fix, so it might take a while to get sorted out.
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.
Fixed with commit 299e3166db7a1b00a434abeff8f9c9ebd6b2cac7. Should be included in 10.1.1.92. Backport of following commits from rhel5: commit cc9d0f4e57b11a37fc5d33d0374509e43a97840c commit 8b4c702d0c2c6130c5263a4944405efa1301ced9 commit 4f9c6e49d113a88a28c55c51bb5eab6ad756612b commit a68ab7d2823836ee90171cf419864e248ad99ce7 commit 4aa9ca1c35b867fa5a4d94c41591700ca7ab5edb (5.3 bug #415871) commit 08233b0c42f8b453ff7d8bde03c9adc57d92d7ed (5.3 bug #463780) Tested with reproducer from comment #1 and reproducers from bug #415871 and bug #463780 which are the last two commits of the list above. Also fixes reproducer in bug #222209 which is probably duplicate of this bug.
verified with anaconda-10.1.1.96-1 and reproducer from comment #0 on 8.5GB disk with Xen/PV guest.
*** Bug 222209 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0978.html