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
are supposed to grow.
3) If any partition is above the maxsize, remove the additional space from those
distribute again evenly over all partitions which can still grow. Repeat this
all are below maxsize.
BTW, one could also introduce a "--userest" option, which would use all the
(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.