Description of problem: The --percent option to kickstart's logvol command does not behave the way it is supposed to, or the way it originally behaved. It is supposed to be an alternative way to specify a fixed size, the difference being that instead of giving the literal size you're giving it as a percentage of free space in the vg. The way it has been working for some time now is that percent indicates how much the logvol should grow as a percentage of the vg's free space. This requires users to specify a base size (--size), that the request is growable (--grow) and then the percentage of free space to grow into. I think it is clear that the first/original interpretation is easier to understand and generally more useful. Version-Release number of selected component (if applicable): anaconda- How reproducible: anaconda-21.48.6-1 Additional info: This will also require an update to the installation guide, which I think has already been done.
anaconda-21.48.8-1.fc21, python-blivet-0.61.3-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/python-blivet-0.61.3-1.fc21,anaconda-21.48.8-1.fc21
Package anaconda-21.48.8-1.fc21, python-blivet-0.61.3-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-21.48.8-1.fc21 python-blivet-0.61.3-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11977/python-blivet-0.61.3-1.fc21,anaconda-21.48.8-1.fc21 then log in and leave karma (feedback).
Package anaconda-21.48.8-1.fc21, python-blivet-0.61.3-1.fc21, pykickstart-1.99.60-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-21.48.8-1.fc21 python-blivet-0.61.3-1.fc21 pykickstart-1.99.60-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11977/pykickstart-1.99.60-2.fc21,python-blivet-0.61.3-1.fc21,anaconda-21.48.8-1.fc21 then log in and leave karma (feedback).
anaconda-21.48.8-1.fc21, python-blivet-0.61.3-1.fc21, pykickstart-1.99.60-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
I tried to make a test installation with Fedora 21 RC4 with kickstart using my kickstart configuration files from Fedora 19 and 20, and failed because of the change described in this bug report. I have used the following kickstart options for partitioning a (new) disk (here a kvm virtual machine): clearpart --initlabel --all --drives=vda part /boot --fstype ext4 --size 1000 --asprimary --ondisk=vda part pv.system1 --size 50000 --grow --asprimary --ondisk=vda volgroup system pv.system1 logvol swap --vgname=system --name=swap --fstype=swap --size=5000 --grow --maxsize=40000 --percent=15 logvol / --vgname=system --name=root --fstype=ext4 --size=20000 --grow --maxsize=60000 --percent=60 logvol /var --vgname=system --name=var --fstype=ext4 --size=5000 --grow --maxsize=40000 --percent=25 I got an error that --size and --percent cannot be specified for the same logvol. PLEASE can we have back the previos behavior! I think the new behaviour of --percent is not useful in some cases because kickstart have to ensure that particular disk partitions have at least a minimum size which is needed for installation. For example, the root partition (/) must be at least as large as the total size requirements of all packages that will be installed. The new --percent option cannot fullfil this requirement. It would be ok if the option names will change to get the previous behavior, because I agree that the nameing was somehow confusing, so the old and the new behaviour can coexist. Proposal: Add an option --minsize analog to --maxsize, and an option --relpercent (or another named option) to get the previous behavior back. I think parts of the previous code for the old options can be reused for the new (renamed) options, so I think the expense is not to much. If the update doesn't go to Fedora 21 release (I am sorry that I have started testing very late), please can you provide an update.img file too that can be used during kickstart to get the old behavoir back for F21 (and not have to wait for F22 and doing some ugly workarounds until then)? Many thanks in advance!
(In reply to Edgar Hoch from comment #5) > For example, the root partition (/) must be at least as large as the total > size requirements of all packages that will be installed. The new --percent > option cannot fullfil this requirement. The percentages indicate a fixed (base) size as a percentage of the VG size. You should be able to basically use the same snippet without any --size= options. Is there a reason this won't work for you? Are you saying that you can know in advance the sum of the installed packages' sizes but not the amount of disk space? You'll have to be clear about what you need and why the current functionality is inadequate.
I want to explain it with an example. Suppose I have an older notebook with a 100 gb hd and desktop pc with a 500 gb hd. Also suppose that I want to use the same kickstart file for all computers, because it is expensive to write individual kickstart files for each computer (think of about 200 computers...). The --crow option is exact for such cases where the same kickstart file is used for different hardware configurations. In the case of the notebook with a 100 gb disk, I want to create the following configuration (using fixed values): - One partition, for example sda1, for /boot, with ext4, size 1 gb. - A second partition, sda2, for lvm, allocating the whole disks space except of that of sda1. - Create a lvm vg named "system" on sda2. - Create a lvm lv named swap on vg system, for swap, size 10 gb. - Create a lvm lv named root on vg system, for /, with ext4, size 40 gb. - Create a lvm lv named var on vg system, for /var, with ext4, size 15 gb. - Create a lvm lv named home on vg system, for /home, with ext4, size 29 gb (rest of free space in vg system). In the case of te desktop pc with a 500 gb disk, I want to create the same configuration, but with different sizes: - lv swap: size 40 gb (instead of 10 gb). - lv root: size 60 gb (instead of 40 gb). - lv var: size 40 gb (instead of 15 gb). - lv home: size 359 gb (rest of free space in vg system). Reasons: - My kickstart file configures only a limited set of packages that will fit on a smaller disk, too, so kickstart will not break. Later, after booting the installed system, I run a script that installes more (optional) packages depending on the size of the root partition. - I need to ensure that root is at least as big as it is neccessary for my minimal package list (lets say, 20 gb). This is the reason why a --minsize (or --size as used before the change) is required. - All my packages I will install (in the near future, with all the optional packages in my list) will fit on a 60 gb partition. It doesn't make sense to make root bigger than that limit. This is why I have used --maxsize . And disk space assigned to root over that limit is wasted disk space, and should be used for other partitions (for example, for /home or for a data partition). - The same applies to var and swap. I need at least a minimum disk space allocated for these partitions to ensure that the system will work (swap for /tmp in tmpfs, /var for package cache, log files, etc.). If enough disk space is available, I can assign more disk space, but I think usually on /tmp will be only small data, and a high swapping system is slow, so it doesn't make sense to configure swap very big, lets say 20 gb or 40 gb are big enough, more swap space would (and should) eventually never used. The same for /var - 40 gb is enough for yum cache, logs, abrt files, print spool data, mail spool, etc. - I want to assign the remaining disk space to a useful partition, lets say /home, or a data partition (for example, /data). This is only possible if the size of root, var and swap are limited! To summarize, the size of swap, root and var should be limited to a maximum size, but they have to be at least as big as the minimum size. The remaining disk space should be assigned to another partition (for example, /home), unlimited, or remain unallocated so that the administrator can assign it later on demand. If --grow and --percent are based on the size of the whole volume group instead of the difference of minsize and maxsize, then partitions swap, root and var will grow much more on a system with a big disk (for example, 500 gb instead of 100 gb) than disk space is needed for real data. I don't want to have a root partition of 300 gb and a /home partition of 100 gb, but a root partition of 60 gb and a home of 340 gb (for example). The difference of 300 gb - 60 gb = 240 gb is wasted disk space, it will never be used. This is the reason why --percent based on the whole volume group size does not fit for partitioning disks without wasting disk space, where the disk size vary from small to big, using the same kickstart configuration.
(In reply to Edgar Hoch from comment #7) Your desired layout is incredibly specific and, in many ways, the limits you have established are arbitrary. If you were not committed to limiting root at 60G and swap at 40G you could use simple percentages. You have two good options: 1. use a combination of --percent, --grow, and --maxsize 2. write a %pre script to dynamically generate a set of logvol commands (using %include in the main section of the kickstart) Option 1 is significantly simpler, but the results you get will generally scale more consistently with the total disk space and it will be more difficult to impose the very specific limits you described. For example, making swap be 10% of the vg size would be very close to what you want. Option 2 is a bit more cumbersome, but you will be able to specify whatever proportions and limits you want based on the system you are currently installing. Side note: It might be of interest to you to know that growable volumes within a volgroup have growth rates proportional to their base sizes. That means a logvol with --percent=10 will grow at one-fifth the rate of a logvol with --percent=50. The same applies when --size is used instead of percent.