OpenSolaris 2010.03 Automated Installer Guide
Previous Next

How to Create and Use a Custom AI Manifest

When you create an install service by using the installadm create-service command, an AI manifest is automatically copied to the install service. This manifest has default settings that are sufficient for client installations. However, you can make a custom manifest and change the specifications in that manifest to create specific installations for specific clients.See the following sections.

Reviewing the AI Manifest Tags

The AI manifest is an XML file that contains a series of tags and tag values. Each tag and value is enclosed inside XML tags.

The XML tags all contain a start tag, such as <name>, and an ending tag, such as </name>. Within each tag, a tag name is given, then that tag's value is given. A tag is a parameter that specifies a piece of information about the manifest itself or about the manifest's installation specifications. Each tag has a value that can be edited to modify the manifest information or to modify the installation specifications in the manifest.

For example, see this line in the manifest:

<ai_manifest name="default">

This <ai_manifest name> tag assigns a name to the manifest. The value that is given for this tag is “default.” You can change this value.


Note - The <ai_manifest name> tag with the value, “default,” indicates that the manifest is the default manifest. There can be only one default manifest per install service. You can modify or replace the default manifest.


Note the following information about other tags in the AI manifest:

  • You can use the <ai_target_device> tag to specify a particular target disk on which to install the OpenSolaris OS. See Defining a Target for the Installation. If you do not specify a target disk, the automated installer chooses a default target for installing the OpenSolaris OS.

    1. The installer gets the recommended size for installing the OpenSolaris OS from the AI libraries. Currently, the recommended size is 13 GB.

    2. The installer searches for available disks on the client. To determine the default target, the automated installer looks for an available disk with at least recommended size.

    3. When the first disk is found, the installer checks the size of that disk.

      • If the size is greater than or equal to the recommended size, the installer selects the disk and returns to the installation procedure.

      • If the size is less than the recommended size, the installer goes to the next disk to check the size.

    4. If there is no match, the automated installation fails.

  • The tag, <ai_pkg_repo_default_publisher>, defines the IPS repository from which the installation will be performed. You need to provide the URL of the IPS repository and the publisher. In the default AI manifest, the IPS repository is set to http://pkg.opensolaris.org/release/, and the publisher is defined as opensolaris.org.

  • In the tag, <ai_install_packages>, the default manifest instructs the automated installer to install the following packages to the client:

    • entire

    • SUNWcsd

    • SUNWcs

    • babel_install


    Note - Due to dependency issues, entire must be listed first in the package list, followed by SUNWcsd, and then SUNWcs. Any additional packages must be listed after SUNWcs.


  • The tag, <ai_uninstall_packages>, lists packages, babel_install and slim_install, that will be uninstalled from the client.


    Note - Why does the default manifest first install the babel_install package, then uninstall it?

    babel_install is a cluster consisting of a set of packages. When the babel_install cluster is installed, all the packages in the cluster are installed. However, you cannot uninstall packages that belong to a cluster. By uninstalling the cluster definition, the individual packages can be deleted later. babel_install is used for convenience to install all the required packages, but the cluster definition is not needed after installation of packages are completed. The default manifest removes the cluster definition, so that further customization of the packages can be done.

    slim_install is another cluster. And, slim_install is part of babel_install which is installed by the default manifest. The default manifest uninstalls slim_install, in order to permit customization.


  • The tag, <ai_auto_reboot>, can be used to request automatic reboot after successful installation. The default value is false, meaning that the client does not automatically reboot after successful installation. If this value is changed to true, the client automatically reboots after successful installation.

  • The second part of the default AI manifest is an embedded SC manifest, beginning at the line:

    <sc_embedded_manifest name = "AI">

    For instructions about how to modify the SC manifest, see How to Create Custom SC Manifest Files.


Note - For a summary of the AI manifest contents and possible values, see AI Manifest Contents.


Replacing Default AI Manifest with a Custom Manifest

