Joe_Wulf wrote:
I would have liked to have seen or found a 'users manual' for kickstart.
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/index.html
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-options.html
and "yum install system-config-kickstart"
- When I build a system with KS, why does the /root/anaconda-ks.cfg file
NOT reflect exactly what the source ks.cfg looked like?
Anaconda records all of it's choices, including choices made
interactively in the installer. The anaconda.ks file can
be used to reproduce the install choices, including questions not posed
in the original kickstart.
Perhaps you could give a concrete example of something showing up that
you did not expect and was not what you wanted?
- I want to build many systems from many versions of the RedHat OS's. Why
doesn't the kickstart configuration NATURALLY understand each OS I've
copied into my ks server and build ks-cfg files that work natively with
that version of the OS.
Each version of the OS has new features that cannot be expressed in
previous versions.
An example is the "repo" functionality that was added for RHEL 5 / FC 6.
This functionality is very powerful but was not available in EL 4.
Ergo, if you request to use it in your kickstart, that should be an
error, else you won't be able to install packages from external repos
that you
may have mentioned in the packages section.
Keeping seperate kickstarts for seperate OS's is desired behavior,
because they are seperate OS's and therefore require different answer files.
If you want something to manage those configurations, look at something
like http://cobbler.et.redhat.com, use RHN, or write your templating
system, however
simple or complex you'd like it to be.
--Michael
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
