| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 4: File Formats Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 4: File Formats Oracle Solaris 11.1 Information Library |
- Distribution constructor manifest file format
/usr/share/install/dc.dtd.1
The distribution constructor (DC) can be used to build Oracle Solaris installation images.
DC XML manifest files are used as input to the distribution constructor. These manifests define the image that the distribution constructor builds. You can use different manifests to build different kinds of images. See the “Files” section for a list of template manifests that are available.
Use the distro_const command to build images, referencing a manifest file in the command. If you want to customize the image specifications, copy a manifest file, customize the copy, and use the copy as input for the distro_const command when you build the image.
At a minimum, you need to edit the target element in the manifest to specify the location of the build area where the image can be constructed. And, you need to edit the software name element to specify the publisher and repository location that contain the packages needed to build the image.
The manifests include the following primary elements.
Note - The default elements and attributes provided below vary depending on which manifest is used.
This element provides the default name, Oracle_Solaris_Text_X86, for the image that you plan to build. You can use this name, or provide a unique name for your image.
If you intend to perform a series of builds of an image and retain the incremental images, change the add_timestamp attribute value to true to automatically append a time stamp to the name for each image.
If you need to specify an HTTP proxy, use the version of the distro element that includes the http_proxy attribute, and enter the proxy location as shown in the following example:
<distro name="Oracle_Solaris_Text_SPARC" add_timestamp="false"
http_proxy="http://example.com">This element specifies boot menu modifications to be applied to the image.
In the following example, a specialized boot menu with the title myentry will be applied to the image. The timeout attribute specifies time before the default boot entry is automatically activated.
<boot_mods title="myentry" timeout="5">
You can add individual boot menu entries by adding a new boot_entry element for each new entry. Entries are added sequentially to the boot menu in the order based on the insert_at attribute value of start or end for each boot entry.
Note - Add new entries before any assistive_tech=magnifier entry.
See the following boot_mods element in the dc_livecd.xml sample manifest:
<boot_mods>
<boot_entry>
<title_suffix>with magnifier</title_suffix>
<kernel_args>-B assistive_tech=magnifier</kernel_args>
</boot_entry>
<title_suffix>with screen reader</title_suffix>
<kernel_args>-B assistive_tech=reader</kernel_args>
</boot_entry>
</boot_mods>Since a title sub-element is not included in this example, the default is used. The default title is the first line of /etc/release.
The title_suffix is a required sub-element, a text string to be appended to the entry title. An optional kernel_args sub-element passes kernel arguments to the boot loader.
Optional attributes for the boot_entry element include:
Set this attribute to “true” to make this boot entry the default. If more than one entry is set to “true”, the last entry defined as such will override preceding entries.
Set value to “start” or “end” to indicate insertion point relative to other boot entries.
This element defines the ZFS build dataset to be used for the build. This dataset is the area where the image will be created. The filesystem name should not include the zpool name.
<target>
<logical>
<zpool name="rpool" action="use_existing">
<filesystem name="dc/text" action="preserve"/>
</zpool>
</logical>
</target>This section specifies where the distribution constructor can get packages to download and use to build the image.
Image Packaging System (IPS) publishers provide packages in one or more package repositories.
In the source element in this section, edit the publisher name and origin name to specify which publisher to use and where the package repository is located. Multiple publishers can be listed. When the distribution constructor attempts to locate packages to install, publishers are searched in the order in which they are listed in the source element. Use the mirror sub-element to specify a mirror repository location. See the pkg(5) man page for information about IPS publishers and repositories.
<source>
<publisher name="solaris">
<origin name="http://pkg.oracle.com/solaris/release"/>
</publisher>
<publisher name="solaris">
<origin name="http://example.com/"></origin>
<mirror name="mirror1.example.com"></mirror>
<mirror name="mirror2.example.com"></mirror>
</publisher>
</source>
Note - This element also includes a destination tag which specifies the data mount point to be used during the build of the image. Changing the destination attribute is not recommended.
This software_data element with the install attribute lists the set of packages to be installed in order to build a particular type of image, depending on which manifest you are using. For example, the dc_text_x86.xml manifest lists the packages needed to build a text install image.
Each name element lists one package name.
<software_data action="install" type="IPS"> <name>pkg:/entire@latest</name> <name>pkg:/group/system/solaris-large-server</name> <name>pkg:/system/install/text-install</name> <name>pkg:/system/install/media/internal</name> </software_data>
If you have packages that you want to add to the image, append the package names by adding a name element for each package.
By default, the most current package version available in the specified repository is installed. If another version is required, include the version portion of the package FMRI as shown in the following example:
<name>pkg:/entire@0.5.11-0.165</name>
Use the following command to check which versions are available.
$ pkg list -af entire
Note - Do not remove the installation of the packaged named entire. The packaged named entire is an incorporation used to manage multiple packages.
The software_data element with the uninstall attribute can be used to uninstall an individual package.
<software_data action="uninstall" type="IPS"> <name>pkg:/editor/nano</name> </software_data>
This element affects a system after that system has been installed with the image created using the distribution constructor.
In the source element, use the publisher name and optional mirror name to specify where the installed system can access additional packages to download and install.
<source>
<publisher name="solaris">
<origin name="http://pkg.oracle.com/solaris/release/"/>
</publisher>
</source>The software element with name attribute ba-init lists the files and directories to be installed or uninstalled in the boot archive for the image that is built. See the comments in the manifest file for information.
 | Caution - Modifying the boot archive contents could render the system unbootable. |
The execution element in the manifest 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. The default checkpoints needed to build the default installation image are included in each manifest.
Each checkpoint element includes the mod-path attribute, which specifies where the checkpoint script is located.
Use the distro_const command options to control pausing and restarting the build process at particular checkpoints.
Some of the checkpoint sub-elements include arguments with default values provided. See the manifest comments for details.
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. See the following example about how to add a new checkpoint element to point to a custom script. A user creates a custom script, /tmp/myscript.sh, to run in the build process after the default transfer-ips-checkpoint. To point to the new script, add the following element to the manifest after the transfer-ips-install checkpoint.
<checkpoint name="custom1"
desc="my new script"
mod_path="solaris_install/distro_const/checkpoints/custom_script"
checkpoint_class="CustomScript">
<args>/tmp/myscript.sh {PKG_IMAGE_PATH}filearg arg2</args>
</checkpoint>Where filearg and arg2 are arguments the script takes, and filearg is the name of a file in $PKG_IMAGE_PATH. See the “Environment Variables” section below for a description of PKG_IMAGE_PATH.
Note - Multiple custom checkpoints can be specified in a DC manifest. Each checkpoint must have a unique name.
The configuration element in the manifest lists SMF service profiles that are applied to the media during the image construction process. These SMF services specify which services will be running, or not running, on the booted media. The profiles are applied in the order in which they are specified in this element.
This element would rarely be modified.
The following environment variables are used only with custom checkpoint scripts. See the example in “Execution and Checkpoint Section” above.
Replaced by distro_const during execution with ZFS_dataset/build_data/pkg_image.
Replaced by distro_const during execution with ZFS_dataset/build_data/boot_archive.
The following manifest files can be used to build various Oracle Solaris images. These manifests are included in the distribution-constructor package.
To build x86 Oracle Solaris Live DVD images.
To build x86 automated installation images.
To build SPARC automated installation images.
To build x86 text installation images.
To build SPARC text installation images.
See attributes(5) for descriptions of the following attributes:
|
Creating a Custom Oracle Solaris 11 Installation Image
|