You can replace the default AI manifest for an install service with a custom manifest that you created and revised to suit specific client specifications. Use the following procedure to create a custom manifest and assign it to an install service.

  1. Copy the automated installer's default manifest from the target image path that is associated with the install service you plan to use.

    The target image path for an install service can be determined with the following command, where srvname is the name of the install service.

    #  # installadm list -n srvname

    For example, see the following command and output:

    # installadm list -n svc1
       Service Name Status       Arch    Port  Image Path
       ------------ ------       ----    ----  ----------
       svc1         on           sparc   45603 /export/aiserver/svc1

    In the above example, the install service, svc1, has an image path of /export/aiserver/svc1. The default manifest, default.xml, located in this image path is at:

    /export/aiserver/svc1/auto_install/default.xml

    Note - For services created with images that date back prior to the OpenSolaris 2009.06 release, you can copy the default.xml manifest located on the install server at /usr/share/auto_install/default.xml.


  2. Keep the <ai_manifest name> tag in your manifest copy set to the value of default.

  3. Revise the <ai_embedded_manifest> and <sc_embedded_manifest> sections of your copy as needed.

  4. Use the installadm add command to replace the default manifest for an existing install service with your copy as follows:

    # /usr/sbin/installadm add -m manifest_file -n svc_name

    Where manifest_file is the name of the manifest copy that you created and modified, and where svc_name is the name of the install service.

    The installadm add command validates your manifest before replacing the default manifest.


Note - The build number or release of the OpenSolaris operating system that you specify in the AI manifest must match the build number or release of the AI ISO image that you specify in the installadm create-service command with the -s option. For further information, see Specifying Packages to Install a Specific Version of OpenSolaris.


Modifying AI Manifest Contents

Once you've created what will be your custom AI manifest, you can edit the tags in this custom file. The following examples show options for modifying the contents of your custom AI manifest.


Note - The examples in this section are partial excerpts from AI manifest files, showing only the tags being discussed in that example. Only the last example shows a complete AI manifest.



Note - For further information about specific AI manifest tags and valid values for these tags, see AI Manifest Contents.


Defining a Target for the Installation

You can specify a target location on a client for installing the OpenSolaris OS as described below.


Note - If you do not specify a target disk, the automated installer chooses a default target for installing the OpenSolaris OS. See 14. How is the Default Target Disk Selected?.


There a variety of options for specifying a target installation location. One option is to enter an MPXIO name or a logical device name in the tag, <ai_target_device>, as shown in these examples.

Using a logical device name:

...
<ai_target_device>
     <target_device_name>c0t0d0</target_device_name>
</ai_target_device>
...

Using an MPXIO name:

...
<ai_target_device>
     <target_device_name>c0t0000002037CD9F72d0</target_device_name>
</ai_target_device>
...

Or, you can specify a VTOC slice as the installation target. See Using a VTOC Slice as the Installation Target.

Alternately, starting with the OpenSolaris 2010.03 release, you can use the following new options to specify an installation target.

You can specify multiple criteria for determining the installation target, but there are limitations. See Using Multiple Criteria to Specify an Installation Target.

Using the Boot Disk as the Installation Target

The <ai_target_device> tag now accepts boot_disk as a keyword. This keyword can be used to specify the current boot disk as the installation target as follows:

...
<ai_target_device>
    <target_device_name>
        boot_disk
    </target_device_name>
</ai_target_device>
...

Note the following limitations to the boot_disk keyword:

  • The boot_disk keyword does not work in XEN/PV, because information about the boot disk is not available in that environment.

  • Some x86 BIOS's do not report the boot disk correctly. See http://bugs.opensolaris.org/bugdatabase/view_bug_.do?bug_id=6831009.

  • For SPARC clients, if the diag-switch? OBP property is set to true, information about the boot disk is not available. If you would like to utilize boot disk keyword on SPARC platforms, check that the diag-switch? is set to false.

Using the Device ID to Specify an Installation Target

You can use the new <target_device_select_id> tag to select a target disk by its device ID.

You can get the device ID by using the iostat command as in this example:

$ iostat -iEn

c7d0             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: ST31000340NS    Revision:  Device Id:
id1,cmdk@AST31000340NS=9QJ2LNYY
...

