Go to main content

Creating a Custom Oracle® Solaris 11.3 Installation Image

Exit Print View

Updated: December 2017
 
 

Set Up Build Checkpoints

The execution element lists a series of checkpoints that are executed during the image construction process. Checkpoints are executed in the order in which they are listed in this section. Each manifest includes the default checkpoints needed to build the default installation image.

During the image construction process, the checkpoints modify the contents of the build area that is specified in the manifest.

Use the distro_const command options to control pausing and restarting the build process at particular checkpoints. See How to Build an Image in Stages.

The build area contains a pkg_image and a boot_archive directory. During the build process, everything that will be included in the final image is added to the pkg_image directory. The files in the separate boot_archive directory are used during the build process to create a boot archive file which is also added to the pkg_image directory.

    The following brief descriptions of each default checkpoint are presented in the order in which the checkpoints are executed in most manifests.

  • transfer-ips-install – At this checkpoint, the distribution constructor contacts the IPS publishers and adds to the image the packages that are listed in the software element with the transfer-ips-install attribute.

  • set-ips-attributes – At this checkpoint, the constructor sets the publisher to be used by the installed system. These values are set in the software element with the set-ips-attributes attribute. The values set by this checkpoint are not relevant if you are building an automated installation image. An AI client is configured to use the publisher of the AI server.

  • pre-pkg-img-mod – At this checkpoint, the constructor imports into the image the SMF service files that were specified in the configuration element of the manifest. Also, the constructor modifies some files to optimize the image. All package related operations and checkpoints must precede this checkpoint.

  • ba-init – At this checkpoint, the constructor populates the root archive with the files listed in the ba-init section of the manifest. These files are copied from the pkg_image area into the root_archive area.

    All changes made before this checkpoint are included in both the image being built and the root archive. You should add new checkpoints for custom scripts before this checkpoint if you want to ensure that changes from the custom scripts are incorporated in both the root archive and the image.

  • ba-config – At this checkpoint, the constructor performs further modifications to the files that were copied into the root archive. The constructor creates symbolic links to other files that are not needed until later in the boot process in order to minimize the size of the root archive.

  • ba-arch – At this checkpoint, the constructor packs the root archive and creates the root archive as a file within the pkg_image directory. The constructor also applies any optimizations to the root archive specific to the type of system being built. After this checkpoint, changes to the boot archive specifications by custom scripts are not integrated into the root archive because the root archive has already been packed.

  • boot-setup – At this checkpoint, the constructor sets up the GRUB2 menu based on the entries specified in the boot_entry section of the manifest. This checkpoint applies only to images for x86 systems.

  • pkg-img-mod – At this checkpoint, the constructor creates the main archives for the image being built and optimizes the pkg_image area. The constructor moves files in the pkg_image directory, creating the archive for the image. Everything included in the pkg_image directory is included in the image. Any additions after this checkpoint are not included in the image.

  • create-iso – This checkpoint builds the .iso files, including everything in the pkg_image directory.

  • create-usb – This checkpoint builds the .usb file from the generated .iso file.

Each checkpoint element includes the mod-path attribute that specifies where the checkpoint script is located. Also, some of the default checkpoints include arguments with default values provided.

The following checkpoint example from the dc_ai_sparc.xml sample manifest creates the boot archive for the image build and points to a script that will build the image. It also includes argument fields with specific values provided for each argument.

<checkpoint name="ba-arch"
    desc="Boot Archive Archival"
    mod_path="solaris_install/distro_const/checkpoints/boot_archive_archive"
    checkpoint_class="BootArchiveArchive">
    <kwargs>
        <arg name="size_pad">0</arg>
        <arg name="bytes_per_inode">0</arg>
        <arglist name="uncompressed_files">
             <argitem>etc/svc/repository.db</argitem>
             <argitem>etc/name_to_major</argitem>
             <argitem>etc/minor_perm</argitem>
             <argitem>etc/driver_aliases</argitem>
             <argitem>etc/driver_classes</argitem>
             <argitem>etc/path_to_inst</argitem>
             <argitem>etc/default/init</argitem>
             <argitem>etc/nsswitch.conf</argitem>
             <argitem>etc/passwd</argitem>
             <argitem>etc/shadow</argitem>
             <argitem>etc/inet/hosts</argitem>
        </arglist>
    </kwargs>
