Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
 Contact HP
HP.com home
HP Tru64 UNIX Version 5.1B-2 and Higher: Patch Kit Installation Instructions > Chapter 4 Patching a Cluster

No-Roll Patching


Table of Contents
Content starts here

The no-roll patch process lets you install patches on a cluster without performing a rolling upgrade. This chapter provides the following information:


The no-roll technology is included in Rev. 34–00 and higher of the dupatch utility. You can find the revision number on the first output line you see when you run dupatch (see the example in “Steps for Running a No-Roll Procedure”). The first kit that includes this technology was issued in April 2002.


A rolling upgrade lets you perform a software upgrade on a cluster while maintaining high availability of the cluster. To provide this high availability, a certain amount of setup work is required to build tagged files and to reboot the cluster members to use the tagged files. This can take a considerable amount of time.

However, if you have a mission-critical environment and want to use a patch method that applies patches quickly, minimizes down time of the cluster, and reduces the number of reboots required, you might want to use the no-roll patch process. This process patches your cluster in one operation that requires only one or two reboots of the whole cluster to complete the operation. You will need the second reboot only if you install a patch that contains a version switch (see “Throwing the Version Switch”).

The no-roll patch process is a modification of dupatch; that is, all patches are installed or removed entirely using the dupatch utility, as opposed to the clu_upgrade and dupatch utilities used in the rolling upgrade procedure. The no-roll process conducts significantly fewer operations than the rolling upgrade procedure.

While a no-roll patch installation is in progress, no other critical operations should be running on the cluster because the cluster will change state and reboot automatically at various stages of the procedure.

In addition, the no-roll patch procedure employs the use of the Tru64 UNIX Event Management System (EVM) to send cluster-wide events. As a result, patches must be applied to the system in multi-user mode. If you attempt to use the no-roll procedure while in single-user mode, you will be advised to change the cluster to multi-user mode before continuing.

Steps for Running a No-Roll Procedure

The following steps describe how to patch your cluster using the no-roll procedure.


To use the no-roll patch method, you must not use the clu_upgrade utility to prepare the cluster, as you would for a rolling upgrade prior to running dupatch. If a rolling upgrade is in progress before attempting to run dupatch, then the no-roll option will not be available until the cluster is restored to the state prior to the roll attempt.

  1. With your system running in multi-user mode, enter the dupatch command:

    # dupatch
    Tru64 UNIX Patch Utility (Rev. 48-00)
    This dupatch session is logged in /var/adm/patch/log/session.log
        Main Menu:
        1)  Patch Kit Installation
        2)  Patch Kit Deletion
        3)  Patch Kit Documentation
        4)  Patch Tracking
        5)  Patch Baseline Analysis/Adjustment
        h)  Help on Command Line Interface
        q)  Quit
    Enter your choice:

  2. From the main menu select the patch installation or patch deletion option. (See “Installing Patches from Multi-User Mode”.)

  3. If dupatch determines it is running on a cluster that has not been prepared to do a rolling patch, it asks if you want to do the patch operation without rolling. You will see a message similar to the following:

    Checking Cluster State...done 
    This system is part of a cluster which has not been prepared to do a 
    rolling patch installation or deletion. Do you wish to perform this 
    patch operation cluster-wide without using the rolling-patch mechanism?
    Please answer y or n ? [y/n]:

    If you choose y, dupatch proceeds by allowing you to do the analysis and selection of patches to be installed or removed, after which the whole cluster is brought down to init level 2 via an Event Management System event.

    If you are using dupatch from the command line and do not specify the -proceed option, you will need to press Return in order to transition the cluster from level 3 to level 2. If the -proceed option was set, the transition will occur automatically.

After dupatch completes its patch analysis, it will perform the patch operation on the member on which you ran dupatch. After the patches are installed or removed, dupatch will issue a second event to the remaining cluster members that will instruct them to complete their patch operations in parallel.

The dupatch utility then waits a calculated time-out period for all the other cluster members to complete their operations. The time-out period is based on the time it took to perform the patch operation on the member running dupatch.

After the patch operation is completed on all other cluster members, dupatch will complete the procedure on the member on which the dupatch command was issued.

If a cluster member times out or encounters an error, dupatch will report the problem, suspend the process, and send you a message to check the problematic member in order to resolve the problem. Once dupatch has resumed, it will complete the patch process on the rest of the cluster.

If a cluster member is known to be down when you issue the dupatch command, an /sbin/it job will be posted for the member to run the cluster patch script upon reboot. (For more information, see the it(8) reference page.)

Because all patches currently require a reboot, the whole cluster will reboot after all the members report back.

Throwing the Version Switch

If a patch applied to the system requires the use of a version switch, you will see a message similar to the following at the end of the dupatch session:

   Patch OSFPAT00074200510 has been
   identified as needing a version switch. Once the following reboot is
   complete, please enter the "/var/adm/patch/noroll/noroll_versw"
   command from any cluster member.

As indicated by the message, you must enter the /var/adm/patch/noroll/noroll_versw command from any cluster member. This is a manual operation that you must perform after the reboot is complete. All cluster members must be up prior to running the noroll_versw command. If they are not, the noroll_versw command will fail and the version switch will not take place.

After issuing the noroll_versw command, reboot your system to ensure system integrity.

Removing Patches

You cannot use the no-roll process to remove inclusive patch kits because you must run the versw_enable_delete script (“Run Mandatory Script Before Removing New Style Patch Kits”), which requires that you reboot each cluster member to remove the patch kit. Because the no-roll process automatically reboots the system after deleting the patches, you would not be able to reboot each member as required.

Printable version
Privacy statement Using this site means you accept its terms
2006 Hewlett-Packard Development Company, L.P.