Include the <target_device_select_id> tag as shown in the following example:

...
<ai_target_device>
    <target_device_select_id>
        id1,cmdk@AST31000340NS=9QJ2LNYY
    </target_device_select_id>
</ai_target_device>
...

Note the following limitations for the <target_device_select_id> tag:

  • The tag does not work in XEN/PV, because the Device ID is not available for virtual drives.

  • The iostat command does not report the Device ID on LDOM guests. However, that information is available, and can be obtained by using the Target Discovery test driver which is present in the automated installation application. Use the test driver as demonstrated in this example.

    # /opt/install-test/bin/tdmgtst -dv | grep ddm_disk_dev_id
    ddm_disk_dev_id=id1,vdc@f8498536e4a8ad037000bcb400001
Using Physical Device Path to Specify an Installation Target

You can use the new tag, <target_device_select_device_path>, to select a target disk by specifying the physical path in the /devices directory.

One way to find the physical path is to look at the related c#t#d#s# symbolic link, as in the following example.

$ ls -l /dev/dsk/c7d0s0
lrwxrwxrwx 1 root root 51 2009-04-03 00:20 /dev/dsk/c7d0s0 ->
../../devices/pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0:a

Include the <target_device_select_device_path> tag as shown in the following example:

...
<ai_target_device>
    <target_device_select_device_path>
        /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0
    </target_device_select_device_path>
</ai_target_device>
...
Using Volume Name to Specify an Installation Target

You can use the new tag, <target_device_select_volume_name>, to select a target disk by specifying a volume name that was created using the format command.

The following example shows how to create a volume name.

format -d c0d0 > /dev/null 2>/dev/null - <<EOF
volname
"ai-disk"
y
quit
EOF

Include the <target_device_select_volume_name> tag as shown in the following example:

...
<ai_target_device>
    <target_device_select_volume_name>
        ai-disk
    </target_device_select_volume_name>
</ai_target_device>
...
Using an iSCSI Target for Installations

With iSCSI technology, you can install to a disk drive hosted by another computer on the same TCP/IP network. Starting with the OpenSolaris 2010.03 release, you can specify an iSCSI target for automated installations, as shown in this example.

...
<ai_target_device>
    <target_device_iscsi_target_name>iqn.1986-03.com.sun:02: \
c9e1533d-2d61-c198-b4ea-a9e3c40a49dd</target_device_iscsi_target_name>
    <target_device_iscsi_target_ip>10.0.0.1</target_device_iscsi_target_ip>
    <target_device_iscsi_target_port>3260</target_device_iscsi_target_port>
    <target_device_iscsi_target_lun>0</target_device_iscsi_target_lun>
</ai_target_device>
...

The following table describes each iSCSI tag.

Table 8-1 iSCSI Tags

Tag Name

Description

Required?

Valid Values

<target_device

_iscsi_target_name>

Target name, such as IQN, EUI, or NAA

Required

A-Z, a-z, 0–9, periods, hyphens, colons

<target_device

_iscsi_target_ip>

IP address of the target

Required

Valid IP address

<target_device

_iscsi_target_port>

IP port for the target

Optional, defaults to 3260

Integer between 0–65535

<target_device

_iscsi_target_lun>

Logical unit number specifies a SCSI device on the target. This may be needed to distinguish between multiple boot disks on the same target.

Optional, defaults to zero (0)

Decimal integers 0–16383 or 1–4 single hexadecimal digits separated by hyphens between 0 and 1–f-f-f

<target_device

_iscsi_parameter_source>

Indicates where the iSCSI boot parameters will be sought.

Optional, defaults to the AI manifest

“manifest”, “DHCP”

To specify an iSCSI target in the AI manifest, you must first create an iSCSI boot target by using the iscsitadm command. Then, use the iscsitadm information to complete the above iSCSI manifest tags. See (link to public wiki URL).


Note - To use an iSCSI target, the packages, SUNWiscsi and SUNWiscsidm, must be included in the <ai_install_packages> tag in the AI manifest as follows:

...
<ai_install_packages>
  ...
  <pkg name="SUNWiscsi"/>
  <pkg name="SUNWiscsidm"/>
</ai_install_packages>
...

These packages are in the default AI manifest. Check to be sure you have included them in any custom manifests.


Using Multiple Criteria to Specify an Installation Target

You can use multiple criteria to specify an installation target, but there are limitations.

Only one of following criteria can be specified at a time. And, the following criteria cannot be combined with other criteria:

  • <target_device_iscsi_parameter_source>

  • <target_device_name> – Using either c#t#d# or boot_disk

  • <target_device_select_volume_name>

  • <target_device_select_id>

  • <target_device_select_device_path>

The following criteria can be combined with each other. But, they are invalid if used with any of the criteria from the previous list.

  • <target_device_type>

  • <target_device_vendor>

  • <target_device_size>

The following examples show how you could combine these criteria.

In the following example, an SCSI Hitachi disk with at least 70 GB will be selected for the installation.

...
<ai_target_device>
        <target_device_type>
        SCSI
        </target_device_type>
        <target_device_vendor>
        HITACHI
        </target_device_vendor>
        <target_device_size>
        146800640
        </target_device_size>
</ai_target_device>
...

In the following example, an IDE disk with at least 12 GB will be selected for the installation.

...
<ai_target_device>
        <target_device_type>
        ATA
        </target_device_type>
        <target_device_size>
        25165824
        </target_device_size>
</ai_target_device>
...

Note - If an invalid manifest is provided to the AI client, the automated installation aborts when validating the manifest. Error messages indicating the cause of the failed syntactic validation can be found in /tmp/install_log file on installation client.


Using a VTOC Slice as the Installation Target

If a slice is not specified, the automated installer, by default, selects slice 0 on the client to install the OpenSolaris OS. If you would like to install the OpenSolaris OS on a different slice, you can specify the slice in the AI manifest in the <ai_target_device> tag.

This example instructs the installer to install the OpenSolaris OS on slice 4.

...
<ai_target_device>
     <target_device_name>c0t0000002037CD9F72d0</target_device_name>
     <target_device_install_slice_number>4</target_device_install_slice_number>
</ai_target_device>
...
Modifying the Partitions and Slices on the Install Client

You can modify the existing partitions and slices in the installation target. See the following options:

Creating an Extended Partition

Starting with the OpenSolaris 2010.03 release, you can create an extended partition in an fdisk partition table as part of your automated installation. An extended partition provides space for one of more logical partitions. Multiple logical partitions can be created in an extended partition.

You can create an extended partition, or create logical partitions in a new or existing extended partition, by using the <ai_device_partitioning> tag in the AI manifest. See the following examples.

Create an extended partition by using the <ai_device_partitioning> tag as in the following example:

...
<ai_device_partitioning>
     <partition_action>create</partition_action>
     <partition_size>max_size</partition_size>
     <partition_type>EXTDOS</partition_type>
</ai_device_partitioning>
...

In the example above, you are creating an extended partition. When applied to extended or primary partitions, the max_size value uses the largest region of free space on the disk to create the extended or primary partition. In the new extended partition, a logical partition is automatically created that uses all the space in the extended partition.

In this example, the partition type is set to EXTDOS. Other valid text values for the partition_type tag include the SOLARIS, DOS16, FAT32, and DOSEXT.

Create a logical partition inside an existing extended partition by using the same <ai_device_partitioning> tag as in the following example:

...
<ai_device_partitioning>
     <partition_action>create</partition_action>
     <partition_size>max_size</partition_size>
     <partition_type>SOLARIS</partition_type>
     <partition_is_logical>true</partition_is_logical>
</ai_device_partitioning>
...

In the example above, you are creating a new logical partition, of the type SOLARIS, within the existing extended partition, using any available free space in the extended partition.

The max_size value, as in the above example, specifies that the largest block of free space in the extended partition will be used for the logical partition.


Note - If there are no other logical partitions, the entire extended partition is used for the logical partition.

