Overview of how AI install works
Before using the Automated Installer (AI), it's a good thing to start with a basic understanding of how the AI functions work at a high level.
At a high level, it takes a manifest and profile to determine which packages get installed, and what the identification of the system will be like. This is somewhat similar to the old jumpstart flow—which used a profile rather than a manifest—and a sysidcfg file instead of what is now called a profile.
There the resemblance mostly ends. Oracle has extensively changed the means by which the two pieces of information get to the system, and also how their contents are selected.
In the prior Solaris versions, a jumpstart client system downloaded and examined a rules file to find the best match for itself. It then read the matching profile to determine what its disk layout should be, which packages should be installed, and so on.
Oracle has now made this sort of thing a database-driven operation, albeit a simpler database than Oracle Enterprise. There is a special service tasked with providing a target system with a manifest and a profile, based on various levels of criteria.
First, there is the service name. This can be specified or overridden by the client. In theory it could be used very flexibly; but in practice, every service name ends up with its own OS boot image, so it might be better named (or at least thought of) as target OS version.
Next, there is the manifest. As mentioned previously, this determines almost everything about what packages go on disk, as well as the disk layout, and so on. It is entirely up to the server as to which manifest the client receives (if the client is honest about itself at least). Customization of manifests for different install types is commonly done by hand-editing XML.
Lastly, there is the profile. This determines the system identity. This is exactly the information generated by the new sysconfig command, and in fact that is the command you would normally use to generate it.
AI installer client-side services
Normally, the AI image automatically starts the following two services on the client after boot time:
svc:/application/manifest-locator:default svc:/application/auto-installer:default
If you boot without the install option enabled or if they fail, the services may be left in a "disabled" or "maintenance" mode. Unfortunately, once you log in, you may or may not be able to restart the service. The good news is however, that it is not a true continually running service. It is the SMF-hacked equivalent of a hook in /etc/rc2.d/S00xxx. So you have a choice of either manually enabling them with svcadm, or directly invoking the install command that the service would normally start as follows:
auto-install -m /system/volatile/ai.xml
This file does not initially exist. In a fully-default install, the contents of this file are identical to /usr/share/auto_install/default.xml, so the simplest method to get a default AI install rolling again, is as follows:
auto-install -m /usr/share/auto_install/default.xml
Alternatively, download or create a custom manifest file as needed.
It should be noted that the default manifest for the AI image installs the set of packages known as the svc:/group/system/solaris-large-server group, which has 462 packages.
So, don't panic if you happen to use pkg list from the OS you boot into for the installer image. Even though it only shows packages contained in svc:/group/system/solaris-auto-install, which contains 335 packages, it will install any grouping you like from the network repository.
The manifest-locator service, svc:/application/manifest-locator, is relatively simple. It contacts the install service, identifies which service name it is interested in, and what it believes its own hostname, IP, and basic characteristics are. It then saves the manifest and profile returned to it to /system/volatile/ai.xml and /system/volatile/profile/### respectively.
It knows what install server/service to connect to, via the install_svc_address and install_service properties provided through either the GRUB menu kernel line, or the wanboot system.conf file provided to the client. As a matter of curiosity, at the lowest level it tends to call the following command:
ai_get_manifest -s x.x.x.x:5555:default-(sparc/i386) -o /system/volatile/ai.xml -p /system/volatile/profile
The auto-installer service, svc:/application/auto-installer, is not any more complicated than the manifest-locator service.
It first checks to see if the "install" keyword was provided at boot time, and if not, it exits.
Otherwise, it is hardcoded to look in /system/volatile/ai.xml and the /system/volatile/profile/ directory, for a manifest and profile to use for installation.
It is good to know this for two reasons: first of all, because you can manually copy over the relevant files to their respective places, and then restart only the auto-installer svc if desired. Secondly, because it is possible to skip restarting the service, and just directly call the same program the service does, with the same arguments.
auto-install -m /system/volatile/ai.xml -c /system/volatile/profile
AI installer server-side services
An AI install server usually provides a source of manifests and profiles over the network to AI clients, managed by installadm. In addition, it can be a source of packages. It may serve a copy of the Oracle packages, or extra packages, or a combination of both.
Serving packages is done by creating or copying an IPS repository. Once this is created, it can be shared through either an SMF svc:/application/pkg/server instance, or through plain old NFS. For more details refer Chapter 1, IPS - The Image Packaging System.
Once you have your own repository, you can either replace the existing Oracle entry in the relevant manifests, or augment it by adding your own in addition to it. The section in the manifest is as follows:
<publisher name="solaris">
<origin name="http://pkg.oracle.com/solaris/release"/>
</publisher>