12    Managing DMS Clients and Environments

This chapter describes how to use the dmu utility to manage Dataless Management Services (DMS) environments and clients. The information in this chapter describes how to:

12.1    Adding a DMS Client

The information you need to add a DMS client is shown in the Client Setup Worksheet in Appendix B. You should fill out a worksheet for each client you want to add before you use dmu to add clients to a DMS environment.

Before you can add a client, you must have already followed the procedures in Chapter 11 to install software in at least one DMS environment, and customize the .proto.. files (if desired).

The client system must be connected to a Local Area Network (LAN) and must be registered with the server through one of the network naming services (see Section 10.8) or must have an entry in the server's /etc/hosts file.

When a client is added to a DMS environment, the root directory from the server's DMS environment gets copied to the client area.

Use the following procedure to add a client to a DMS environment:

  1. Invoke the dmu utility by entering the following command at the root system prompt:

    #  /usr/sbin/dmu

  2. Choose the ADD a client option by entering a at the DMU Main Menu prompt: 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT
    Enter your choice:  a

  3. The following confirmation message is displayed along with the information you are asked to provide about the client: 

    You have chosen to add a client for dataless service.

     
    
The following conditions must be met to add a client:

     
    
   1. You must know the client processor's hostname.
   2. The client's hostname must be in your system's host
      database(s).
   3. You must know the client's interface type, subnet
      mask.
   4. You must know the type of kernel build area.
   5. You must know the swap device and partition on the
      client.
   6. You must know the client's hardware Ethernet or FDDI
      address.
   7. If the client and the server reside on different subnets,
      you will need the address of the gateway(s) that the
      client can sue to communicate with the server.

     
    
Do you want to continue? (y/n) [y]:

    If you enter n, the dmu utility returns to the DMU Main Menu. If you enter y or press the Return key (to accept the default), the utility prompts you to enter the client's host name.

  4. The following message is displayed when the server and client are on different networks. You must provide the gateway information needed for the client to connect to the server. RIS stores this information in the /var/adm/ris/gateways file. RIS displays the default network information if the gateway information is known.

    The following are the known gateway[s] between the client  subnet and server subnet. If these values[s] are not correct,  please enter the proper addresses[s].  If these values are correct press Return.  ( For example, 16.69.144.???):  [16.69.144.199]

    Enter the client's route for network address as shown in the following example:

    Enter the IP address of the gateway[s] between the client  subnet and server subnet:  ( For example, 16.69.144:???):  [16.69.144.199]

  5. Enter a host name that has an entry in the server system's host database by using the Network Information Service (NIS) or Berkeley Internet Name Domain (BIND) naming services or by making an entry in the server's /etc/hosts file.

    Enter the client processor's hostname or press RETURN to quit:  client1

    If you press the Return key, the utility returns to the DMU Main Menu. If you enter a host name that is not in the server's host database, the following message is displayed: 

    arp failed on hostname "client_name"

    In the above message, arp is the address resolution protocol. If you receive this message, check the server's host database, the /etc/hosts file, to determine the correct client name. If the client was never registered with a network naming service (such as BIND or NIS) or was never entered in the /etc/hosts file, exit the utility by pressing Ctrl/c and add the client to the /etc/hosts file.

    Note

    For the remaining examples, assume the Return key is pressed to accept the default response.

  6. After you enter the client name, you are prompted to enter the location of the client's root directory. If you specify a path other than the default, which is /clients/hostname, you must have already created the directories in that path. The path you specify must begin with /clients. If for example, you wanted to differentiate between client systems in different departments at your site, you could specify /clients/department_name/hostname as the location of root. The department_name directory must have already been created under the /clients directory for you to do this. Digital suggests a maximum of 25 characters in the total path name for the client's root directory.

    Enter the path to the client's root file system at the prompt:

    Enter the path to contain the root file system. 
    [/clients/client1]: 

  7. Next, the utility prompts you to enter the swap information for the client.

    Enter the swap device and partition on client1. [rz0b]: 
     
    Enter the swap device drive type for rz0b. [RZ26]: 

  8. The utility prompts you to enter some basic network information about the client. The dmu utility enters this information into the client's rc.config file to allow the client to boot over the network. You will be asked to enter the default route for network information if the server and client are on different networks. Refer to the Network Administration guide if you need more information about obtaining the client's network information:

    Enter the network interface for client1 (16.69.199.157) [ln0]:

     
    Enter the subnet mask for ln0. [255.255.255.0]: 

     
    Enter the default route for network 16.69.224 [16.69.144.199]:

    If no entry for the client's subnet is found in the /var/adm/dms/gateways file on the server the following message is displayed:

    Enter the IP address of the gateway[s] between the client  subnet and server subnet. (For example, 16.69.144.???). :

    If an entry for the client's subnet is found in the /var/adm/dms/gateways file on the server the following message is displayed:

    The following are the known gateway[s] between the client subnet  and server subnet. If these value[s] are not correct, please  enter the proper address[s]. If these value[s] are correct,  press Return. (For example, 16.69.144.???) [16.69.144.199]:

    Note

    The default is ln0, which is appropriate for the DEC 3000 series and other systems that use the Lance Ethernet module. Some systems such as the EB64+ use the Tulip Ethernet module, which is identified as, for example, tu0. Be sure to enter the correct network device identifier for the Ethernet or FDDI interface on the client system.

  9. The utility prompts you to enter the type of kernel build support you want to provide for the client. Refer to Section 10.6.2.1 for more information about kernel build support. If you are not sure what type of kernel build support you want, enter H for help. 

    Enter the type of kernel build area for client1.