If there is more than one logical partition, the total space for all logical partitions in an extended partition cannot exceed the total space in the extended partition.

If there is no available space for the logical partition because another logical partition is already using all the space, this installation would fail.


Create an extended partition that contains two new logical partitions as shown in the following example.

<!-- create an extended partition in the largest block of free space -->
<ai_device_partitioning>
<partition_action>create</partition_action>
<partition_size>max_size</partition_size>
<partition_type>EXTDOS</partition_type>
</ai_device_partitioning>
<!-- create a 10G FAT32 logical partition on the extended partition you just created-->
<!-- in this example, the partition would consume the 
1st 10G of the extended partition -->
<ai_device_partitioning>
<partition_action>create</partition_action>
<partition_is_logical>true</partition_is_logical>
<partition_size>10</partition_size>
<partition_size_units>G</partition_size_units>
<partition_type>FAT32</partition_type>
</ai_device_partitioning>
<!-- create a Solaris logical partition using the largest unused free space 
in the extended partition -->
<!-- in this example, the partition would use the remaining space in the 
extended partition -->
<ai_device_partitioning>
<partition_action>create</partition_action>
<partition_is_logical>true</partition_is_logical>
<partition_type>SOLARIS</partition_type>
<partition_size>max_size</partition_size>
</ai_device_partitioning>

This example accomplishes the following:

  • Creates an extended partition using the largest region of free space available on the disk.

  • Creates a FAT32 logical partition in the extended partition, using the first contiguous 10GB of the available space.

  • Creates a Solaris logical partition using the largest remaining unused space.


Note - On a fragmented disk, you can create multiple logical partitions, specifying max_size, until all space has been used.


Deleting an fdisk Partition (x86 only)

Note - Partition operations are meaningful only for x86 clients.


You can delete existing partitions during client installation. Use the tag, <ai_device_partitioning>, and specify the delete action in the tag to delete a partition during installation.

...
<ai_device_partitioning>
      <partition_action>delete</partition_action>
      <partition_number>3</partition_number>
</ai_device_partitioning>
...
Creating an fdisk Partition (x86 only)

Note - Partition operations are meaningful only for x86 clients.


You can create a new partition during client installation. Use the tag, <ai_device_partitioning>, and specify the create action in the tag to create a partition during installation.

The following example creates a Solaris partition. This example uses Gigabytes (GB) as the unit for partition size. You could use megabytes (MB), terabytes (TB), or sectors to define a partition.

...
<ai_device_partitioning>
      <partition_action>create</partition_action>
      <partition_type>SOLARIS</partition_type>
      <partition_size>30</partition_size>
      <partition_size_units>GB</partition_size_units>
</ai_device_partitioning>
...
Deleting a VTOC Slice

You can delete an existing VTOC slice during client installation. Use the tag, <ai_device_vtoc_slices>, and specify the delete action in the tag to delete a slice during installation.


Note - The size element is required, but only for XML validation.


...
<ai_device_vtoc_slices>
       <slice_action>delete</slice_action>
       <slice_number>0</slice_number>
       <slice_size>20</slice_size>
</ai_device_vtoc_slices>
...
Creating a VTOC Slice

You can create a new VTOC slice during client installation. Use the tag, <ai_device_vtoc_slices>, and specify the create action in the tag to create a slice during installation. The following example shows how to create a new slice 5.

This example uses GB (Gigabytes) as the unit for slice size.

...
<ai_device_vtoc_slices>
       <slice_action>create</slice_action>
       <slice_number>5</slice_number>
       <slice_size>20</slice_size>
       <slice_size_units>GB</slice_size_units>
</ai_device_vtoc_slices>
...
Preserving VTOC Slices

You can preserve an existing VTOC slice during client installation. Use the tag, <ai_device_vtoc_slices>, and specify the “preserve” action in the tag to preserve an existing slice during installation. The following example shows how to preserve VTOC slice 7.

...
<ai_device_vtoc_slices>
       <slice_action>preserve</slice_action>
       <slice_number>7</slice_number>
</ai_device_vtoc_slices>
...
Specifying an Automatic Reboot After Installation

