7 Producing Kernel Product Kits

This chapter tells you how to produce a kernel product kit, what additional files are required, and how to test the kit installation.

Note

The information in this chapter describes how to produce kernel product kits. If you want to create a user product kit, go to Chapter 6.

Follow these steps to create and test a kernel product kit:

Read Chapter 1 for an overview of product kits.

Design the kit directory structure as described in Chapter 2.

Prepare subsets and associated control files as described in Chapter 3.

Create subset control programs (Chapter 4). Subset control programs are required for kernel product kits.

Produce and test subsets as described in Chapter 5.

Create additional installation files as described in Section 7.2.

Rerun the newinv utility as described in Section 5.3 to update the master inventory file with the additional installation files.

Rerun the kits utility as described in Chapter 5 to produce updated subsets and control files.

Create the kit distribution media as described in Section 7.3.

Test the distribution media as described in Section 7.4.

7.1 Overview

A kernel product is a layered product that contains kernel support. Users do not run kernel products directly; the operating system and utilities access kernel products to perform their work. For example, a device driver is one common type of kernel product. A user runs an application or utility, which generates system requests to perform operations such as opening a file or writing data to a disk. The system determines which device driver should service this request and then calls the required driver interface.

The kernel modules and the kit support files are distributed as part of the kernel product kit, and can be installed either directly from the distribution media or loaded onto a Remote Installation Services (RIS) area for installation by RIS clients over a local area network (LAN).

Caution

The following restrictions apply to kernel product kits that support hardware provided by outside manufacturers, commonly referred to as third party hardware support:

Third party hardware devices are not supported in clusters environments.

Third party storage devices are supported as data devices only. Boot support is not available for third party storage devices.

Third party graphics devices can be supported, but the device reverts to VGA mode after an Update Installation if that device's support is not included in the update package. Reinstalling the device's kernel kit after the Update Installation can restore full graphics support.

Third party platforms can be supported, but only for Full Installation.
If the system kernel is destroyed, you cannot restore it from genvmunix. You would have to do a Full Installation of the operating system and reinstall the third party platform support.
With the number of restrictions on third party platform support, Compaq recommends that all third party platform support be delivered by the Compaq new hardware delivery (NHD) process. For more information, please send electronic mail to upmbosstaff@compaq.com.

7.2 Creating Additional Installation Files

The files needed to build a kernel product kit depend on whether the kit will be configured statically or dynamically on the customer's system. For example:

A statically configured product is linked statically into the kernel at build (or bootlink) time and configured at boot time. A static product can be built from source files, binary objects, modules, or all three.

A dynamically configured product is loaded into a running kernel after it has been booted. It is not part of the permanent kernel and is configured when it is loaded. It must be reloaded after each boot of the system. A dynamic product can be built from source files, binary objects, modules, or all three.

Note:

A module that can be loaded dynamically also can be linked statically. The only difference is the call to configure the product. For more information on static and dynamic drivers, see the Writing Device Drivers manual.

Figure 7-1 shows the files that make up the ODB product kit source directory. Additional kernel product files are highlighted.

Figure 7-1: Kernel Product Source Directory

Note

The files locations in the following list describe where you would find the files when you receive the product from the kit developer. Figure 7-1 shows where these files are located in the actual kit source hierarchy.

/odb.conf -- the ODB product configuration file.
If your product kit may run on a cluster, each cluster member must have its own configuration file. To accommodate this requirement, create a context-dependent symbolic link (CDSL) targeted to the member-specific file.
1. The context-dependent symbolic link (CDSL) for the odb.conf file is linked to the member-specific cluster/members/{memb}/opt/OAT100/odb.conf file. This CDSL is installed in the root file system and placed in the opt/OAT100 source directory.
2. The member-specific file odb.conf file can differ on each cluster member. This file is installed in the cluster member's root file system and is placed in the cluster/members/member0/opt/OAT100 source directory.

/sbin/odb_recover -- a utility to recover corrupt ODB documents when the system boots.
The odb_recover script executes when the system boots and the /usr file system may not be mounted. This file is installed in the root file system and is placed in the opt/OAT100/sbin source directory.