You may select one of [F]ull, [P]artial, [N]one or
[H]elp for more information. [P]:

  10. The following message confirms the choices you made: 

    You have specified the following configuration for client1:

     
    
        ROOT:  /clients/client1
 SWAP_DEVICE:  /dev/rz0b
   SWAP_TYPE:  RZ26
  BUILD_TYPE:  Partial
   INTERFACE:  ln0 (16.69.244.32)
 SUBNET_MASK:  255.255.255.0
       ROUTE:  network: 16.69.224 gateway: 16.69.144.199
    Is this correct (y/n) [y]: 

    If you enter n, the utility returns to the DMU Main Menu and you will have to add your client information again. If you enter y, you are prompted to select the dataless environment to which you want to add the client. The directory /clients/client1 is overwritten if it currently exists.

  11. If there is only one /var/adm/dms/dmsn.alpha area, the following message is displayed: 

    The existing environment is /var/adm/dms/dms0.alpha.

     
    
The following environment will be installed from
/var/adm/dms/dms0.alpha:

     
    
Description
   1    'Digital UNIX 4.0 Operating System (Rev xxx)'

     
    
Is that correct? (y/n) [y]:

    If there are multiple /var/adm/dms/dmsn.alpha areas, or if more than one dmsn.alpha environment is installed in this DMS server area, a list of the environments into which you can add the new client is displayed. As shown in the following example, each environment may contain different software subsets or may have been customized which may influence the environment you choose. 

    Select the remote dataless environment:

     
    
 1)  /var/adm/dms/dms0.alpha
     'Digital UNIX 4.0 Operating System (Rev xxx)'

     
    
 2)  /var/adm/dms/dms1.alpha
     'Digital UNIX 4.0 Operating System (Rev xxx)'
     'DEC Pascal for DEC OSF/1 AXP Runtime Support'
     'DEC Fortran for OSF/1 AXP Runtime Support'
     'DEC Cobol RTL V2.2 for DEC OSF/1 Systems'
     'DEC C++ RTL Version 3.0 for DEC OSF/1 SYSTEMS'

     
    Enter your choice:  2 

    The following environment will be installed for the client
from /var/adm/dms/dms1.alpha:

     
    
Description
        'Digital UNIX 4.0 Operating System (Rev xxx)'
        'DEC Pascal for DEC OSF/1 AXP Runtime Support'
        'DEC Fortran for OSF/1 AXP Runtime Support'
        'DEC Cobol RTL V2.2 for DEC OSF/1 Systems'
        'DEC C++ RTL Version 3.0 for DEC OSF/1 SYSTEMS'

     

    Is that correct? (y/n) [y]:

  12. If you enter n, the utility returns to the DMU Main Menu and the client is not added to any DMS environment. If you enter y, you are prompted to enter the client's Ethernet or FDDI address:

    Enter the client processor's hardware network 
    address. For example, 08-00-2b-02-67-e1:  08-00-2b-30-68-96

    Refer to the Network Programmer's Guide or Section 6.2 for information about how to obtain a network hardware address. If you do not enter the hardware address in the correct format (for example, too many numbers), the utility displays an error message and repeats the prompt as shown in the following example: 

    08-2b-30-68-9696 is an invalid Ethernet or FDDI address.

    