By default, the automated installer does not reboot the client after a successful installation of an OpenSolaris OS. However, if you want the client to automatically reboot after a successful installation of the OpenSolaris OS, add the XML tag, <ai_auto_reboot>, in the AI manifest, and set the reboot value in that tag to true, as per the following snippet:

...
<ai_auto_reboot>
     true
</ai_auto_reboot>
...
Specifying an IPS Repository

The automated installer client must install packages from an IPS repository. You can specify an IPS repository, a repository mirror, an a HTTP proxy for a repository, or an additional repository as follows.

The IPS repository is defined in the AI manifest by using the tag <ai_pkg_repo_default_publisher>. See the following example. This example specifies the repository located at http://pkg.opensolaris.org. The name of this repository is opensolaris.org.

...
<ai_manifest name="ai_manifest1">
      <ai_pkg_repo_default_publisher>
          <main url="http://pkg.opensolaris.org" publisher="opensolaris.org"/>
      </ai_pkg_repo_default_publisher>
</ai_manifest>
...
Specifying an IPS Repository Mirror

You can add a mirror to an IPS repository in the AI manifest as in this example:

...
<ai_manifest name="ai_manifest1">
      <ai_pkg_repo_default_publisher>
          <main url="http://pkg.opensolaris.org" publisher="opensolaris.org"/>
          <mirror url="http://mymirror.test">
      </ai_pkg_repo_default_publisher>
</ai_manifest>
...
Specifying an HTTP Proxy to Reach an IPS Repository

The client needs to reach the IPS repository defined in the AI manifest to install the OpenSolaris OS. In a normal configuration, the DHCP server sends DNS information to the client. This information is used to resolve the IPS repository name to an IP address. In cases where DNS is not set up, an HTTP proxy can be used to resolve the IPS repository name and complete the client installation. The XML tag, <ai_http_proxy>, and value in the manifest can contain the URL of the proxy as follows:

...
<ai_manifest name="http_proxy">
     <ai_pkg_repo_default_publisher>
         <main url="http://pkg.opensolaris.org" publisher="opensolaris.org"/>
     </ai_pkg_repo_default_publisher>
     <ai_http_proxy url="http://129.101.77.121:8080"/>
</ai_manifest>
...
Specifying an Additional Repository

You can install custom packages from an IPS repository other than the repository that was used for installation by specifying additional IPS repositories in the AI manifest. Use the tag, <ai_pkg_repo_addl_publisher>, to add additional repositories to the AI manifest.

...
<ai_manifest name="example1">
    <ai_pkg_repo_default_publisher>
        <main url="http://pkg.opensolaris.org" publisher="opensolaris.org"/>
    </ai_pkg_repo_default_publisher>
    <ai_pkg_repo_addl_publisher>
        <main url="http://pkg.mydomain" publisher="mydomain"/>
    </ai_pkg_repo_addl_publisher>
</ai_manifest>
...

Note - Sometimes a package might be included in more than one repository. IPS searches for that package in the repositories according to the order of the repository in the manifest. When a package match that includes version number is found, then IPS stops the search and installs that package.


Specifying Packages to be Installed

The following packages are needed for a successful installation of the OpenSolaris OS and are included in the AI default manifest:

  • entire

  • SUNWcsd

  • SUNWcs

  • babel_install

In the <ai_install_packages> tag, you can additional packages to be added during installation. However, you need to retain the default packages along with the additional packages.


Note - Due to dependency issues, entire must be listed first in the package list, followed by SUNWcsd, and then SUNWcs. Any additional packages must be listed after SUNWcs.


In the following example, the openoffice and the SUNWTcl packages are added as part of the OpenSolaris installation.

<ai_manifest name="ai_packages">
     <ai_install_packages>
         <pkg name="entire"/>
         <pkg name="SUNWcsd"/>
         <pkg name="SUNWcs"/>
         <pkg name="babel_install"/>
         <pkg name="openoffice"/>
         <pkg name="SUNWTcl"/>
     </ai_install_packages>
     <ai_uninstall_packages>
         <pkg name="babel_install"/>
         <pkg name="slim_install"/>
     </ai_uninstall_packages>