/usr/bin/odb_start -- the ODB product startup script.
The odb_start script is a user command. This file is installed in the /usr file system and is placed in the usr/opt/OAT100/bin source directory.

/usr/var/log_files/odb_log -- the ODB product log file.
If the product kit can be installed on a cluster, each cluster member must have its own copy of the log file. To accommodate this requirement, create a context-dependent symbolic link (CDSL) targeted to a member-specific file.
1. The context-dependent symbolic link (CDSL) for the odb_log file is linked to the member-specific usr/var/cluster/members/{memb}/opt/OAT100/log_files/odb_log file. This CDSL is installed in the /usr/var file system and placed in the usr/var/opt/OAT100/log_files source directory.
2. The member-specific file odb_log file can differ on each cluster member. This file is installed in the cluster member's /usr/var file system and is placed in the /usr/var/cluster/members/member0/opt/OAT100/log_files source directory.
See Section 2.3.2 for information about CDSLs.

/usr/var/templates/odb_template -- a document template that can be modified by a user.
This file is installed in the /var file system and is placed in the usr/var/opt/OAT100/templates source directory.

/etc/files -- the files file fragment contains information about the location of the source code and modules associated with the driver, tags indicating when the driver is loaded into the kernel, and whether the source or binary form of the driver is supplied to the customer.

Note

This is not a complete /etc/files file.

/etc/sysconfigtab -- the sysconfigtab file fragment contains device special file information, bus option data, and information on contiguous memory usage for statically and dynamically configured drivers.

Note

This is not a complete /etc/sysconfigtab file.

The sysconfigtab file fragment gets appended to the /etc/sysconfigtab database when the kernel product kit is installed. See sysconfigtab(4) for more information.
If the product kit can be installed on a cluster, each cluster member must have its own copy of the sysconfigtab file fragment. To accommodate this requirement, create a context-dependent symbolic link (CDSL) targeted to the member-specific file.
1. The context-dependent symbolic link (CDSL) for the sysconfigtab file fragment is linked to the member-specific cluster/members/{memb}/opt/OAT100/etc/sysconfigtab file. This CDSL is installed in the root file system and placed in the opt/OAT100/etc source directory.
2. The member-specific sysconfigtab file can differ on each cluster member. This file is installed in the cluster member's root file system and is placed in the cluster/members/member0/opt/OAT100/etc source directory.
See Section 2.3.2 for information about CDSLs.

/sys/BINARY/odb_printer.mod -- the object module file containing the single binary module for the ODB kernel product.

A kernel product kit requires you to include the following files on the distribution media to make the kernel product accessible during installation:

The files file fragment (Section 7.2.1)

The sysconfigtab file fragment (Section 7.2.2)

The driver.mod object module file (Section 7.2.3)

The *.c (source) and *.h (header) files (Section 7.2.4)

The device.mth method files (Section 7.2.5)

7.2.1 The files File Fragment

The files file fragment contains information about the location of the source code and modules associated with the driver, tags indicating when the driver is loaded into the kernel, and whether the source or binary form of the driver is supplied to the customer. You need to edit this file if the kit development directory structure differs from the driver development directory structure or if you must change the driver name for any reason.

Caution

The files file fragment must be in the same directory as the kernel modules or the kreg and doconfig utilities will not work properly.

Figure 7-2 shows which fields within the files file fragment need to change.

Figure 7-2: Editing the files File Fragment

7.2.2 The sysconfigtab File Fragment

The sysconfigtab file fragment contains device special file information, bus option data information, and information on contiguous memory usage for statically and dynamically configured drivers. When the user installs a kernel product kit, the driver's sysconfigtab file fragment gets appended to the /etc/sysconfigtab database. You should place this file fragment in a product directory, such as /opt/OAT100/etc.

You do not need to change the sysconfigtab file fragment unless you change the driver (subsystem) name. The driver name appears in three places within the file, as shown in Figure 7-3. In the example, the driver runs on a TURBOchannel bus (indicated by the TC_Option entry), but a similar set of bus options would be specified for other bus types.