</checkpoint>

As shown in this example, the kwargs element contains keyword arguments that need to be passed into the checkpoint during the build. Within the kwargs element are arg name elements that can be used to specify individual keywords to be passed into the checkpoint. The arglist element contains a list of multiple argitem values to be passed into the checkpoint. This example includes a list of uncompressed files in the arglist element.

Each kwargs list item is enclosed in double quotes. If no double quotes are used or if one set of double quotes encloses the entire string, the entire string including spaces and new lines is interpreted as one argument. Do not use commas between arguments.

If you create a custom script to be used during the building of an image, you must add a checkpoint element pointing to the script location. The checkpoint for a custom script needs only an args element that points to the custom script location. For further information and examples, see Creating and Using Custom Scripts When Creating an Installation Image.

Example 2  Adding SVR4 Packages to An Installation Image

In this example, a new checkpoint is added to the manifest. This new checkpoint lists SVR4 packages to be added to the image and their location. This new checkpoint then is referenced in the execution section.

First, the new checkpoint is created by adding a new software element. This checkpoint specifies SVR4 as the software type, where to find the packages, and where to install the packages.

In addition, the specific SVR4 packages to be installed are listed in the software_data element.

<software name="transfer-svr4-install" type="SVR4">
   <destination>
       <dir path="{PKG_IMAGE_PATH}"/>
   </destination>
   <source>
    <publisher/>
      <origin name="path-to-packages"/>
    </publisher>
   </source>
   <software_data action="install">
      <name>SUNWpackage1</name>
      <name>SUNWpackage2</name>
   </software_data>
</software>

If included in the checkpoint, the values of {PKG_IMAGE_PATH} and {BOOT_ARCHIVE} are replaced by the distro_const command with the path to the build area for the package image and the boot archive, respectively. In this example, the SVR4 packages will be installed into the package image directory.

Finally, the new checkpoint is referenced in the execution section. The checkpoint name can be any string, but for this example, the checkpoint_class value must be TransferSVR4.

<execution stop_on_error="true">
   <checkpoint name="transfer-ips-install"
       desc="Transfer pkg contents from IPS"
       mod_path="solaris_install/transfer/ips"
       checkpoint_class="TransferIPS"/>
   <checkpoint name="set-ips-attributes"
       desc="Set post-install IPS attributes"
       mod_path="solaris_install/transfer/ips"
       checkpoint_class="TransferIPS"/>
   <checkpoint name="transfer-svr4-install"
      desc="Transfer pkg contents from SVR4 packages"
      mod_path="solaris_install/transfer/svr4"
      checkpoint_class="TransferSVR4"/>

Note that the software name must match the checkpoint name. In this example, both are “transfer-svr4–install.”

Example 3  Creating Hashes of the Media in an Installation Image

The checksums checkpoint enables users to automatically generate hashes of the media generated by the distro_const command.

    <checkpoint name="checksums" 
      desc="Checksum calculation for media" 
      mod_path="solaris_install/distro_const/checkpoints/checksums"
      checkpoint_class="Checksums"> 
      <kwargs> 
        <arglist name="algorithms"> 
          <argitem file_path="/tmp/md5sums.txt">md5</argitem> 
          <argitem>sha1</argitem> 
          <argitem>sha224</argitem> 
          <argitem>sha256</argitem> 
          <argitem>sha384</argitem> 
          <argitem>sha512</argitem> 
        </arglist> 
      </kwargs> 
    </checkpoint>
  

The arglist element includes all of the algorithms that are used to generate hashes for the generated media. Each argitem specifies an algorithm. The valid algorithms can be determined by running the /usr/bindigest -l command. Each argitem can have a path attribute that specifies the absolute path of an additional file that will be appended with the hashes produced by that algorithm. If no algorithms are specified, the default is md5.

While the image is built, files will be generated for each algorithm containing checksums for each media.