</ai_manifest>

Note - The default manifest first installs the babel_install package, then uninstalls it. babel_install is a cluster consisting of set of packages. When the babel_install cluster is installed, all the packages in the cluster are installed. However, you cannot uninstall packages that belong to a cluster. By uninstalling the cluster definition, the individual packages can be deleted later. babel_install is used for convenience to install all the required packages, but the cluster definition is not needed once installation of packages is completed. The default manifest removes the cluster definition, so that further customization of the packages can be done.

slim_install is another cluster. And, slim_install is part of babel_install which is installed by the default manifest. The default manifest then uninstalls slim_install, in order to permit customization.


Specifying Packages to Install a Specific Version of OpenSolaris

If the packages are specified as package names in the manifest without a version noted, the automated installer installs the latest version of the packages. If you want to install a specific version of the OpenSolaris OS, you can specify the version in the package entire, by using the following form:

<pkg_name="entire@0.5.11-0.build#/>

The IPS repositories include the full FMRI for each version of a package. Use the FMRI string to specify a specific version of the package, entire, in the AI manifest.

The following example specifies that OpenSolaris build 111 be installed to the client.

<ai_manifest name="ai_packages">
     <ai_install_packages>
         <pkg name="entire@0.5.11-0.111"/>
         <pkg name="SUNWcsd"/>
         <pkg name="SUNWcs"/>
         <pkg name="babel_install"/>
         <pkg name="openoffice"/>
         <pkg name="SUNWTcl"/>
     </ai_install_packages>
     <ai_uninstall_packages>
         <pkg name="babel_install"/>
         <pkg name="slim_install"/>
     </ai_uninstall_packages>
</ai_manifest>

Note - The build number or release of the AI ISO image that you specify in the installadm create-service command must be the same build number or release of the OpenSolaris operating system that you specify in the AI manifest.


Example: A Complete AI Manifest

The following example shows a complete AI manifest where all the primary tags are in use.

<ai_manifest name="ai_manifest1">
     <ai_target_device>
         <target_device_name>c0t0d0</target_device_name>
     </ai_target_device>                <!-- delete partition 3 -->
     <ai_device_partitioning>
         <partition_action>delete</partition_action>
         <partition_number>3</partition_number>
     </ai_device_partitioning>
     <ai_device_partitioning>               <!-- Create solaris partition -->
         <partition_action>create</partition_action>
         <partition_size>30</partition_size>
         <partition_size_units>GB</partition_size_units>
         <partition_type>SOLARIS</partition_type>
     </ai_device_partitioning>
     <ai_device_vtoc_slices>                <!-- Create VTOC slice 4 -->
         <slice_action>create</slice_action>
         <slice_number>0</slice_number>
         <slice_size>30</slice_size>
         <slice_size_units>GB</slice_size_units>
     </ai_device_vtoc_slices>
     <ai_pkg_repo_default_publisher>               <!-- IPS repository -->
         <main url="http://pkg.opensolaris.org" publisher="opensolaris.org"/>
     </ai_pkg_repo_default_publisher>
     <ai_http_proxy url="http://129.101.77.121:8080"/>       <!-- Use http proxy to install pkgs from IPS -->
     <ai_auto_reboot>true</ai_auto_reboot>            <!-- Automatic reboot after successful installation -->
     <ai_install_packages>
         <pkg name="entire"/>
         <pkg name="SUNWcsd"/>
         <pkg name="SUNWcs"/>
         <pkg name="babel_install"/>
         <pkg name="SUNWTcl"/>
     </ai_install_packages>  <!-- Due to dependency issues, entire must be listed first
            in the package list, followed by SUNWcsd, and then SUNWcs.
            Any additional packages must be listed after SUNWcs.  -->
     <ai_uninstall_packages>
         <pkg name="babel_install"/>
         <pkg name="slim_install"/>
     </ai_uninstall_packages>
</ai_manifest>
Previous Next