I use ----------- clearpart --linux part / --size 2500 --grow --maxsize 3000 part /boot --size 25 part swap --size 127 part /backup --size 1 --grow ------------ in my ks file an I would expect a 3G / and a "all the rest"G /backup partition, but what do I get: a 2.9G /, a 30M /backup partition and the rest unused!? [root@s1 /root]# df -h Filesystem Size Used Avail Use% Mounted on /dev/hda5 2.9G 1.7G 1.0G 61% / /dev/hda7 30M 13k 28M 1% /backup /dev/hda1 30M 3.3M 25M 12% /boot [root@s1 /root]# fdisk -l /dev/hda Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 4 32098+ 83 Linux /dev/hda2 5 1245 9968332+ 5 Extended /dev/hda5 5 387 3076416 83 Linux /dev/hda6 388 404 136521 82 Linux swap /dev/hda7 405 408 32098+ 83 Linux
I've verified this problem. I think a workaround is that if you don't use --grow for the / partition. Just go ahead and make it 3 GB and use '--grow' for the /backup partition. There seems to be a problem with using more that one '--grow' tag. We'll look at this.
Some of my machines don't have enough space for a 3GB / partition;-( I suggest the following simple algorithm: 1) Assign the minimal amount of space to each partition. 2) If there is space left, distribute the remaining space evenly over all partitions which are supposed to grow. 3) If any partition is above the maxsize, remove the additional space from those and distribute again evenly over all partitions which can still grow. Repeat this step until all are below maxsize.
BTW, one could also introduce a "--userest" option, which would use all the remaining space (if any) for this partition.
We are currently re-engineering the partitioning section, so this problem should not occur in the future. Thanks for your report.