Figure 7-3: Editing the sysconfigtab File Fragment

See sysconfigtab(4) for more information about the /etc/sysconfigtab file.

7.2.3 The Object Module File

The driver.mod object module file contains the single binary module for both statically and dynamically configured drivers. Include this file in a product directory, such as /opt/OAT100/sys/BINARY, in the root ( / ) file system.

Caution

You cannot use RIS to link compressed modules. Use the file command to determine if a file is compressed. You see output similar to the following:
# file odb_graphics.mod
odb_graphics.mod:
    alpha compressed COFF executable or object module not stripped

7.2.4 The Source and Header Files

The *.c (source) and *.h (header) files contain the source code for the device driver. Include these files in a product directory, such as /usr/opt/OAT100/src, when the driver is statically configured and distributed in source form.

7.2.5 The Method Files

The device.mth method files contain driver methods that are called during automatic configuration to create device special files for dynamically configured drivers. The subset control program creates links to these device special files in the customer's subsys directory when the driver is installed. The driver method files are on the distribution media and are not installed onto the customer's system. The device driver developer can tell you which method files the subset control program should link to, typically /subsys/device.mth. Link the method in a device driver kernel kit only if the driver needs to have device special files created for its devices.

7.3 Producing Distribution Media

After you have tested the subsets, you can produce the distribution media. Distribution media production consists of the following tasks:

Rerun the newinv utility to update the master inventory file with the additional installation files. (Section 5.3)

Rerun the kits utility to produce updated subsets and control files. (Chapter 5)

Edit the /etc/kitcap file. (Section 7.3.1)

Build the kernel product kit on the distribution media.
- Use the gendisk utility to build a kit on disk media. (Section 7.3.2)
- Use the gentapes utility to build a tar format kit on magnetic tape. (Section 7.3.3)

You can produce the kernel product kit in either tar format or direct CD-ROM (DCD) format. Installation time for tar format kits is faster than for DCD format kits.

If your product kit does not access kernel modules during boot, use the tar format to compress your kit and save space on the media.
In tar format, the product files in each subset are written to the distribution media as a single file. During installation, the setld utility uncompresses the files and moves them onto the target system, preserving the files' original directory structure. Kits distributed in tar format install more quickly and consume less space on the distribution media.

If your product kit accesses kernel modules during the boot process, you must use the DCD format and cannot produce the kit on magnetic tape media.
In DCD format, the files are written to the distribution media as a UNIX file system where the product files are organized into a directory structure that mirrors the target system. Subsets distributed in DCD format cannot be compressed.

You can distribute kernel product kits on diskette, CD-ROM, or magnetic tape, as follows:

Diskettes are good for testing purposes or for small products. The product must fit on a single diskette; it cannot span multiple diskettes. Use the gendisk utility to produce kits for diskette media.

CD-ROMs can support large kits or multiple kits on a single media. The kit is first produced on the hard disk, then written onto the CD-ROM. Use the gendisk utility to produce the master kit on hard disk. Follow the CD-ROM manufacturer's instructions for writing the kit onto the CD-ROM media.

Magnetic tape
Magnetic tape can be used for kernel product distribution if you do not need to access the kernel modules during the boot process. You must use tar format; magnetic tape does not support DCD format. Use the gentapes utility to produce kits for magnetic tape media.

Figure 7-4 shows the file formats and distribution media available for kernel product kits.

Figure 7-4: Kernel Product Kit File Formats

7.3.1 Editing the /etc/kitcap File

The gendisk and gentapes utilities refer to the /etc/kitcap file, a database containing information about the kits to be built on the system. Each record contains a product code and the names of the directories, files, and subsets that make up the product kit. Before you can build your kit, you must add a media descriptor record to the /etc/kitcap database.

Note

If you use the gendisk utility to produce your kit on disk distribution media, you can specify an alternate kit descriptor database. See gendisk(1) for more information.

Use the following conventions when you add a record to the /etc/kitcap file:

Separate the first field from the rest of the record by a colon ( : ) for disk media descriptors and by a pipe character ( | for tape media descriptors.

Separate all other fields with colons ( : ).

Indicate continuation with a backslash ( \ ) at the end of the line.

Lines starting with a pound sign ( # ) are comments and are ignored.

Comments within the record start with pound sign ( # ) and end with a colon ( : ). Use this feature sparingly.

The contents of a kitcap record differ depending on whether you are producing disk or tape media. You must add one record for each media type on which you plan to distribute your kit.

The contents of the record also depend on the product type you are delivering. For example, the kitcap record for a kernel product may require the kk=true parameter and the rootdd= option. See kitcap(4) for more information about the contents of the /etc/kitcap file.

7.3.1.1 Disk Media Descriptor

Create a disk media kitcap record when you produce kits for distribution on diskette or CD-ROM. The kitcap record for disk media contains the following elements:

The kit name, consisting of two parts:
- The product code, consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file (prodcode.k).
- The media code HD to indicate disk media. This element is followed by a colon ( : ).

The partition on the disk media where the product should be placed. The partition is a letter between a and h. Partition c is used most often, as it spans the entire disk.

The destination directory for the subsets on the disk media. This allows a hierarchical structure so you can put multiple products on one disk, or put parts of one product on different areas of the same disk. You can use multiple destination directories in a kitcap record.
The destination directory field also may include these parameters:
- kk=true
  Indicates that the kit is needed during the boot process. When the gendisk utility finds this option, it automatically generates a kitname.kk file.
- rootdd=dirname
  Specifies kit file placement on the distribution media, relative to the kit-specific directory such as /OAT100/kit. For example, rootdd=.. would place the kit's root under the /OAT100 directory.

The product description. This entry is taken from key file NAME field. Replace any spaces with an underscore ( _ ) character, for example: Product Description becomes Product_Description.

The name of the output directory where you created the kit, where the gendisk utility can find the product subsets.

The instctrl directory, relative to the output directory specification.

The names of the subsets that make up the kit.

See kitcap(4) for more information about the disk media record format.

See Section 3.3 for information about the key file.

Example 7-1 shows the record to be added to the /etc/kitcap file to produce the ODB kit on disk media:

Example 7-1: Sample Disk Media Descriptor for Kernel Product

OAT100HD:c:\
  dd=/OAT100:Orpheus_Document_Builder:/mykit/output:\
  instctrl:OATODB100:OATODBTEMPS100:OATODBKERNEL100

Based on the information shown in Example 7-1, the gendisk utility places the kit on the c partition in the / (root) directory of the disk media. The product description is Orpheus_Document_Builder and the kit output directory is named /mykit/output. The kit consists of three subsets: OATODB100, OATODBTEMPS100, and OATODBKERNEL100.

7.3.1.2 Tape Media Descriptor

The kitcap record for tape media contains the following elements:

The kit name, consisting of two parts:
- Product code, consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file (prodcode.k).
- The media code, either TK for TK50 tapes or MT for 9-track magnetic tape. This element is followed by a pipe character ( | ).

Product description. This entry is taken from the NAME field of the key file.

Name of the output directory where you created the kit, where the gentapes utility can find the subsets.
Since the gentapes utility can take subsets from multiple products and merge them on tape as a combined product, you can specify multiple directories where the gentapes utility can find the subsets. There must be one directory entry for each kitcap descriptor.

Three empty SPACE files to ensure compatibility with operating system kits. To create the SPACE file in the output area of the kit directory structure, issue the following commands:
```
# cd /mykit/output
# touch space
# tar -cf SPACE space
```

The INSTCTRL image in the output directory containing setld control information.

The names of the subsets that make up the kit. Each subset listed must be stored in one of the specified directories.

Optional volume identifiers %%N, followed by the names of the subsets to be placed on that volume. You can use multiple tapes.

See kitcap(4) for more detailed information about the tape media record format.

Example 7-2 shows the record to be added to the /etc/kitcap file to produce the ODB kit on TK50 tapes:

Example 7-2: Sample Tape Media Descriptor

OAT100TK|Orpheus Document Builder:\
  /mykit/output:SPACE:SPACE:SPACE:\
  INSTCTRL:OATODB100:OATODBTEMPS100:OATODBKERNEL100

The product name, OAT100, is the same name that appears in the key file. The product description, Orpheus Document Builder also appears in the key file. The name of the output directory is specified as /mykit/output, and three SPACE files are included for compatibility with operating system kits. The last line of the record contains the INSTCTRL image in the output directory and the names of the subsets that make up the kit: OATODB100, OATODBTEMPS100, and OATODBKERNEL100.

7.3.2 Building a Kernel Product Kit on Disk Media

When the product subsets are located in the output area of the kit directory structure, use the gendisk utility to create the kit on a disk.

Note

The gendisk utility supports diskettes but does not allow you to create a chained diskette kit. A kit written to diskette must fit on a single diskette or be packaged as a set of kits on separate diskettes.

Use the following syntax for the gendisk command:

gendisk [-d] [-i] [-k filename] [-w] [-v] [hostname:] prodID devname

-d: Creates a distribution disk in direct CD (DCD) format. This means that the distribution disk contains uncompressed file systems that are arranged in the same way as the software will be installed on the system.
-i: Creates a distribution disk in ISO 9660 format. This means that the distribution disk contains an ISO 9660-compliant CD-ROM file system (CDFS).
-k filename: Uses an alternate kit descriptor database, filename, on the local system. You may use either a full absolute pathname or a relative pathname from the directory where you run the gendisk utility. You do not have to name the file kitcap.
-w: If used without the -v option, writes the product media without verification. If used with the -w option, the gendisk utility writes and then verifies the product media.
-v: If used without the -w option, verifies the product media without writing it first. This assumes that you already have written kit files to the distribution media. If used with the -w option, the gendisk utility writes and then verifies the product media.
hostname:: The optional hostname: operand is the name of a remote machine that contains the kitcap file. The utility searches the /etc/kitcap file on the remote machine for the prodID and uses it for creating the media. The colon (:) is a required delimiter for TCP/IP networks, and space is permitted between the colon and the prodID. For example, if the product code is OAT100 and you are using the kit descriptor database on node mynode, use mynode:OAT100 for this option.
prodID: The mandatory prodID operand is a kit identifier consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file. See Section 3.3 for information about the key file.
devname: The mandatory devname operand specifies the device special file name for a raw or character disk device such as /dev/rdisk/dsk1. The gendisk utility uses the disk partition specified in the kit descriptor and ignores any partition specified on the command line.

Note

If you do not use either the -w or -v options, the gendisk utility writes and then verifies the product media.

The command shown in Example 7-3 creates a tar format kernel product kit for OAT100 on dsk0:

Example 7-3: Sample gendisk Command

# gendisk OAT100 /dev/rdisk/dsk0

See gendisk(1) for more information.

7.3.3 Building a Kernel Product Kit on Magnetic Tape

When the product subsets are located in the output area of the kit directory structure, use the gentapes utility to create the kit on magnetic tape. Use the following syntax for the gentapes command:

gentapes [ -w | -v ] [hostname:] prodID devname

-w: Writes the product media without verification. Do not use the -w option with the -v option.
-v: Verifies the product media without writing it first. Do not use the -v option with the -w option.
hostname:: The optional hostname: argument is the name of a remote network machine that contains the kit descriptor database. The gentapes utility searches the kit descriptor database on the remote machine for the kit identifier (prodID[TK|MT]) and uses it to create the media. The colon (:) is a required delimiter for TCP/IP networks, and space is permitted between the colon and the prodID. For example, if the product code is OAT100 and you are using the kit descriptor database on node mynode, use mynode:OAT100 for this option.
prodID: The mandatory prodID operand is a kit identifier consisting of the product code and version number specified in the CODE and VERS fields of the kit's key file. See Section 3.3 for information about the key file.
devname: The mandatory devname operand specifies the device special file name for a no-rewind tape device such as /dev/ntape/tape0l. The gentapes utility uses the default tape density for the device and ignores any suffix specified on the command line.

Note

If you do not use either the -w or -v option, the gentapes utility writes the tape, rewinds it, and then verifies the files in the kit descriptor.

The command shown in Example 7-4 creates a tar format user product kit for OAT100 on the magnetic tape in /dev/ntape/dat:

Example 7-4: Sample gentapes Command

# gentapes OAT100 /dev/ntape/dat

See gentapes(1) for more information about this utility.

7.4 Testing the Distribution Media

Before shipping a kernel product kit to customers, you should test the kit with the same procedures that your customers will use on configurations that resemble your customers' systems.

Run the following tests to test a kernel product kit:

Use the setld utility to verify that the subsets have been built correctly and that the files get installed into the correct locations on the target system. (Section 7.4.1)

Use the ris utility to add a kernel product kit into a RIS area and verify that the correct files are present on the kit. Then, register the client system to the RIS area and use the setld -l command to install the product on the client system. (Section 7.4.2)

7.4.1 Testing a Kernel Product Kit with the setld Utility

Use the setld utility to test a kernel product kit as described in the following procedure for the OAT100 kit:

Log in to the system as root or use the su command to gain superuser privileges.

Place the CD-ROM in the drive.

Create a directory to be the media mount point, such as /cdrom:
```
# mkdir /cdrom
```

Mount the CD-ROM on /cdrom. For example, if the CD-ROM device is located on the c partition of cdrom0, enter the following command:
```
# mount -r /dev/disk/cdrom0c /cdrom
```

Use the setld utility to install the kernel product subsets:

# setld -l /cdrom/OAT100/kit

Your session looks similar to the following:

*** Enter subset selections ***
 
The following subsets are mandatory and will be installed automatically
unless you choose to exit without installing any subsets:
 
      * Document Builder Kernel Support
      * Document Builder Tools
 
The subsets listed below are optional:
 
 - Other:
     1) Document Builder Templates
 
Or you may choose one of the following options:
 
     2) ALL mandatory and all optional subsets
     3) MANDATORY subsets only
     4) CANCEL selections and redisplay menus
     5) EXIT without installing any subsets
 