Enter the client processor's hardware network address.
For example, 08-00-2b-02-67-e1:

    Note

    The utility does not check the validity of the address you enter; however, the utility does check to make sure the address you enter is in the correct format.

  13. After you enter a valid hardware network address, the utility checks to see is there is enough free space in /clients to create the root and var file systems for the client. The following message is displayed: 

    Checking file system space required for client
root and var file systems.

  14. If there is not enough free space available to create the file system the following message is displayed: 

    There is not enough free space in /clients
to create the root and var file systems
for client1. client1 has not been added.

    The DMU Main Menu is displayed.

  15. If there is enough space to create the root and var file systems, the dmu utility copies the DMS environment root area to the /clients/<clientname> area, creates the /var file system for the client, and displays the following message: 

    Creating the root and var file systems for client1

    
Client client1 has been added.

Notify the client's system administrator when client registration is complete, and inform them that they can now boot the client across the network. See Section 12.2 for basic information about booting a client. Detailed booting information is in the Installation Guide.

12.2    Booting a DMS Client

After a DMS client is added to the appropriate environment, the client's system administrator can boot the client over the network. When the client starts to boot, the kernel that boots over the network is: /clients/hostname/.vmunix

The following occurs when the client boots:

The network information you entered about the client when the client was added to the environment is sufficient to boot successfully across the LAN.

DMS clients must be able to boot over Ethernet or FDDI LAN. The basic procedure for booting a processor over the network from a Digital UNIX server is to shut down the client system to console mode and then issue a boot command from the client.

Refer to the Installation Guide for information about booting specific processors.

When the client boots, the client system administrator is prompted to enter a superuser password. The superuser password must contain between 6 and 16 characters and should use a combination of upper and lower case letters. Digital also suggests using special characters such as the dollar sign ($), percent sign (%), asterisk (*), and numbers in the password. The password is not displayed on the screen for security reasons. A second prompt asks for the new password again as validation. The screen display is similar to the following: 

*** SUPERUSER PASSWORD SPECIFICATION **

 

Changing password for root.

 

Enter root password:
Retype root password:

System information is displayed while the client system is coming up. When the Common Desktop Environment (CDE) login window or the login prompt appears, enter root as the login name. At the prompt for a password, enter the superuser password that was previously specified.

12.2.1    DMS Client Database File

The DMS client database file is located in /var/adm/dms/clients/dmsdb. An entry in this file is similar to the following: 

client1:08-00-2b-30-96-68:/var/adm/dms/dms0.alpha:/clients/client1:
rz0b:RZ26:None:ln0:255.255.255.0

In the previous example:

When you remove a client through the REMOVE a client option from the DMU Main Menu, the client's entry in the dmsdb file is erased.

12.3    Deleting a Software Environment

When you delete a software environment, the environment itself and all clients registered to that environment are deleted in a destructive manner. That is, once you confirm your choice, there is no opportunity to undo the deletion.

Caution

Make sure that the clients registered to the environment have been notified and shut down before you delete the environment. Failure to do so will cause a running client to lose its operating system.

To delete a software environment, use the following steps:

  1. Invoke the dmu utility by entering /usr/sbin/dmu at the root system prompt, and choose the DELETE software environments option by entering d at the prompt: 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT

    Enter your choice:  d

  2. The utility displays a list of the existing dataless environments and prompts you to choose the environment you want to delete: 

    Select the remote dataless environment:

     
    
 1)  /var/adm/dms/dms0.alpha
       'Digital UNIX V4.0 Operating System (Rev xxx)'

     
    
 2)  /var/adm/dms/dms1.alpha
       'Digital UNIX V4.0 Operating System (Rev xxx)'
       'Sort Runtime Library'

     
    
 3)  /var/adm/dms/dms2.alpha
       'Digital UNIX V4.0 Operating System (Rev xxx)'
       'System V Environment'

     
    Enter your choice:  1

  3. After you select the dataless environment to delete, a confirmation displays your choice: 

    The following environment will be deleted from
/var/adm/dms/dms0.alpha:

     
    
Description
   'Digital UNIX 4.0 Operating System (Rev xxx)'

     
    
Is that correct? (y/n) [y]:

    If you enter n, the utility returns to the DMU Main Menu. If you enter y, the following message displays: 

    After this deletion, the area /var/adm/dms/dms0.alpha will
