If you maintain the core operating system (OE) and the applications media in different depots, you may need to make customizations for the bundles you have created that define patches. If some products are installed from the applications depot instead of the core operating system (OE) depot and you have patches that depend on the filesets in the bundles that are taken from the applications depot, you may need to set the load_order on sw_sel clauses describing patches to be >10. This guarantees that the patches are loaded after all software from the applications depot is installed.

You can do this by directly modifying the configuration files created to describe the patches or by adding a sw_sel similar to the following to the customization file; not in the configuration file that actually defines the patches:

sw_sel "ISO_patches" { load_order=15

}

This takes advantage of something that described earlier. If you have a sw_sel mentioned twice, the information defined in the second clause overrides the information previously defined. In this case, no load_order was defined for the sw_sel, ISO_patches so the change adds the existing definition to change its load order since the default is 5.

A load_order of 10 ensures that the patches are loaded after the core operating system (OE), which is loaded at load_order 0, and the applications that default to load_order 5.

Installing with SD wrap-up

The previous sections illustrated the following concepts:

∙How simple it can be to use SD to install systems; installation from an Ignite-UX server over the network was employed in the examples presented.

∙How to setup your Ignite-UX server for use with SD installations.

∙How to manage your configuration explaining some of the issues that you face when managing your configuration.

∙Why it is a good idea to separate configuration that belongs to depots or archives from the default configuration supplied with Ignite-UX and custom configuration that you may layer over the default.

∙Where possible you should not modify the configuration files created by Ignite-UX commands. If you change the software in a depot, you will probably want to recreate the configuration file that describes the depot; if you have manual changes you must review the file and reapply the same changes to the new configuration file. This is time consuming so keeping the configuration separate means you only have to be aware of changes and review the customizations layered on top of the other configuration files periodically.

Performance considerations for SD-UX based installs

The following section provides information for you to consider when you have an Ignite server that is intended to perform large numbers of concurrent cold installs using SD-UX (more than three at one time). In the following discussion, only the information regarding network bandwidth applies to all the methods Ignite-UX can use to perform install or recoveries (SD-UX-based installs, archive- based installs, and recovery sessions.)

191