Estimated free diskspace(MB) in root:54.5 usr:347.0
 
Enter your choices or press RETURN to redisplay menus.
 
Choices (for example, 1 2 4-6): 2
 
You are installing the following mandatory subsets:
 
        Document Builder Kernel Support
        Document Builder Tools
 
You are installing the following optional subsets:
 
 - Other:
        Document Builder Templates
 
Estimated free diskspace(MB) in root:54.5 usr:347.0
 
Is this correct? (y/n): y
 
Checking file system space required to install selected subsets:
 
File system space checked OK.
 
3 subset(s) will be installed.
 
Loading subset 1 of 3 ...
 
Document Builder Tools
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
Loading subset 2 of 3 ...
 
Document Builder Templates
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
Loading subset 3 of 3 ...
 
Document Builder Kernel Support
   Copying from /cdrom/OAT100/kit (disk)
   Verifying
 
3 of 3 subset(s) installed successfully.
 
Configuring "Document Builder Tools" (OATODB100)
 
The installation of the Document Builder Tools (OATODB100)
software subset is complete.
 
Please read the /opt/OAT100/README.odb file before
using the Document Builder Tools product.
 
Configuring "Document Builder Templates" (OATODBTEMPS100)
 
Configuring "Document Builder Kernel Support" (OATODBKERNEL100)
 