be empty.  The following clients are registered for
/var/adm/dms/dms0.alpha:
client1 client2 client3

    
This procedure will completely remove /var/adm/dms/dms0.alpha.
Do you want to continue? (y/n) [n]:

    If you enter n or press the Return key (to accept the default), the utility returns to the DMU Main Menu and does not delete the environment or the clients registered to it. If you enter y, the utility deletes the DMS environment and all the clients registered to that environment and displays the following message: 

    Do you want to remove the client's root file system
[/clients/client1]? (y/n) [n]:

    The utility prompts you to answer whether or not you want to remove the root and var file systems for each client registered to the environment. This is your opportunity to save customized data in the root directory. If you enter n, all customized data in root will be lost.

After the deletion is complete, the utility returns to the DMU Main Menu.

12.4    Modifying Client Information

The dmu utility lets you modify the network hardware address of a client. Refer to the Network Programmer's Guide or Section 6.2 in this manual for instructions about how to obtain the hardware address of a client.

To modify a client's information perform the following procedure:

  1. To modify a client's hardware address, invoke the dmu utility (by entering /usr/sbin/dmu at the root system prompt), and choose the MODIFY a client option by entering m at the prompt: 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT

     
    Enter your choice:  m

  2. The dmu utility displays a list of the registered clients. It does not display the DMS environment to which the client is registered. 

    The following clients are available to modify:

     
    
client4 client5 client6

     
    Enter the client processor's hostname or press RETURN to quit:  client4

    If you do not enter a client name and press the Return key, the utility returns to the DMU Main Menu.

  3. If you enter a valid client name, you are prompted to enter the client's new Ethernet or FDDI address. The client's current hardware address is the default response.

    Note

    The utility does not check the validity of the address you enter; however, the utility does check to make sure the address you enter is in the correct format.

    Enter the client processor's hardware network address.  For example, 08-00-2b-02-67-e1 [08-00-2b-30-68-96]:
    08-03-3c-01-55-44
     
    Client client4 has been modified.

    If you press the Return key instead of entering a new Ethernet or FDDI address, the address will not change. When the modification is complete, the utility returns to the DMU Main Menu.

Caution

If you want to change the client's IP address or the environment to which the client is registered, you must first shut down the client, (by using the shutdown command) and then remove the client from the current environment (by choosing REMOVE a client from the DMU Main Menu). Then, add the client to another environment (by choosing ADD a client from the DMU Main Menu).

12.5    Removing a Client

You must make sure the client has been shut down (using the shutdown command) before it is removed from an environment. A client will lose its operating system if it is removed while it is up and running. Follow these steps to remove (delete) a client from a DMS environment:

  1. Invoke dmu by entering /usr/sbin/dmu at the root system prompt and choose the REMOVE a client option by entering r at the prompt. You may want to execute the LIST registered clients option first to determine the exact client processor host name. 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT

     
    Enter your choice:  r

  2. A message appears that confirms that you have chosen to remove a client processor. You are prompted to enter the client processor's host name and then to confirm the removal of the client (the default confirmation is no). 

    You have chosen to remove a client from the remote
dataless service.

    Enter the client processor's hostname or press RETURN to quit:  client5

    If you press the Return key, the utility returns to the DMU Main Menu. If you enter a client name that is not in the DMS client database, /var/adm/dms/clients/dmsdb, the following message is displayed: 

    There is no entry for client_name in the dmsdb file.

    If you enter a valid client name, the following prompt displays:

    Remove client5? (y/n) [n]:

Note

If you remove a client but choose to save the root file system, you cannot reuse that root file system if you subsequently add a client with the same client name.

When client removal is complete, the utility returns to the DMU Main Menu.

12.6    Listing DMS Clients

Choose the List Registered Clients option on the DMU Main Menu to see a list of the clients registered in all dataless environments:

  1. Invoke the dmu utility by entering /usr/sbin/dmu at the root system prompt and choose the LIST registered clients option from the menu by entering l at the prompt: 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT

     

    Enter your choice:  l 

    The following clients are registered for /var/adm/dms/dms0.alpha:

    
client1 client2 client3

    
The following clients are registered for /var/adm/dms/dms1.alpha:

    
client4 client5 client6

    
The following clients are registered for /var/adm/dms/dms2.alpha:

    
client7 client8 client9

12.7    Showing Software Environments

