Red Hat Bugzilla – Bug 1284660
issue: kickstart fails with 3way raid1 array setup on RHEL 7.1
Last modified: 2016-11-03 19:51:51 EDT
Description of problem:
it complains about insufficient disks only when i try to create raid level 1 across more than 2 disk partitions using kickstart file. (see logs boot_3on6_rh7.tgz (63.3 kB))
Creating raid 1 across 2 disk partitions works fine (see logs raid-2on2_rh7_logs.tgz (59.0 kB) )
Version-Release number of selected component (if applicable):
ERR anaconda: storage configuration failed: not enough space for LVM requests
INFO anaconda: fs space: 0 B needed: 1524.54 MiB
Space is available and installable
> Not enough space in file systems for the current software selection. An additional 1524.54 MiB is needed.
23:05:29,005 ERR anaconda: storage configuration failed: not enough space for LVM requests
23:05:33,688 INFO anaconda: fs space: 0 B needed: 1524.54 MiB
The needed size almost matches the os image specified in liveimg kickstart command.
23:05:26,741 DEBUG packaging: liveimg size is 1598596032
The related code:
free = Size(self.storage.fileSystemFreeSpace)
needed = self.payload.spaceRequired
log.info("fs space: %s needed: %s", free, needed)
""" Grow LVs according to the sizes of the PVs.
Strategy for growth involving thin pools:
- Applies to device factory class as well.
- Overcommit is not allowed.
- Pool lv's base size includes sizes of thin lvs within it.
- Pool is grown along with other non-thin lvs.
- Thin lvs within each pool are grown separately using the
for vg in storage.vgs:
total_free = vg.freeSpace
if total_free < 0:
# by now we have allocated the PVs so if there isn't enough
# space in the VG we have a real problem
raise PartitioningError(_("not enough space for LVM requests"))
elif not total_free:
log.debug("vg %s has no free space", vg.name)
Please retry with RHEL7.2, and if it still fails attach the logs from /tmp/*log as individual text/plain attachments.
Created attachment 1101171 [details]
Created attachment 1101173 [details]
Created attachment 1101175 [details]
Created attachment 1101179 [details]
Created attachment 1101181 [details]
7.2-partdata - partition kickstart commands
Created attachment 1101182 [details]
Created attachment 1101183 [details]
This is caused by the code in LVMVolumeGroupDeviec.freeSpace which adds padding for lvm-on-raid. It adds 5 extents for each disk (there are three) in the raid. The user chose a 32 MiB extent size, so each new LV (there are three) uses an extra 480MiB in the VG. The result is that the VG (in blivet's model) runs out of space sooner than it should.
What is the workaround here? Will reducing the extent size help? Like say 4MB?
(In reply to Arun S A G from comment #11)
> What is the workaround here? Will reducing the extent size help? Like say
Yes, that should help. The real fix here is to improve calculations of VG free space in Blivet like we did on master/rawhide.
Ported fixes from the master branch are proposed for the rhel7-branch as:
(In reply to Vratislav Podzimek from comment #13)
> Ported fixes from the master branch are proposed for the rhel7-branch as:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.