*** Document Builder Kernel Support Product Installation Menu ***
 
1. Statically configure the graphics support
2. Dynamically configure the graphics support
 
Type the number of your choice []: 1
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /sys/conf/TEST01 as /sys/conf/TEST01.bck
 
Do you want to edit the configuration file? (y/n) [n]: n
 
*** PERFORMING KERNEL BUILD ***
        Working....Fri May 9 14:49:25 EDT 2001
 
The new kernel is /sys/TEST01/vmunix
 
The /sys/TEST01/vmunix kernel has been
moved to /vmunix and the changes will take effect
the next time the system is rebooted.
#

The setld utility displays prompts and messages to guide you through the process of selecting the subsets you want to install. As each subset is loaded, the setld utility calls the subset control program as needed, including static or dynamic driver configuration. Figure 7-5 shows the steps the subset control program takes to statically configure the driver.

Figure 7-5: Static Configuration of a Driver

When the installation is complete, unmount the CD-ROM:
```
# umount /cdrom
```

If the product was configured statically, restart the system with the new kernel:
```
# /usr/sbin/shutdown -r now
```
When the system restarts, the device driver is available on the system.

Verify that the installed product functions correctly.

Delete the ODB subsets with the setld -d command.

# setld -d OATODB100 OATODBTEMPS100 OATODBKERNEL100