The dmu utility lets you display a list of the current DMS environments:

  1. Invoke the dmu utility by entering /usr/sbin/dmu at the root system prompt and choose the SHOW software environments option from the menu by entering s at the prompt: 

    *** DMU Main Menu ***

     
    
    a) ADD a client
    c) CONFIGURE software environments
    d) DELETE software environments
    i) INSTALL software environments
    l) LIST registered clients
    m) MODIFY a client
    r) REMOVE a client
    s) SHOW software environments
    x) EXIT

     
    Enter your choice:  s

  2. Your screen display will look similar to the following (depending upon the software subsets installed in each DMS environment): 

    1)  /var/adm/dms/dms0.alpha
    'Digital UNIX 4.0 Operating System (Rev xxx)'

     
    
2)  /var/adm/dms/dms1.alpha
    'Digital UNIX 4.0 Operating System (Rev xxx)'
    'System V Environment '

     
    
3)  /var/adm/dms/dms2.alpha
    'Digital UNIX 4.0 Operating System (Rev xxx)'
    'Sort Runtime Support'

After displaying the list of DMS environments, the utility returns to the DMU Main Menu.

Note

Only the Digital UNIX product name is displayed by the Show command of the /usr/sbin/dmu utility. To determine if a hardware release is installed in a DMS environment, use the setld command. For example, the following command produces a list of the subsets installed into the client root area of /var/adm/dms/dms0.alpha:

#  setld -D /var/adm/dms/dms0.alpha/root -i

Refer to setld(8) for more information or enter the following command to display the reference page on your screen (if the Digital UNIX reference page software subsets have been installed on your system):

#  man setld

12.8    Maintaining the DMS Environment

This section contains information about maintaining the DMU server area.

12.8.1    Controlling Root File System Growth

The du command displays a summary of disk usage for file systems. Use this command to monitor the file growth in each client's root directory. If clients use too much space, performance is adversely affected. Users must then be told to delete all unnecessary files from their file systems. Monitor disk usage periodically depending upon the systems' use. Refer to du(1) for more information about monitoring file system growth.

The df command displays statistics about the amount of free space on a specified file system or on a file system that contains a specified file. Refer to df(1) for more information about monitoring file system growth.

12.8.2    Listing Installed Software Subsets

Use the setld utility to determine which software subsets are installed into a particular dmsn.alpha area. For example, the following command produces a list of the subsets installed into the client root area of /var/adm/dms/dms0.alpha:

#  setld -D /var/adm/dms/dms0.alpha/root -i

Refer to setld(8) for more information or enter the following command to display the reference page on your screen (if the Digital UNIX reference page software subsets are installed on your system):

#  man setld

12.8.3    Removing Subsets

Use the setld utility to remove software subsets from a dmsn.alpha area. For example, if you installed the Online Reference Pages subset, OSFMAN400, and now want to remove it, use a command similar to the following:

#  setld -D /var/adm/dms/dms0.alpha/root -d OSFMAN400

This command removes the subset from /var/adm/dms/dms0.alpha. The Installation Guide contains a list of all software subsets.

Caution

During the installation if setld placed files in root, the product may not be fully removed from the client's root file system. Additionally, you should be careful about removing any subset that might be in use by client systems. For example, if you remove a subset that contains kernel build files, the clients may not be able to build new kernels. If you remove a subset that contains NFS components, the clients may not be able to reboot. It is important to understand exactly what dependencies clients have on a software component before you remove it. You may not be able to reload a subset to resolve client operational problems without first removing all of the clients and then reregistering them.

12.9    Applying Binary Patches to the Kernel in a DMS Environment

This section describes how to apply binary patches to the kernel in a DMS environment without deregistering and reregistering all of the client systems or reinstalling the DMS environment.

Binary patches to the Digital UNIX operating system are often issued to address problems in the kernel or layered products.

When a binary patch affects only files in the /usr file system or other file systems that are mounted read-only by the DMS clients, simply copy the files into the shared /usr file system on the server. The usual cautions that apply to changing the /usr file system in a multi-user environment apply to the DMS environment for instance, replacing a shared library has the same potential impact.

When the binary patch changes object modules (or source files) in the /sys area in /usr/sys on a stand-alone system, the situation is more complicated in the DMS environment. This is due to the way the client's /sys area is set up, which differs depending on how the client builds kernels.

The following sections assume that all the client root file systems are NFS mounted from the server.

12.9.1    Installing a Binary Patch

Ensure that you have the appropriate binary patch for the version of Digital UNIX that is installed in the DMS area. If you install an incorrect version of the patch, you may create a kernel that will not work on the client systems, or you may create a kernel that causes data corruption. To obtain the exact version names, use the following command:

