The distribution constructor is a tool that application developers can use to build their own custom OpenSolaris image which they can then distribute to their contacts and customers.If you have not used the distribution constructor before, read this introduction. Then, install the tool on your system, using the instructions at Setup for the Distribution Constructor.. If you are already familiar with the distribution constructor tool, go to Using the Distribution Constructor for detailed instructions about how to design and create images. The distribution constructor is a command-line tool for building preconfigured, bootable OpenSolaris images. This tool takes an XML manifest file as input, and builds an ISO image that is based on the parameters specified in the manifest file. Optionally, a USB image can be created, based on the generated ISO image.An ISO image or a USB image is a collection of software in a single file. These images are bootable and can be used for installation and other purposes. Both ISO images and USB images can be distributed on the Internet. The ISO image needs to be burned into a CD/DVD before use. The USB image needs to be copied into a USB flash drive by using a special Solaris utility.The Distribution Constructor outputs a USB image that could work in other types of flash memory devices, if that device has driver support provided by the OpenSolaris release. The usbcopy utility is the only utility that can be used to copy the USB image into a USB flash drive. This usbcopyutility is available with the OpenSolaris release. You can use the distribution constructor to create the following types of OpenSolaris images:OpenSolaris 2009.06 x86 Slim CD – Using the distribution constructor, you can create an x86 ISO image that is comparable to the Live CD image that's distributed as the OpenSolaris 2009.06 release. And, you can modify the content of this ISO image, selecting and adding additional packages to the image. You can revise the default settings for the resulting booted environment to create a custom, redistributable ISO image or USB image. x86 ISO Image for Automated Installations SPARC ISO Image for Automated InstallationsThe OpenSolaris 2009.06 release includes the automated installer tool. The automated installer (AI) is used to automate the installation of the OpenSolaris OS on one or more SPARC and x86 systems over a network. The installations can differ in architecture, packages installed, disk capacity, and other parameters. The automated installer uses a SPARC or x86 AI ISO image to install the OpenSolaris OS to client systems. You can use the distribution constructor to create a SPARC AI ISO image that can be used to install the OpenSolaris OS on SPARC clients, or to create an x86 AI ISO image that can be used to install the OpenSolaris OS on x86 clients.For information about using the automated installer, see the OpenSolaris Automated Installer Guide. When using the distribution constructor, you can only create SPARC images on a SPARC system. And, you can only create x86 images on an x86 system.To see the system requirements for using the distribution constructor, see . The distribution constructor tool uses the following components:The distribution constructor creates images based on settings specified in a file. This file is the blueprint from which every image is built. This blueprint is an XML file called a manifest file. Sample manifest files with preset values are included in the distribution constructor package. You can manually edit a manifest file to customize the ISO images you create. The distribution constructor enables you to specify scripts or programs that can be used to make installation customizations based on the type of image you are building. These scripts are called finalizer scripts. The distribution constructor package includes the set of scripts that are used for creating the Slim Live CD and AI ISO images. It is recommended that you use the supplied finalizer scripts without editing them. You do, however, have the option to write and add your own scripts to perform additional operations. with The distribution constructor package also includes a command-line utility, the distro_const command, that actually builds your image for you. After you've finished editing the image blueprint in a manifest file to suit your requirements, you run the distro_const command to build your image. You can use the options provided in the distro_const command to stop and restart the build process at various stages, in order to check and debug the image that is being built. This process of stopping and restarting during the build process is called checkpointing. The following section describes each of the components of the distribution constructor application more fully.XML manifest files contain specifications for the contents and parameters of the ISO images that you create using the distribution constructor. The distribution constructor contains default manifests that can be used to create a custom Slim CD, an x86 AI ISO image, or a SPARC AI ISO image.Manifests specify parameters such as the following:Names of the packages to be included in the image Network location of the repository to access to retrieve packages for the image Name and location of scripts used to finalize the creation of the new image All the fields in each manifest file provide preset, default values that will create the type of ISO image you need. Optionally, you can manually edit these preset fields in a manifest file to further customize the resulting image.For instructions about editing manifest files, see Setting Up the Manifest. A manifest file points to scripts that are used to customize the new image. These finalizer scripts transform the generic image into a media-specific distribution. The default scripts that are provided in the application packages generate ISO images for either an x86 Slim CD, an x86 AI ISO image, or a SPARC AI ISO image. Start with the default scripts, and with caution, add your own scripts to supplement. Edit the manifest file to point to any new scripts.While custom scripts are needed to create your own custom image, support for scripts is limited to the unmodified scripts that are supplied with the application packages. If you choose to customize these scripts, backup the original scripts first. For further information about these scripts and how to customize them, see Customizing the Finalizer Scripts. After setting up the manifest and, optionally, customizing the finalizer scripts, you build an image by using the distro_const utility from the command line.For further information, see Creating an Image. See also the distro_const1M man page. The distribution constructor provides the ability to pause, or “checkpoint,” and resume at certain stages of the image-generation process. This checkpointing feature supports the process of developing and debugging images. You can start building an image, pause at any stage where you want to stop and examine the contents of the image, then resume building the image. Checkpointing is optional.A checkpoint in the build process is created after each finalizer script is executed. So, new checkpoint references are added when you add new finalizer scripts. You use this feature by taking advantage of the checkpointing options that are available in the distro_const command. Run the command to check which checkpoints are available, then build your image with any checkpoint options that you choose.For instructions, see Using Checkpointing. See also the distro_const1M man page. When you use the distribution constructor to create ISO images, there are a few differences between creating images for SPARC systems and for x86 systems:To prepare to use the distribution constructor, you can download an x86 Live CD image and use it to install the OpenSolaris OS on your x86 system. However, there are no SPARC Live CD images. Instead, you must use the automated installer to install the OpenSolaris OS on a SPARC system. Then you can use the distribution constructor on that SPARC system.For information about using the automated installer, see the OpenSolaris Automated Installer Guide. The root archive for x86 images differs from the root archive for SPARC images. The whole root archive, or bootroot, for x86 images is a UFS filesystem, compressed by using lzma. The SPARC platform does not support the compression of the whole root archive in this way. Instead, SPARC root archives use DCFS, which compress each file individually. These individually compressed files might require specific handling in the manifest. For instructions, see <bootroot_contents> in . In order to use the distribution constructor, you must have the following set up on your system. Requirement Description Disk Space Confirm that you have sufficient space on your system to use the distribution constructor. The recommended minimum size for your distribution constructor work space is 8 Gbytes. OpenSolaris 2009.06 release Install the SPARC or x86 OpenSolaris 2009.06 operating system (OS) on your system.When using the distribution constructor, you can only create SPARC images on a SPARC system. And, you can only create x86 images on an x86 system.X86 Slim CD images for the OpenSolaris 2009.06 operating system, also called Live CD images, can be downloaded from . For instructions about installing the OpenSolaris release from the Live CD onto your x86 system, see Getting Started With OpenSolaris. SPARC Slim CD images are not supported. However, you can use the automated installer to install the SPARC OpenSolaris OS on your system. For information about using the automated installer, see the OpenSolaris Automated Installer Guide. Your installed OpenSolaris system must have network access.Specifically, the distribution constructor accesses Image Packaging System (IPS) repositories that are available on the network to retrieve packages for the ISO image. You must have network access to the repositories that you specify in the manifest file.Also, note that you must run the distribution constructor as root. Required packages Install the SUNWdistro-const package, which contains the distribution constructor application, on your system.You can use the Package Manager tool to install the required package. The Package Manager is available on the menu bar on the desktop of the OpenSolaris 2009.06 operating system. On the menu bar, go to System>Administration>Package Manager.Alternately, use IPS commands such as the following to install this package:# pkg install SUNWdistro-const When you've installed the SUNWdistro-const package on your system, you have the following tools, scripts, and utilities available to design and build custom, preconfigured OpenSolaris images.File Location Description /usr/bin/distro-const Distribution constructor application /usr/bin/usbcopy/usr/bin/usbgen Tools for generating and copying USB images /usr/bin/proc_tracedata/usr/bin/proc_slist Tools for generating the ISO sort file /usr/share/distro_const Configuration, data, and utilities files used by the distribution constructor application /usr/share/distro_const/slim_cd Configuration, data, and utilities files used to create an x86 Slim CD ISO image, including a default all_lang_slim_cd_x86.xml manifest file. /usr/share/distro_const/auto_install Configuration, data, and utilities files used to create AI ISO images for x86 or SPARC automated installations, including the manifest files: ai_sparc_image.xml and ai_x86_image.xml. /usr/share/man/man1m/distro_const/usr/share/doc/distro_const/index.html Documentation for the distribution constructor, including the following:distro_const1M man page OpenSolaris Distribution Constructor GuideThis document is also available at . The distribution constructor and finalizer scripts require files provided by the SUNWinstall package, including the /usr/bin/ManifestRead file and files in /usr/lib/python2.4/vendor-packages/osol_install.SUNWinstall also includes /usr/bin/ManifestServ, which can be used as a debugging tool for XML manifests. Once you have successfully set up the distribution constructor on your system, you are ready to build your own custom images. See Using the Distribution Constructor for detailed instructions about designing and building custom images. Prerequisites: If you have not used the distribution constructor before, read Introduction to the Distribution Constructor. Then, install the application on your system, using the instructions at Setup for the Distribution Constructor..Once you have installed the distribution constructor application on your system, you are ready to use this tool to design and build custom images. This process includes the following three basic steps:Optional: Editing the Manifest File Optional: Using the Finalizer Scripts Creating an Image The SUNWdistro-const package that you installed on your system includes default manifest files. These XML manifest files provide the distribution constructor with the blueprints that specify the contents and parameters of the image that you plan to build. The default manifest files included in the SUNWdistro-const package are:Manifest for x86 ISO image – Located at /usr/share/distro_const/slim_cd/all_lang_slim_cd_x86.xml, this manifest is used to create an ISO image comparable to the OpenSolaris 2009.06 Live CD. To view the contents of the x86 Slim CD manifest, see Sample Manifest File. Manifest for SPARC AI ISO image – Located at /usr/share/distro_const/auto_install/ai_sparc_image.xml, this manifest is used to create a SPARC AI ISO image for automated installations of the OpenSolaris OS to SPARC clients. Manifest for x86 AI ISO image – Located at /usr/share/distro_const/auto_install/ai_x86_image.xml, this manifest is used to create an x86 AI ISO image for automated installations of the OpenSolaris OS to x86 clients. You do not need to modify the default manifest files. However, you can edit them if you wish. The following table summaries some of the key sections in the manifest file and provides further instructions about how you can customize these sections.When using the distribution constructor, you can only create SPARC images on a SPARC system. And, you can only create x86 images on an x86 system. Section XML Tags Description of Required Manual Edits <distribution name="OpenSolaris"> This section provides a default name for the distribution.You can leave the default name or type a unique name for your distribution. <checkpoint_enable> The default setting in this section enables checkpointing when you create the image. You can use checkpointing to pause while building an image for testing purposes. Checkpointing is described later in this topic. <pkg_repo_default_authority> This section specifies the location of the IPS repository. The constructor accesses the repository and retrieves packages for the image when the image is being built. The default repository location is .If you do not want to use the opensolaris.org repository, modify this location to point to the repository of your choice. To view a list of some of the alternate repositories, see OpenSolaris Repositories. <packages> This section lists the packages to be included in the image.If you have packages that you want to add to the image, list your packages in this field, one package per line. <bootroot_contents> This section lists the default files and directories that will be included in the boot root for the image that is built. Files or directories that need to be excluded from the image are specified with the base_exclude tag.It is recommended that you not edit the boot root contents with the following exception. Modifying the boot root contents might cause the system to fail to boot. The root archive for x86 images differs from the root archive for SPARC images. The whole root archive, or bootroot, for x86 images is a UFS filesystem, compressed by using lzma. The SPARC platform does not support the compression of the whole root archive in this way. Instead, SPARC root archives use DCFS, which compress each file individually. These individually compressed files might require specific handling in the manifest.During boot time, some of the files in the root archive need to be modified. But, compressed files cannot be modified. Therefore, for SPARC images, you need to specify in the manifest which files should not be compressed. In the finalizer section of the manifest, find the reference to the boot_archive.py script. By default, this script specifies that all the files and directories in the /boot/solaris/filelist.ramdisk file, and all the files and subdirectories under the usr/kernel directory, are uncompressed. You must specify any additional files that need to be in uncompressed state in the bootroot by setting the fiocompress=false option in the manifest for those files. <build_area> This section specifies the area where the image will be created.You must check that the package image area specified is valid for your system and revise as needed.If you want to use checkpointing, you must specify a ZFS dataset, or a mount point that correlates to a ZFS dataset, as your build area. If the ZFS dataset does not exist, it will be created. The zpool that you specify, however, must already exist.If you do not want to use checkpointing, you can use either a regular mount point or a ZFS or UFS file system.After an image has been created, the build area for that image has the following structure.<build_area>/build_data/pkg_image – Package image area. <build_area>/build_data/bootroot – Boot root build area. <build_area>/build_data/tmp – Temporary directory used by constructor and finalizer scripts. <build_area>/media – Area where the output images are placed. <build_area>/logs – Area that holds log files which record the steps executed by the application and the output from all commands.The “simple” log, named simple-log-YYYY-MM-DD-HH-Mi-SS, contains only errors. The “detail” log, named detail-log-YYYY-MM-DD-HH-Mi-SS, contains informational output and errors. The console echos information in the “simple” log file. <finalizer> This section specifies the finalizer scripts that the distribution constructor invokes and the order in which the distribution constructor invokes them.Default finalizer scripts are provided in the distro_const package and automatically referenced in this section of the manifest file. You do not need to edit this section unless you add new finalizer scripts, or you change the name or the argslist of existing scripts. <key_value_pairs> This section specifies additional parameters that are needed by the distribution constructor or by the finalizer scripts. Default parameters are provided.You do not need to edit the default key-value pairs except to add new ones that will be recognized by new or customized finalizer scripts. You can either use one of the default manifest files, or you can copy a default manifest and create a custom manifest file with a new file name. You will reference the manifest file by name when you use the distro_const command to create an image.If the default scripts do not leave the build_area as you need it, you can create your own scripts to make further modifications. If you do create new scripts, you'll need to update the script references in the finalizer section of the manifest file.Always backup the original manifest file and the default scripts before copying them. Your custom scripts are not supported. When you have completed any revisions to the manifest file and, optionally, customized the finalizer scripts as described in the next section, you can proceed with running the distro_const utility to create an image. The distribution constructor application includes default scripts in the /usr/share/distro_const directory and subdirectories. These scripts are referenced in the finalizer section of the manifest files.It is recommended that you use the default scripts without editing them. You do have the option to write your own scripts to perform additional operations. For example, some of the finalizer scripts that are used to create an x86 Slim CD are as follows:pre_bootroot_pkg_image_mod – Image area modifications for all types of images slim_cd/slimcd_pre_bootroot_pkg_image_mod – Image area modifications specific to Slim CD slim_cd/slimcd_gen_cd_content – Generate the list of files that are part of the Slim Live CD image. bootroot_initialize.py – Boot-root initialization slim_cd/slimcd_bootroot_configure – Boot-root configuration specific to Slim CD bootroot_configure – Boot-root configuration bootroot_archive.py – Boot-root archiving slim_cd/slimcd_post_bootroot_pkg_image_mod – Post-boot-root image area modification specific to Slim CD grub_setup – Initialization of grub menu post_bootroot_pkg_image_mod – Post-boot-root image area modification create_iso – ISO image creation create_usb – USB image creation These finalizer scripts are referenced in the finalizer section of the Slim CD manifest. You can view the complete contents of the default Slim CD manifest, including the finalizer section where the scripts are referenced, at Sample Manifest File.Some of the scripts listed above are also used to create SPARC or x86 ISO images for automated installations. But, the automated installer manifests reference other finalizer scripts that are specific to the SPARC or x86 automated installation processes. You can use the default scripts without editing them. However, you can also create custom scripts to perform additional tasks as follows: Create new scripts by using the existing scripts as models for your new scripts. Review the characteristics of finalizer scripts as described below. Also, see the custom script examples that are provided below. Add your new scripts to the /usr/share/distro_const directory or anywhere on the system or network. Make sure that root can execute these scripts. Add the new script names in the finalizer section of the appropriate manifest file. Be sure to specify the full path to your scripts in the manifest file, even if they are in the /usr/share/distro_const directory. When you add a reference for a new script in the finalizer section of a manifest file, you must specify a checkpoint name that is used to pause the image build before or after this script performs its task. Optionally, you can include a custom message associated with the checkpoint name. If this message is omitted, the path of the script is used as the default checkpoint message.Use meaningful names for checkpoint names instead of using numbers. If new scripts are added, the new steps for those new scripts will disrupt a prior numbered checkpoint order. For example, the following reference in a manifest file specifies the checkpoint name of “br-arch” for a boot root archiving script, and the associated message is “Boot root archiving.”<script name="/usr/share/distro_const/bootroot_archive.py"> <checkpoint name="br-arch" message="Boot root archiving"/>In this example, when you build your image, you could refer to the “br-arch” checkpoint in the distro_const command. This checkpoint would enable you to pause building the image just before the boot root archiving script performs its task.For instructions about how to refer to checkpoints in the distro_const command, see Using Checkpointing to Create an Image.To see further examples of finalizer script references, see the finalizer section of the Sample Manifest File. When you create your own scripts, note the following characteristics of the finalizer scripts:Scripts can be Python programs, shell scripts, or binaries. Scripts are executed in the order that they are listed in the manifest file. The stdout and stderr information for the scripts is captured in the log files. The argslist, which can accept a list of items, uses double-quotes to delimit the list arguments. When no double-quotes are used, or if one set of double-quotes envelopes the entire string, the entire string including spaces and newlines is interpreted as one argument. Do not use commas between arguments. The distribution constructor passes five initial arguments to all scripts which are executed. These five arguments are not included as entries in the manifest file. The manifest file specifies additional arguments passed in after these five arguments. The initial arguments are as follows: Argument Description Server socket file name The first argument is the manifest reader socket. This argument specifies the socket that is used with /usr/bin/ManifestRead for accessing the manifest data. See the section below about Using the ManifestReader. Package image area path The second argument is the PKG_IMG_PATH, which specifies the path to the area where the package image is created. Use this argument to locate a file in the package image area. The following example checks whether the user “jack” is in the password file.PKG_IMG_PATH=$2 /usr/bin/grep jack $PKG_IMG_PATH/etc/passwd >/dev/null if [[ $? == "0" ]] ; then print "Found Jack" fi Temp directory The third argument specifies a directory that is used when creating temporary files needed during the build process. In the following example, we want to create a file in the temporary directory for building the boot root.TMP_DIR=$3 /usr/sbin/mkfile $TMP_DIR/bootroot_archive /usr/sbin/lofiadm -a $TMP_DIR/bootroot_archive Bootroot build area The fourth argument is the boot root build area, where the boot root files are gathered. See the following example from the bootroot_archive.py module. The module references the boot root build area in order to size the boot root before creating the archive.BR_BUILD = sys.argv[4] # Bootroot build area print "Sizing bootroot requirements..." cmd = /usr/bin/du + " -sk " + BR_BUILD + " | " + /usr/bin/awk + " '{print $1}'" bootroot_size = int(Popen(cmd, shell=True, stdout=PIPE).communicate()[0].strip()) Media area The fifth argument specifies where the finished media is deposited. In the following example, the create_iso script uses this argument to place the resultant ISO image.MEDIA_DIR=$5 ... DIST_ISO=${MEDIA_DIR}/${DISTRO_NAME}.iso ... Additional arguments A list of additional arguments to be passed into a script is tagged in the manifest with the <argslist> tag. The first of these arguments is passed in as arg6.In the following example from the slim_cd.xml manifest file, two additional arguments are passed to the bootroot_configure script, as arg6 and arg7:<argslist> "/usr/share/distro_const/slim_cd/slimcd_generic_live.xml" ".livecd" </argslist>Another method for specifying additional arguments is to use key-value pairs. See the following section. The distribution constructor passes the manifest reader socket argument into finalizer scripts. This argument specifies the socket that is used with /usr/bin/ManifestRead for accessing the manifest data.The following example calls ManifestRead to request the name item from the manifest file. ManifestRead returns zero or more items, each on its own line. If ManifestRead is given multiple items to search for, the lines returned contain both the item being searched for and a result.MFEST_SOCKET=$1 VOLNAME=`/usr/bin/ManifestRead ${MFEST_SOCKET} "name"` if [ "XX${VOLNAME}" == "XX" ] ; then print -u2 "$0: Error retrieving volume ID" exit 1 fiThe following example shows how to make use of ManifestRead from a python script:from osol_install.ManifestRead import ManifestRead # get the manifest reader object from the socket manifest_reader_obj = ManifestRead(MFEST_SOCKET) # get bootroot compression type BR_COMPR_TYPE = get_manifest_value(manifest_reader_obj, "img_params/output_image/bootroot/compression/type") if (BR_COMPR_TYPE == None): raise Exception, (sys.argv[0] + ": bootroot compression type missing from manifest")Another method for passing arguments into scripts is to specify a key-value pair. This method is useful for passing the same argument into multiple scripts without duplication. A script can access a keyed value by specifying the key to /usr/bin/ManifestRead from within the script. Provide the server socket as the first argument and then provide the nodepaths to the items whose values are needed, as in the following examples.... MFEST_SOCKET=$1 ... /usr/bin/ManifestRead -k $MFEST_SOCKET iso_sort iso_sort_file=`/usr/bin/ManifestRead $MFEST_SOCKET iso_sort`The above example calls ManifestRead from a shell script to get a keyed value as in this sample script. from osol_install.ManifestRead import ManifestRead ... IS_KEY = True iso_sort_file = manifest_reader_obj.get_values("iso_sort", IS_KEY) fd = open(iso_sort_file,....)The above example calls ManifestRead from python to get the same keyed value. The following examples illustrate some practical applications for custom finalizer scripts.When putting together an image, you can experiment with how an image works when packages are added or removed from a working set. This type of experimentation is supported by the distribution constructor. Additional packages can be added to the existing list in the package section of a manifest file. And, packages that you want to remove can be added to the post_install_remove_package section. After you made your modifications to the manifest file to add or remove packages, you need to restart the build process from the beginning, and re-download all the packages. That can take time. You can do these modifications more rapidly by using finalizer scripts.The following custom script adds an IPS package to the image from an alternate repository specified in the manifest file. The package is added to the package image area. The name of the package to add is included in the script. This example also demonstrates how to use the ManifestRead program to get values from the manifest file.#!/bin/ksh # # # Args: # # 5 arguments are passed in by default from the DC. # # MFEST_SOCKET: Socket needed to get manifest data via ManifestRead object # PKG_IMG_PATH: Package image area # TMP_DIR: Temporary directory # BR_BUILD: Area where bootroot is put together (not used in this example) # MEDIA_DIR: Area where the media is put (not used) # # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ if [ "$#" != "5" ] ; then print -u2 "Usage: $0: Requires 5 args:" print -u2 " Reader socket, pkg_image area, tmp dir," print -u2 " bootroot build area, media area" exit 1 fi MFEST_SOCKET=$1 PKG_IMG_PATH=$2 if [ ! -d $PKG_IMG_PATH ] ; then print -u2 "$0: Image package area $PKG_IMG_PATH is not valid" exit 1 fi PKGCMD="/bin/pkg" #Hard code package to install TEST_PKGS="SUNWcdrw" # # You would have specified the additional repository like this in the manifest # # # <pkg_repo_addl_authority> # <main url="http://localhost:10000" authname="localtest"/> # </pkg_repo_addl_authority> # Get the alternate repository URL from the manifest add_url=/usr/bin/ManifestRead ${MFEST_SOCKET} \ "distro_constr_params/pkg_repo_addl_authority/main/url" # Get the alternate repository authority from the manifest add_auth=/usr/bin/ManifestRead ${MFEST_SOCKET} \ "distro_constr_params/pkg_repo_addl_authority/main/authname" added_authority=0 # # Check to see if authority is already set in the package image area # if not, add it in # ${PKGCMD} -R $PKG_IMG_PATH authority $add_auth > /dev/null 2>& 1 if [ $? != 0 ] ; then ${PKGCMD} -R $PKG_IMG_PATH set-authority -O ${add_url} ${add_auth} added_authority=1 fi if [$? != "0" ] ; then print -u2 "$0: Unable to set additional authority" exit 1 fi for t in ${TEST_PKGS} ; do pkg_name="pkg://${add_auth}/${t}" ${PKGCMD} -R $PKG_IMG_PATH install ${pkg_name} if [$? != "0" ] ; then print -u2 "$0: Unable to install ${pkg_name}" exit 1 fi done # if we have added the additional authority, unset it so it doesn't pollute what's # originally there if [ $added_authority == 1 ] ; then ${PKGCMD} -R $PKG_IMG_PATH unset-authority ${add_auth} fi return 0Because this type of finalizer script adds or removes packages from the package image area, you must reference the script as the first finalizer script in the <finalizer> section of the manifest file. Include in this reference a checkpoint name that indicates the point in the image-building process where you want to restart the build to test your added package.For example, if you have created a script, export/home/user1/test_my_pkg, to test your custom package, you would reference the script as follows in the finalizer section of the manifest file. Note that a checkpoint, named “my_test,” indicates where the build will restart.<finalizer> <script name="/export/home/user1/test_my_pkg"> <checkpoint name="my_test" message="Running my test package" </script> <script name="/usr/share/distro_const/pre_bootroot_pkg_image_mod"> <checkpoint name="im-mod" message="Image area modifications"/> </script> ........ </finalizer>After you made the changes to the manifest file to reference your new script, you can start building your image from the beginning once. After that, if you make any changes to your package, you do not need to restart from the beginning . You can generate an image with your modified package by starting at the checkpoint that runs your script.The following are the sequence of commands a user would execute to repeatedly test their modifications to packages.Run the build from the beginning after modifying the manifest. Do this only once.distro_const build /my_updated_manifest.xml Check steps that are resumable.distro_const build l /my_updated_manifest.xml Restart from the step of your package modification. You can restart from this step as many times as you need while you debugging your modified contents.distro_const build r my_test /my_updated_manifest.xml For further information about using the distro_const command with checkpointing options, as demonstrated in this example, see . When a particular package is specified in the package section of a manifest file, that package is installed in the package image area by the distribution constructor. If you have an alternate version of this package, such as your own private copy of a package, you could test this version of the package by using a custom finalizer script. The finalizer script would replace the previously installed version of the package with a test version from an alternate repository.In the following custom script, an IPS repository server is running on http://localhost:10000. The name of the package to replace is passed as an argument. The script first uninstalls the existing version of the package, then installs the test version from the alternate repository. This custom script also demonstrates how to get arguments passed in as finalizer script arguments. Note the comments in the script that explain how the script accomplishes these tasks.#!/bin/ksh # # # Args: # # These Arguments are passed in by default from the DC. # # MFEST_SOCKET: Socket needed to get manifest data via ManifestRead object \ # (not used in this example) # PKG_IMG_PATH: Package image area # TMP_DIR: Temporary directory # BR_BUILD: Area where bootroot is put together (not used in this example) # MEDIA_DIR: Area where the media is put (not used) # PKG_NAMES: Package to replace with one from the test repo. # # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ if [ "$#" != "6" ] ; then print -u2 "Usage: $0: Requires 6 args:" print -u2 " Reader socket, pkg_image area, tmp dir," print -u2 " bootroot build area, media area, pkg_name" exit 1 fi PKG_IMG_PATH=$2 if [ ! -d $PKG_IMG_PATH ] ; then print -u2 "$0: Image package area $PKG_IMG_PATH is not valid" exit 1 fi PKGCMD="/bin/pkg" #The test packages are passed in as arguments to this finalizer script #You would have specified the argument like this in the finalizer section #to pass in the argument # # # <finalizer> # <script name="/my/update_my_pkg_test"> # <checkpoint name="update-pkg" message= \ "Replaces an existing package with my own"/> # <argslist> # "SUNWcdrw" # </argslist> # </script> # </finalizer> # TEST_PKG=$6 #hard code alternate repository and authority. Assume that my test package resides in #a repository running on port 10000 of the localhost. # Get the alternate repository URL from the manifest add_url="http://localhost:10000" # Get the alternate repository authority from the manifest add_auth="MY_TEST" added_authority=0 # Check to see if authority is already set in the package image area, if not, # add it in ${PKGCMD} -R $PKG_IMG_PATH authority $add_auth > /dev/null 2>& 1 if [ $? != 0 ] ; then ${PKGCMD} -R $PKG_IMG_PATH set-authority -O ${add_url} ${add_auth} added_authority=1 fi if [$? != "0" ] ; then print -u2 "$0: Unable to set additional authority" exit 1 fi # Remove the package that's currently in the package image area. ${PKGCMD} -R $PKG_IMG_PATH uninstall ${TEST_PKG} if [$? != "0" ] ; then print -u2 "$0: Unable to uninstall ${TEST_PKG}" exit 1 fi # Install the package from test repo pkg_name="pkg://${add_auth}/${TEST_PKG}" ${PKGCMD} -R $PKG_IMG_PATH install ${pkg_name} if [$? != "0" ] ; then print -u2 "$0: Unable to install ${pkg_name}" exit 1 fi # if we have added the additional authority, unset it so it doesn't pollute what's # originally there if [ $added_authority == 1 ] ; then ${PKGCMD} -R $PKG_IMG_PATH unset-authority ${add_auth} fi return 0 If you have a package that is in SVR4 format, you can test that package in an image before you convert it into an IPS package. You can use a finalizer script to add the content of a SVR4 package to the image. See the following custom script and note the comments in the script that explain how the script accomplishes this task.#!/bin/ksh # # # Args: # # 5 arguments are passed in by default from the DC. # # MFEST_SOCKET: Socket needed to get manifest data via ManifestRead object (not used) # PKG_IMG_PATH: Package image area # TMP_DIR: Temporary directory # BR_BUILD: Area where bootroot is put together (not used in this example) # MEDIA_DIR: Area where the media is put (not used) # # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ if [ "$#" != "5" ] ; then print -u2 "Usage: $0: Requires 5 args:" print -u2 " Reader socket, pkg_image area, tmp dir," print -u2 " bootroot build area, media area, pkg_name" exit 1 fi PKG_IMG_PATH=$2 if [ ! -d $PKG_IMG_PATH ] ; then print -u2 "$0: Image package area $PKG_IMG_PATH is not valid" exit 1 fi TMP_DIR=$3 # # Install a SVR4 packages into the package image area # #create an admin file for non-interactive pkgadd's ADMIN_FILE=${TMP_DIR}/admin.$$ cat << \ADMIN_EOF > $ADMIN_FILE mail= instance=unique partial=nocheck runlevel=nocheck idepend=nocheck rdepend=nocheck space=nocheck setuid=nocheck conflict=nocheck action=nocheck networktimeout=60 networkretries=3 authentication=quit keystore=/var/sadm/security proxy= basedir=default ADMIN_EOF # # Path to your new packages # PKG_PATH=/path/to/my/test/svr4_pkg # # Test package name # SVR4_TEST_PKG=SUNWmy-test /usr/sbin/pkgadd -n -a ${ADMIN_FILE} -d $PKG_PATH -R ${PKG_IMG_PATH} ${SVR4_TEST_PKG} if [ $? != "0" ] ; then echo "installing package failed" exit 1 fi /bin/rm ${ADMIN_FILE} return 0 After you have set up the manifest file that you plan to use and customized the finalizer scripts if desired, you are ready to build an image by running the distro_const command.The full syntax for this command is as follows:Syntax: distro_const build [R] [r step] [p step] [l] manifestYou need to run the distro_const command as root. You can use the distro_const command to do either of the following:Build an image in one step. Build an image, but pause and restart the build as needed in order to examine the content of the image and debug the finalizer scripts during the build process. To run a complete build of an image without pausing, use the basic distro_const command without options as follows:# distro_const build manifestReplace manifest with the name of the manifest file to be used as the blueprint for your image. The build subcommand is required. When you enter this command, the distribution constructor pulls the needed packages for the image and builds the image to the specifications that you entered in the manifest file. You do not need to build an image without pausing. In fact, you may prefer to pause and restart the build process to debug your selection of files, packages, and scripts for creating an image. You can use the checkpointing options in the distro_const command to pause and restart the build process as needed.The checkpointing feature is enabled by default in a manifest file. However, checkpointing can only function when you specify ZFS dataset, or a mount point that correlates to a ZFS dataset , as your build area.You can disable checkpointing in the manifest file by setting the checkpoint_enable parameter to false. Use the checkpointing options that are available in the distro_const command as described in the following basic instructions.For a summary of the options that are available for the distro_const command, see distro_const Command Reference. Before you build the image, check the valid steps at which you can choose to pause or resume the build by using the following command:# distro_const build [l] manifestThis command displays the valid steps at which you can pause or resume building an image. Use the step names provided by this command as valid values for the other checkpointing command options.The build subcommand is required. For example, the following command confirms which checkpoints are available, given a manifest file named slim_cd_x86.xml.# distro_const build l slim_cd_x86.xmlAfter the command is run, the valid checkpointing steps are displayed as follows.Step Resumable Description -------------- --------- ------------- im-pop X Populate the image with packages im-mod X Image area modifications slim-im-mod X Slim CD image area modifications br-init X Boot root initialization slim-br-config X Slim CD boot-root configuration br-config X Boot root configuration br-arch X Boot root archiving slim-post-mod X Slim CD post-boot-root image area modifications grub-setup X Grub menu setup post-mod X Post bootroot image area modification gen-slim-cont X Generate Slim CD image content list iso X ISO image creation The check in the resumable field indicates that you can restart the build from this step. Use the following command to build an image, and to pause building the image at the specified step.# distro_const build [p step] manifestThe build subcommand is required. The step and manifest fields are required. For example, the following command starts building an image and pauses the build before step im-mod modifies the image area:# distro_const build p im-mod slim_cd_x86.xml Resume the build, either from the last step executed or from a specified step, by using one of the following alternatives:Use the following command to resume building the image from a specified step.# distro_const build [r step] manifestThe specified step must be either the step at which the previous build stopped executing, or an earlier step. A later step is not valid. The step and manifest fields are required. The build subcommand is required. For example, the following command resumes building the image where the im-mod modifies the image area:# distro_const build r im-mod slim_cd_x86.xml Use the following command to resume building the image from the last step executed.The manifest field and the build subcommand are required. # distro_const build [R] manifestFor example, the following command resumes building the image from wherever the build had paused.# distro_const build R slim_cd_x86.xml The following table summarizes the distro_const command options.Command Options Description distro_const build manifest Creates a full image, using the specified manifest file as the blueprint for that image. The subcommand build is required. The manifest field is required. distro_const build [l] manifest Lists valid steps at which the user can choose to pause or resume building an image if checkpointing is active. This command option queries the manifest file for valid steps. Use the step names provided by this command as valid values for the other checkpointing command options. The build subcommand is required. The manifest field is required.Checkpointing is active by default, but requires ZFS filesystems.Step values other than the first value correspond to finalizer script entries in the manifest file. For example, the manifest, slim_cd/all_lang_slim_cd_x86.xml, includes the following steps:im-pop – Populate the image with packages im-mod – Image area modifications slim-im-mod – Slim CD image area modifications br-init – Boot-root initialization slim-br-config – Slim CD boot-root configuration br-config – Boot-root configuration br-arch – Boot-root archiving slim-post-mod – Slim CD post-boot-root image area modifications grub-setup – GRUB menu setup post-mod – Post-boot-root image area modification gen-slim-cont – Generate Slim CD image content list iso – ISO image creation When additional scripts are added, additional default checkpoint steps are added in the manifest file.You can edit the checkpoint step names in the manifest file. Use meaningful names for custom checkpoint steps in the manifest file instead of using step numbers. If new scripts are added, the new steps for those new scripts will disrupt a prior numbered step order.For example, the following reference in a manifest file specifies the checkpoint name of “br-arch” for a boot root archiving script:<script name="/usr/share/distro_const/bootroot_archive.py"> <checkpoint name="br-arch" message="Boot root archiving"/>In this example, when you build your image, you could refer to the “br-arch” checkpoint in the distro_const command. This checkpoint would enable you to pause building the image just before the boot root archiving script performs its task. distro_const build [p step] manifest Builds an image and pauses building the image at the specified step if checkpointing is active. The step and manifest fields are required. The build subcommand is required. distro_const build [r step] manifest Resumes building the image from the specified step if checkpointing is active. The specified step must be either the step at which the previous build stopped executing, or an earlier step. A later step is not valid. The step and manifest fields are required. The build subcommand is required. distro_const build [R] manifest Resumes building the image from the last step executed if checkpointing is active. The manifest field is required. The build subcommand is required. See also the distro_const1M man page. Review the following troubleshooting items and see the latest information at Installer Common Questions and Troubleshooting.Make sure the pkg(1) command on your system is working correctly, and your connection with the IPS server is stable. Sometimes, IPS times out when trying to download a big cluster of packages. To check outside of the distribution constructor environment, try to mimic what the constructor does in terms of installing packages. Try the following commands as root, and make sure they work correctly.pkg image-create F a opensolaris.org=http://pkg.opensolaris.org /tmp/test_img pkg R /tmp/test_img install SUNWcsd pkg R /tmp/test_ima install SUNWcs pkg R /tmp/test_img install slim_install If a manifest does not validate, as could be the case after the manifest has been changed, run the ManifestServ utility in a verbose mode to find the error.The ManifestServ utility, /usr/bin/ManifestServ, with no arguments displays the following usage:ManifestServ Usage: /bin/ManifestServ [-d] [-h|-?] [-s] [-t] [-v] [-f <validation_file_base> ] [-o <out_manifest.xml file> ] <manifest.xml file> where: -d: turn on socket debug output (valid when -s also specified) -f <validation_file_base>: give basename for schema and defval files Defaults to basename of manifest (name less .xml suffix) when not provided -h or -?: print this message -o <out_manifest.xml file>: write resulting XML after defaults and validation processing -t: save temporary file Temp file is "/tmp/<manifest_basename>_temp_<pid> -v: verbose defaults/validation output -s: start socket server for use by ManifestRead The distribution constructor validates the manifest against an XML schema and a defval manifest. ManifestServ enables you to perform a manual validation, using a verbose mode which shows where any problems are.The following example demonstrates a case where the manifest didn't validate against the schema. The boldface message below indicates this is a schema validation error.# distro_const build my_distro.xml /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/all_lang_slim_cd_x86_temp_7861.xml:350: element pair: Relax-NG validity error : Element pair failed to validate attributes /tmp/my_distro_temp_7861.xml fails to validate validate_vs_schema: Validator terminated with status 3 validate_vs_schema: Validator terminated abnormally Error validating manifest against schema /usr/share/distro_const/DC-manifest.rng # Run ManifestServ, /usr/bin/ManifestServ, specifying the t option, in order to save the temporary file, and the v option, in order to provide verbose output which will have the line number of the error.$ ManifestServ f /usr/share/distro_const/DC-manifest t v manifest_fileManifestServ -f /usr/share/distro_const/DC-manifest -t -v my_distro.xml /usr/share/distro_const/DC-manifest.defval.xml validates Checking defaults for name Checking defaults for distro_constr_params/distro_constr_flags/stop_on_error Checking defaults for distro_constr_params/pkg_repo_default_authority/main/url ... ... (omitted content) ... ... /tmp/my_distro_temp_7870.xml:350: element pair: Relax-NG validity error : Element pair failed to validate attributes /tmp/all_lang_slim_cd_x86_temp_7870.xml fails to validate validate_vs_schema: Validator terminated with status 3 validate_vs_schema: Validator terminated abnormally Error validating manifest against schema /usr/share/distro_const/DC-manifest.rng Error running Manifest Server schema_validate: Schema validation failed for DC manifest /tmp/my_distro_temp_7870.xml The temporary file will be named near the end of the output. In the example above, the file is /tmp/my_distro_temp_7870.xml. Per the bold error messages, open that file and go to line 350 to find the issue. In this example, the line 350 looks like this:<key_value_pairs> <pair value='/usr/share/distro_const/slim_cd/slimcd_iso.sort' key='iso_sort'/> <pair VaLuE='myvalue' key='mykey'/> </key_value_pairs>The attribute, VaLuE, is incorrect. This contrived example should have value in all lowercase letters, as shown the line immediately above that one. The second to last message line states that the schema validation fails. The schema used for validation for the distribution constructor is /usr/share/distro_const/DC-manifest.xml. The schema shows that the only attributes for <pair> are <value> and <key>, not <VaLuE>. Semantic validation is also done. Semantic validation checks content for “meaning” and context errors as opposed to checking only the syntax. For example, finalizer scripts listed in a manifest can be validated to confirm that the scripts are executable files.The following shows a case where the manifest failed semantic validation.# distro_const build -l my_distro_sem.xml /usr/share/distro_const/DC-manifest.defval.xml validates /usr/share/distro_const/grub_setup.py either doesn't exist or is not an executable file validate_node: Content "/usr/share/distro_const/grub_setup.py" at img_params/output_image/finalizer/script/name did not validate Error validating manifest tree content Semantic validation employs functions to do the validation, and those functions print error messages explaining why the manifest failed validation. In this contrived case, the file /usr/share/distro_const/grub_setup.py is missing, and the error message points directly to the problem. In this case, either grub_setup.py needs to be restored, or, if appropriate, the reference to that file needs to be removed from the manifest.You can still run ManifestServ with v to get more details on semantic validation, but this command option will merely list the one failure among many successes, and may produce output which is harder to read than when v is not specified. Once validation and other preprocessing is completed, ManifestServ prompts for data to dump and check. This step is more useful for testing the data serving process rather than testing the data itself, since the data is plainly visible in the manifest itself.For more information about this interface, see the DC_DESIGN_DOC document in the caiman docs gate at ssh://anon@hg.opensolaris.org/hg/caiman/caiman-docs. Additional information and resources about using the distribution constructor are available at the following sites.For further troubleshooting help, see the Release Notes at . Send questions or comments about the distribution constructor application to caiman-discuss@opensolaris.org. Submit bugs or enhancement requests to . The x86 Slim CD manifest file is shown below: <!-- CDDL HEADER START The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner] CDDL HEADER END Copyright 2009 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. XML specification for building the all languages OpenSolaris live CD iso and usb image --> <distribution name="OpenSolaris"> <distro_constr_params> <distro_constr_flags> <!-- Controls whether the DC should stop if there is an error when the DC is running --> <stop_on_error>true</stop_on_error> <!-- You can specify the step to resume the build from here with the resume_from attribute field of checkpoint_enable. This value will be overridden by the command line if the -r flag is used. Valid values are step numbers or name --> <checkpoint_enable> <!-- true implies Checkpointing is enabled --> true </checkpoint_enable> </distro_constr_flags> <!-- The preferred authority to install packages into the pkg_image area from. The default url is: http://pkg.opensolaris.org/release The default authname is opensolaris.org --> <pkg_repo_default_authority> <main url="http://pkg.opensolaris.org/release" authname="opensolaris.org"/> <!-- If you want to use one or more mirrors that are setup for the authority, specify the urls here. --> <!-- Uncomment before using <mirror url="" /> --> </pkg_repo_default_authority> <!-- Any additional non-preferred authorities to pull packages from should be specified here. Multiple additional authorities may be specified. If you want to use one or more mirrors that are setup for the authority, specify the urls here. --> <!-- Uncomment before using. <pkg_repo_addl_authority> <main url="" authname=""/> <mirror url="" /> </pkg_repo_addl_authority> --> <!-- The default preferred authority to be used by the system after it has been installed. The default url is: http://pkg.opensolaris.org/release The default authname is opensolaris.org If you want to use one or more mirrors that are setup for the authority, specify the urls here. --> <post_install_repo_default_authority> <main url="http://pkg.opensolaris.org/release" authname="opensolaris.org"/> <!-- Uncomment before using. <mirror url="" /> --> </post_install_repo_default_authority> <!-- Any additional non-preferred authorities to use after the system has been installed. Multiple additional authorities may be specified. If you want to use one or more mirrors that are setup for the authority, specify the urls here. --> <!-- Uncomment before using. <post_install_repo_addl_authority> <main url="" authname=""/> <mirror url="" /> </post_install_repo_addl_authority> --> </distro_constr_params> <img_params> <!-- Where to build. This can be a zfs dataset or a mountpoint. The area will be created if it doesn't exist. If the build_area is not a zfs dataset or mountpoint, checkpointing will not be enabled. --> <build_area>rpool/dc</build_area> <!-- list of packages used to form the installed image --> <packages> <!-- Due to dependency issues, SUNWcsd and SUNWcs must be listed first in the package list, and SUNWcsd must precede SUNWcs --> <!-- By default the latest build available, in the specified IPS repository, is installed. If another build is required, the build number has to be appended to the 'entire' package in following form: <pkg_name="entire@0.5.11-0.build#/> --> <pkg name="entire"/> <pkg name="SUNWcsd"/> <pkg name="SUNWcs"/> <pkg name="babel_install"/> <pkg name="SUNWslim-utils"/> </packages> <!-- Items below this line are rarely configured --> <!-- Packages to be removed from the pkg_image area before bootroot construction --> <post_install_remove_packages> <!-- babel_install must be listed before slim_install because babel_install depends on slim_install, so, slim_install can't be uninstall first --> <pkg name="babel_install"/> <pkg name="slim_install"/> </post_install_remove_packages> <!-- If/how to compress the live image. type = compression algorithm to use for pkg.zlib and misc.zlib. Valid types are lzma, gzip, and none. --> <live_img_compression type="lzma"/> <!-- Grub menu modifications. Will use menu.lst if not specified --> <grub_menu_modifications> <!-- Specify a title for the grub menu. If a title for the grub menu is not specified, the first line of /etc/release will be used as the title for the grub menu --> <!-- Uncomment before using <title>Special Grub Title Text</title> --> <entry> <title_suffix>with magnifier</title_suffix> <line>kernel$ /platform/i86pc/kernel/$ISADIR/unix \ -B assistive_tech=magnifier</line> <line>module /boot/$ISADIR/x86.microroot</line> </entry> <entry> <title_suffix>with screen reader</title_suffix> <line>kernel$ /platform/i86pc/kernel/$ISADIR/unix \ -B assistive_tech=reader</line> <line>module /boot/$ISADIR/x86.microroot</line> </entry> <entry> <title_suffix>Enable SSH</title_suffix> <line>kernel$ /platform/i86pc/kernel/$ISADIR/unix -B livessh=enable</line> <line>module /boot/$ISADIR/x86.microroot</line> </entry> </grub_menu_modifications> <!-- Indicate whether the IPS index should be generated for pkg install and uninstall. The default is to not generate the IPS search index --> <generate_ips_search_index> false </generate_ips_search_index> <!-- Files and dirs to be included in the bootroot of all media delivered by this distribution. Bootroot contains the minimal list of contents in order to be able to boot and setup a running system. These files and dirs must exist in the pkg_image area. --> <bootroot_contents> <base_include type="file">usr/sbin/pmadm</base_include> <base_include type="file">usr/sbin/lofiadm</base_include> <base_include type="file">usr/sbin/devfsadm</base_include> <base_include type="file">usr/sbin/modload</base_include> <base_include type="file">usr/sbin/i86/modload</base_include> <base_include type="file">usr/sbin/mount</base_include> <base_include type="file">usr/sbin/hostconfig</base_include> <base_include type="file">usr/sbin/chroot</base_include> <base_include type="file">usr/sbin/syslogd</base_include> <base_include type="file">usr/bin/coreadm</base_include> <base_include type="file">usr/bin/bash</base_include> <base_include type="file">usr/bin/ksh</base_include> <base_include type="file">usr/bin/cat</base_include> <base_include type="file">usr/bin/echo</base_include> <base_include type="file">usr/bin/false</base_include> <base_include type="file">usr/bin/grep</base_include> <base_include type="file">usr/bin/ls</base_include> <base_include type="file">usr/bin/rm</base_include> <base_include type="file">usr/bin/svcprop</base_include> <base_include type="file">usr/bin/true</base_include> <base_include type="file">usr/bin/cd</base_include> <base_include type="file">usr/bin/test</base_include> <base_include type="file">usr/bin/sleep</base_include> <base_include type="file">usr/bin/expr</base_include> <base_include type="file">usr/lib/fs/hsfs/fstyp</base_include> <base_include type="file">usr/lib/fs/hsfs/fstyp.so.1</base_include> <base_include type="file">usr/lib/fs/hsfs/mount</base_include> <base_include type="file">usr/lib/fs/ufs/fstyp</base_include> <base_include type="file">usr/lib/fs/ufs/fstyp.so.1</base_include> <base_include type="file">usr/lib/fs/ufs/mount</base_include> <base_include type="file">usr/lib/libfstyp.so.1</base_include> <base_include type="file">usr/lib/platexec</base_include> <base_include type="file">usr/lib/devfsadm/devfsadmd</base_include> <base_include type="file">usr/lib/libm.so.2</base_include> <base_include type="file">usr/lib/libm.so</base_include> <base_include type="file">usr/lib/libfstyp.so</base_include> <base_include type="file">usr/lib/libz.so</base_include> <base_include type="file">usr/lib/libz.so.1</base_include> <base_include type="file">usr/bin/i86/ksh93</base_include> <base_include type="file">usr/lib/isaexec</base_include> <base_include type="file">usr/lib/libast.so.1</base_include> <base_include type="file">usr/lib/libcmd.so.1</base_include> <base_include type="file">usr/lib/libdll.so.1</base_include> <base_include type="file">usr/lib/libshell.so.1</base_include> <base_include type="file">usr/share/lib/xml/dtd/service_bundle.dtd.1</base_include> <base_include type="file">var/sadm/install/admin/default</base_include> <base_include type="file">var/sadm/system/admin/default_java</base_include> <base_include type="file">var/sadm/install/contents</base_include> <base_include type="file">var/adm/utmpx</base_include> <base_include type="file">var/adm/wtmpx</base_include> <base_include type="file">var/adm/aculog</base_include> <base_include type="file">var/lib/postrun/postrun-runq</base_include> <base_include type="file">var/lib/postrun/postrun</base_include> <base_include type="file">var/log/postrun.log</base_include> <base_include type="file">var/log/authlog</base_include> <base_include type="file">var/log/syslog</base_include> <base_include type="file">var/saf/zsmon/log</base_include> <base_include type="file">var/spool/cron/crontabs/adm</base_include> <base_include type="file">var/spool/cron/crontabs/root</base_include> <base_include type="file">var/nis/NIS+LDAPmapping.template</base_include> <base_include type="file">var/yp/aliases</base_include> <base_include type="file">var/yp/nicknames</base_include> <base_include type="dir">kernel</base_include> <base_include type="dir">boot</base_include> <base_include type="dir">platform</base_include> <base_include type="dir">system</base_include> <base_include type="dir">lib</base_include> <base_include type="dir">sbin</base_include> <base_include type="dir">dev</base_include> <base_include type="dir">devices</base_include> <base_include type="dir">usr/lib/devfsadm/linkmod</base_include> <base_include type="dir">root</base_include> <base_include type="dir">jack</base_include> <base_include type="dir">var/svc/manifest</base_include> <base_include type="dir">var/svc/profile</base_include> <base_include type="dir">var/pkg/catalog</base_include> <base_include type="file">var/pkg/cfg_cache</base_include> <base_include type="dir">etc</base_include> <base_exclude type="dir">etc/gconf</base_exclude> <base_exclude type="dir">etc/brltty</base_exclude> <base_exclude type="dir">etc/gtk-2.0</base_exclude> <base_exclude type="dir">etc/notices</base_exclude> </bootroot_contents> <output_image> <!-- List of finalizer scripts to be run. They are used to customize the image and will be run in the order listed. The name of the checkpoint to be created when this script is run is required. The checkpoint message is displayed when the step is run and is optional. There are 5 standard arguments that are passed to every finalizer script (manifest socket, pkg_image path, tmp dir, bootroot build area, media dir). You may also specify additional arguments (arg6+) in the argslist. This argslist is a whitespace-separated list of double quoted strings. --> <finalizer> <script name="/usr/share/distro_const/pre_bootroot_pkg_image_mod"> <checkpoint name="im-mod" message="Image area modifications"/> </script> <script name="/usr/share/distro_const/slim_cd/ slimcd_pre_bootroot_pkg_image_mod"> <checkpoint name="slim-im-mod" message="Slim CD Image area Modifications"/> </script> <script name="/usr/share/distro_const/bootroot_initialize.py"> <checkpoint name="br-init" message="Boot root initialization"/> </script> <script name="/usr/share/distro_const/slim_cd/slimcd_bootroot_configure"> <checkpoint name="slim-br-config" message="Slim CD boot root configuration"/> </script> <script name="/usr/share/distro_const/bootroot_configure"> <checkpoint name="br-config" message="Boot root configuration"/> <argslist> "/usr/share/distro_const/slim_cd/slimcd_generic_live.xml" ".livecd" </argslist> </script> <script name="/usr/share/distro_const/bootroot_archive.py"> <checkpoint name="br-arch" message="Boot root archiving (64-bit)"/> <argslist>"amd64"</argslist> </script> <script name="/usr/share/distro_const/bootroot_archive_32"> <checkpoint name="br-arch-32" message="Boot root archiving (32-bit)"/> <argslist>"x86"</argslist> </script> <script name="/usr/share/distro_const/slim_cd/ slimcd_post_bootroot_pkg_image_mod"> <checkpoint name="slim-post-mod" message="Slim CD post bootroot image area modification"/> </script> <script name="/usr/share/distro_const/grub_setup.py"> <checkpoint name="grub-setup" message="Grub menu setup"/> </script> <script name="/usr/share/distro_const/post_bootroot_pkg_image_mod"> <checkpoint name="post-mod" message="Post bootroot image area modification"/> <argslist> "usr_zlib_compression=lzma" </argslist> </script> <script name="/usr/share/distro_const/slim_cd/slimcd_gen_cd_content"> <checkpoint name="gen-slim-cont" message="Generate Slim CD image content list"/> </script> <script name="/usr/share/distro_const/create_iso"> <checkpoint name="iso" message="ISO image creation"/> </script> <script name="/usr/share/distro_const/create_usb"> <checkpoint name="usb" message="USB image creation"/> </script> </finalizer> <bootroot> <!-- If/how to compress the bootroot. Valid types are gzip and none --> <compression type="gzip" level="9"/> </bootroot> </output_image> </img_params> <key_value_pairs> <pair key="iso_sort" value="/usr/share/distro_const/slim_cd/slimcd_iso.sort"/> </key_value_pairs> </distribution>