You see output similar to the following:

Deleting "Document Builder Templates" (OATODBTEMPS100).
 
*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
 
Saving /sys/conf/TEST01 as /sys/conf/TEST01.bck
 
Do you want to edit the configuration file? (y/n) [n]: n
 
*** PERFORMING KERNEL BUILD ***
        Working....Fri May 9 14:55:31 EDT 2001
 
The new kernel is /sys/TEST01/vmunix

The /sys/TEST01/vmunix kernel has been
moved to /vmunix and the changes will take effect
the next time the system is rebooted.
 
Deleting "Document Builder Kernel Support" (OATODBKERNEL100).
 
Deleting "Document Builder Tools" (OATODB100).
#

Use the shutdown command to restart the system, ensuring that it reboots with the new kernel after the product is removed:
```
# /usr/sbin/shutdown -r now
```
When the system restarts, the product should not be available on the system.

See Installation Guide and the setld(8) for more information about using the setld utility to install layered products.

7.4.2 Testing a Kernel Product Kit in a RIS Area

Use the ris utility to test a kernel product kit on a RIS server as described in the following procedure for the OAT100 kit. See Sharing Software on a Local Area Network manual for more information about Remote Installation Services (RIS).

Log in to the RIS server as root or use the su command to gain superuser privileges.

Place the CD-ROM in the drive.

Create a directory to be the media mount point, such as /cdrom:
```
# mkdir /cdrom
```

Mount the CD-ROM on /cdrom. For example, if the CD-ROM device were located on the c partition of cdrom0, enter the following command:
```
# mount -r /dev/disk/cdrom0c /cdrom
```

Enter /usr/sbin/ris to start the ris utility.

You see the RIS Utility Main Menu:

*** RIS Utility Main Menu ***
 
Choices without key letters are not available.
 
  ) ADD a client
  ) DELETE software products
 i) INSTALL software products
  ) LIST registered clients
  ) MODIFY a client
  ) REMOVE a client
  ) SHOW software products in remote installation environments
 x) EXIT
 
Enter your choice:

Enter i to select Install software products. You see the RIS Software Installation Menu:

RIS Software Installation Menu:
    1)  Install software into a new area
    2)  Add software into an existing area
    3)  Return to previous menu
 
Enter your choice:

Depending on your test environment, enter 1 to select Install software into a new area or 2 to Add software into an existing area.

Install the software as described in Sharing Software on a Local Area Network.

To install the product kit from the RIS server onto the client system, first register the client system with the RIS server and then use the setld utility as described in the following procedure:

Log in to the RIS server as root or use the su command to gain superuser privileges.

Enter /usr/sbin/ris to start the ris utility. You see the RIS Utility Main Menu:

*** RIS Utility Main Menu ***
 
Choices without key letters are not available.
 
 a) ADD a client
 d) DELETE software products
 i) INSTALL software products
  ) LIST registered clients
  ) MODIFY a client
  ) REMOVE a client
 s) SHOW software products in remote installation environments
 x) EXIT
 
Enter your choice:

Enter a to select ADD a client.

Enter the client information as described in Sharing Software on a Local Area Network.

Log in to the RIS client as root or use the su command to gain superuser privileges.

Use the setld -l command to load the product subsets from the RIS area. For example, if the RIS server is named test01, enter the following command:
```
# setld -l test01:
```
The setld utility displays prompts and messages to guide you through the installation process as described in Sharing Software on a Local Area Network.
See the Installation Guide and the setld(8) for more information on using the setld utility to install layered products.