On 6.4 GB drive I had: part / --size 1024 part swap --size 512 part /tmp --size 512 part /config --size 1024 part /var --size 3072 part /opt --size 1 --grow There is enough space for everyone. (Though the partitioning is clearly optimized for bigger disks). Now, kickstart creates the partitions very recklessly. / partition isn't first on the disk. I don't have this here at the moment, but I recall the partitions were ordered from the biggest to the smallest, like /var hda1, etc. Adding /boot makes the installed system bootable, but not necessarily sane. You can't control the ordering. If you reduce the sizes, like: part / --size 1024 part swap --size 512 part /tmp --size 512 part /config --size 512 part /var --size 500 part /opt --size 1 --grow , or install on a bigger disk, you get what you expect: /dev/hda1 / /dev/hda5 swap /dev/hda6 /tmp /dev/hda7 /config /dev/hda8 /var /dev/hda9 /opt (in the order they were defined in ks.cfg). Haven't checked whether 7.1 is similarly affected.
http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/s1-kickstart2-commands.html Take a look at the above URL for kickstart documentation. You can make kickstart do what you want it to by passing in various options. If you want / to be created first, you can use the --onprimary <N> flag. Does this fix your problem?
That does not work properly. If you define: part / --size 1024 --onprimary 1 part swap --size 512 [and so on] The auto-partitioning will fail if the partitions exists even though there is 'clearpart --all' with: Failed to allocate '/': No free primary
Can you attach your complete kickstart file?
Created attachment 16005 [details] %packges and %post have been snipped as they're of no consequence here
Created attachment 16006 [details] %packges and %post have been snipped as they're of no consequence here
Created attachment 16007 [details] packages and post have been snipped as they're of no consequence here
Whoops. Attaching seemed to freeze but apparently it works.
I just did a minimal kickstart install with your kickstart file with no problems. Here's what df says on that system: /dev/hda1 1035660 157916 825136 17% / /dev/hda6 1035660 20 983032 1% /config /dev/hda9 3621020 20 3437060 1% /opt /dev/hda8 521748 24 495220 1% /tmp /dev/hda5 3099260 4172 2937656 1% /var
Yeah, that works. Try to install on a smaller HDD, like 6.4 GB, and there _should_ be problems. Other way to incite get on the one you currently are using might be to make bigger partitions. I'm guessing: part / --size 2048 part swap --size 512 part /tmp --size 512 part /config --size 2048 part /var --size 4096 part /opt --size 1 --grow would be enough (/opt would be like 600 megs) Reopening just in case.
Yes, I see what you mean. A complete rework of the partitioning subsystem is on the drawing board, so I expect this problem to be fixed by that. As such, there's not much use in patching the existing code. Thanks for your report.