Ignite-UX Frequently Asked Questions

# echo 'env_vars += "TZ=MST7MDT"' >> /tmp/installfs.out
# instl_adm -f /tmp/installfs.out
Note: The "timezone" keyword in the Ignite-UX config file determines
what timezone is actually applied to the system after the
installation is complete. Setting the TZ env variable as shown above
is only used during the installation. (See instl_adm(4) for the
"timezone" keyword).
===============================================================================
----------------------------------------
3. Configuration Files
----------------------------------------
3.1
Q: What should go in which configuration file? Also, what should go in
INSTALLFS?
A: Here is a short description of the common uses of the various
configurations. Obviously, there can be situations that are not
"common" and variations will occur:
- INSTALLFS (accessed/modified via instl_adm(1M)) - Information that
is needed at boot, such as GUI controls and networking.
- /var/opt/ignite/config.local - Information that should be globally
applied to all clients and defines the post_[load/config]_scripts
run on all clients.
- /opt/ignite/data/Rel_<release>/config - This file sets the
definitions for that release and should not be modified.
- /var/opt/ignite/date/Rel_<release>/*_cfg - Information regarding
software selections/sources. These files should be created by
make_config (run against an Software Distributor depot) or in the
archive case, edited versions of the examples in
/opt/ignite/data/examples/[core|noncore].cfg.
When Ignite-UX is run for a client, all of these configuration files
are combined and parsed. If there are conflicting or duplicate
definitions, the order in which the files appear in the INDEX file
determines the precedence with the last file listed (typically
config.local) having precedence over all but the INSTALLFS
definitions.
A potential breakdown can occur if the client was previously
installed and the per client directory in /var/opt/ignite/clients
exists and is populated with the previously resolved configurations.
In this case, the previously resolved config.full has precedence.
===============================================================================
3.2
Q: How do I preview configuration file changes?
A: DESCRIPTION: Fixing syntax problems with mod_kernels results in statements
of the following form:
mod_kernel += "maxdsiz " + ${_maxdsiz}
There does not seem to be a way to preview the effects of these types
of statements. Can a comment be added to the config.full with the
string that was being output?
SOLUTION: The config.full file has the variable values replaced with
the real values so if you review this file, you should be able to see
what the real mod_kernel statement has become. In this case, you
would see the following:
mod_kernel += "maxdsiz 0"
Another option would be to have the configuration file push a shell
prior to the kernel build using a post_load_cmd:
post_load_cmd += "/sbin/sh;"
===============================================================================
3.3
Q: Is there a way to set the configuration files to ignore the disk
warnings, which can prevent automated installations?