#  grep -h "^NAME=" /usr/var/adm/dms/dms0.alpha/root/usr/.smdb./OSFBASE* 


 

	NAME='Digital UNIX Operating System 4.0 ( Rev xxx)'
	NAME='Digital UNIX Operating System Hardware Update Release'

In this example, the dms0.alpha area contains both the Digital UNIX Operating System Version 4.0 ( Rev xxx) base release and the hardware update release. Repeat the previous step for each area until you find the one which has the correct version of the hardware update release installed.

Follow the instructions in the patch kit to install the patch in the server's DMS area.

To install the patch into the dms0.alpha area in the BINARY directory where most kernel .o object files are located, enter the following command:

#  cd /usr/var/adm/dms/dms0.alpha/root/usr/sys/BINARY

Use the ls command to verify that the object file present in the sys/BINARY directory is the one you want to replace. Make a copy of the file under another name. If you are going to replace the file if_tu.o, copy it to if_tu.o-bak or if_tu.o-old. Later, if there is a problem with the patch, you can restore the original file. After you verify the files to replace and make backup copies, put the replacement files into the directory. You are ready to build a new DATALESS kernel.

To assure that your new DATALESS kernel picks up the patched modules, remove the old DATALESS kernel build area from your server by entering the following commands:

#  cd /usr/var/adm/dms/dms0.alpha/root/usr/sys
#  rm -rf DATALESS

You do not need to keep the old DATALESS directory because its contents will be completely replaced when you run doconfig to build a new kernel. Use the -n flag or doconfig will not create a .vmunix, which is used to boot the client using the bootp protocol. However, removing the directory assures that you will get the correct files for building the new kernel.

12.9.2    Configuring the Clients

The following sections describe how to update the client area based on the client's build type.

12.9.2.1    Updating a Client Whose BUILD_TYPE Is None:

If the client's kernel build type is NONE you must copy the DATALESS kernel to the client's root area. To copy the new vmunix and the network-bootable .vmunix to the client's root, enter the following commands:

#  cd $DMSROOT/root
#  ROOT_PATH=/clients/ client_name
#  export ROOT_PATH
#  cp usr/sys/DATALESS/vmunix $ROOT_PATH
#  cp usr/sys/DATALESS/.vmunix $ROOT_PATH

When you reboot the client, the client will use the new generic .vmunix with the binary patch installed.

12.9.2.2    Updating a Client Whose BUILD_TYPE Is Partial

When a client is configured to do Partial kernel builds, the client receives a copy of the DMS area's root/usr/sys directory with the exception of the /usr/sys/BINARY and /usr/sys/include directories. The client's /sys has a symbolic link to the read-only /usr/sys/BINARY and /usr/sys/include in the server's DMS area.

If the replacement file or files from the patch kit all reside in either the /usr/sys/BINARY or /usr/sys/include directories in the server's DMS area, rebuild the kernel on the client system and reboot.

If the replacement file or files reside in another part of the /usr/sys directory, copy them to the corresponding place in the client's sys directory hierarchy.

Next, the doconfig command must be run on the client. Use the -n flag or doconfig will not create a .vmunix, which is used to boot the client using the bootp protocol.

12.9.2.3    Updating a Client Whose BUILD_TYPE Is Full

When a client is configured to do full kernel builds, it receives a full copy of the /root/usr/sys directory hierarchy.

In this case, you must first install all the patch files that you have put in the server's DMS area in the /usr/sys hierarchy into the corresponding places in the client's sys area. For instance, if you installed the module if_tu.o into /usr/sys/BINARY in the server's DMS area, you need to also install it in /clients/ client_name /sys/BINARY.

Because clients that are configured to do full kernel builds may have already modified some kernel objects, be sure to verify that the module you are replacing is the same module you replaced in the DMS area on the server.

Next, run the doconfig command on the client. Be sure to use the -n flag or doconfig will not create a .vmunix, which is used to boot the client via bootp protocol.

Be sure that the client's build area does not contain files that are customized for the client's particular environment.

12.9.3    Booting Client Systems with the New Kernel

After you have installed the new kernel in the client's root area, reboot the client system for the kernel changes to take effect.

12.9.3.1    Recovering from Failures During the Boot

If the client system cannot reboot, you can usually recover by copying the generic network-bootable .vmunix from the DMS area's root area to the client's private root area.

Doing this should let the client boot. You still need to determine why the new kernel was not bootable.