Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Ignite-UX Administration Guide: for HP-UX 11i > Chapter 15 Recovery Methods

System Recovery


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Ignite-UX system recovery allows quick recovery from a failed disk. The failure can be either a hardware failure or a catastrophic software failure.

This section assumes you are creating a recovery image to be stored on the Ignite-UX server via the network, or on tape. If you wish to create recovery image media, see Chapter 14

System recovery requires some work before a problem occurs. On a regular basis, you need to run the appropriate tool on each of your systems: make_net_recovery or make_tape_recovery. Use the make_net_recovery command to create a recovery image on another system, or the make_tape_recovery to create a recovery image on tape.

The make_tape_recovery and make_net_recovery commands each create a bootable, installation recovery image that is customized for your machine. Recovery images contain your system’s configuration information (disk layout, etc.) and files from one or more disks. You can exert some control over which files are saved as part of the image - see “Recovery Image Contents” for more information.

The make_net_recovery command and the make_tape_recovery command are collectively referred to as: make_[tape|net]_recovery.

You can use the make_[tape|net]_recovery commands on a command line, the Ignite-UX GUI from the server, or the Ignite-UX TUI from the client to create a recovery image.

Once you have a recovery image on tape or Ignite-UX server, recovering a failed system is easy:

  1. If a disk failed, replace it.

  2. Boot from your recovery tape or system.

  3. Wait for the recovery to complete.

  4. Once the system comes back up, verify the system configuration and recover the latest copies of files from the last system backup. Ensure that you do not recover operating system files as this can create unexpected results.

If you have SAS devices connected to the recovery client, be aware that as of Ignite version C.7.5, Ignite will recover to the original disk based on WWID, even if it has been moved. However, moving SAS devices can result in a changed device file name. For more information, see the Ignite-UX and SAS Devices white paper, available at http://www.docs.hp.com/en/IUX/infolib.html.

IMPORTANT: The offline diagnostic environment (ODE) command copyutil is a diagnostic tool for HP-UX 11i and should not be used for system recovery. Instead, use make_[tape|net]_recovery.During HP-UX 11i v3 installation and recovery, connected Active/Passive devices will cause long delays (one hour or more) or may cause a system to hang. Similarly, connecting an Active/Passive device before installing the Active/Passive Switch (APSW) plug-in can cause some commands to take a long time. Disconnect any Active/Passive devices connected to your system before installing or recovering HP-UX 11i v3. After installation or recovery, it is important that the APSW plug-in be installed before connecting an Active/Passive device to the system.

System Recovery Tools

The make_[tape|net]_recovery tools have few differences aside from using different media. Both system recovery tools share the same basic recovery image creation options, data structures, recovery image file content, and installation dialog boxes. The main differences are that make_tape_recovery does not require an Ignite server and make_net_recovery can be run from the client with a small subset of the Ignite product.

The make_[tape|net]_recovery tools are not intended for backup of all your system data. Use a restore tool such as fbackup in conjunction with your recovery image. See fbackup(1M ) for more information.

Recovery Tool Comparison

To determine which system recovery tool is best suited for your needs, consider the following:

Use make_tape_recovery to:
  • Manage single or a limited number of systems locally.

  • Manage systems that are not networked.

  • Create tape media for an off-site recovery system.

  • Create recovery images for clients on a different subnet than the Ignite-UX server without using a boot helper system.

Use make_net_recovery to:
  • Centrally manage networked systems.

  • Avoid tape issues (handling, multi-tape images, etc.)

  • Use disk space for image storage.

  • Perform unattended creation of recovery images without tape handling.

  • Create recovery images for clients on a different subnet than the Ignite-UX server without using a boot helper system. (A boot helper system or a similar solution must be used when installing a recovery image across subnets.)

The following table summarizes and compares some of the features of the make_[tape|net]_recovery tools:

Table 15-1 Comparing System Recovery Tool Features

Minimum hardware configuration
  • Two networked systems

  • Sufficient disk space to hold image

Creation interfaces
  • Client command line

  • Ignite-UX server GUI

  • Client TUI

  • Client command line

  • Ignite-UX server GUI

  • Client TUI

Recovery image personality
  • Self contained

  • Written to the client’s tape drive

  • Requires an Ignite-UX server to install

  • Written to NFS mounted file system


Considerations When Using Veritas Volume Manager from Symantec

If you intend to use or are using VxVM, consider the following issues that impact the make_[tape|net]_recovery tools:

  • Ignite-UX only supports cold installing Symantec products that are in an OE depot as shipped by HP.

  • HP only supports an environment where the versions of VxFS and VxVM match. For example, if you install VxFS 4.1, you must also install VxVM 4.1.

  • Systems with mixed versions of VxVM disk groups are recovered with all disk groups specified in the recovery image converted to the higher VxVM version. For example, when your recovery image contains both VxVM 3.5 and 4.1 disk groups, all disk groups are created as VxVM 4.1 disk groups.

  • If your system has different versions of VxFS and VxVM, such as VxFS 4.1 and VxVM 3.5, you will still have mixed versions after the system is recovered.

  • Before an installation is allowed to proceed, Ignite-UX verifies that the correct version of VxVM is being installed, if the installation is coming from an SD depot. If the installation is coming from a recovery image or golden image, Ignite-UX will log a note stating it is assumed the correct version is included in the image. For example, if your disk layout is VxVM 4.1, your image must contain the VxVM 4.1 software.

Recovery Image Contents

The make_[tape|net]_recovery commands enable you to view and control recovery image contents.

  • Ignite-UX creates a symbolic link between directories named after the client’s name and its MAC address. For example, if you had a system with a client name of "longs_peak" and a MAC address of "0x00306E4C9B54", the directories /var/opt/ignite/clients/0x00306E4C9B54 and /var/opt/ignite/clients/longs_peak would be symbolically linked. This chapter uses the client name to reference the directory, but either will work.

  • The list of essential files to be included in the recovery image is available as a simple text file: /opt/ignite/recovery/mnr_essentials. This file allows you to see what files and directories are included in the recovery image by default.

  • You can specify what additional volume groups, directories, and files you want included, and what directories and files you want excluded. This is done using simple syntax in the client-specific content file, /var/opt/ignite/clients/client/recovery/archive_content, or by using command line options. You are not restricted to one or two volume groups. You can create a complete multivolume group recovery image.

  • You can use the user interface (launched with the -ioption to make_[tape|net]_recovery) to find out which volume groups and/or disks will be untouched, which will be partially restored, and which will be restored in full if the recovery image is used, based on the specifications in the mnr_essentials file and the archive_content file.

  • You can also use the user interface to edit the archive_content file and dynamically see the changes in the volume groups and disks that are affected.

  • The policies for user-specified content are documented in the Recovery Image Configuration Policies section below.

The make_tape_recovery tool creates a bootable tape that can be used to restore a system using the system’s tape drive. Remember that make_tape_recovery is subject to the requirements and limitations inherent with tape media:

  • A tape drive must be available on each system to be archived.

  • If you want to save previous recovery images, remove the tapes containing the existing recovery images from the tape drives before creating new ones.

  • If a recovery image exceeds the capacity of a tape, you need to swap tapes for both creation and extraction.

  • If you want to make sure that the newly created tapes are good, you must check the log files on the system.

  • Tape drives are more error prone than a local network.

Recovery Image Configuration Policies

When specifying recovery image content for make_[tape|net]_recovery, the following rules apply:

  • No essential file or directory can be excluded.

  • Files and directories inside an included directory will be included recursively.

  • If an essential file or directory exists outside the root disk or volume group, the disk or volume group it resides in is included in the recovery image. If you want to include all the files within that disk or volume group in the recovery image, use the make_[tape|net]_recovery -A or -x options.

  • If a symbolic link to a file or directory is included, only the link will be included in the recovery image. The actual file or directory is not included unless it is specified or the symbolic link is essential. A warning will be given when an item is only a symbolic link.

  • If a directory is included that contains symbolic links to other files or directories, the symbolic links will be included but not the referenced files or directories, unless they too are included. No warnings are given regarding these links.

  • If a directory contains local mount points, the files and directories under the local mount points are not included, by default. This policy can be waived by specifying the option inc_cross (include directories and cross-mount points) in the selection interface or command line.

  • In case of conflicting entries in the selections, exclusions take precedence over inclusions.

  • File system volume size must provide 10 percent free space for each volume - Ignite-UX automatically modifies the file system volume size accordingly. For more information, see the description of the _hp_addnl_fs_free_pct variable in instl_adm(4).

Reconciling Client and Server Ignite-UX Versions for Recovery

If you initiate a recovery from the server GUI and the client system has a lower version of Ignite-UX than the server does, Ignite uses swinstall to update the existing Ignite-UX software on the client. If the client system does not have Ignite installed, a small subset of Ignite-UX software will be installed. (The small subset of Ignite-UX software is not a full Ignite-UX server installation, and does not provide Ignite-UX server capability to the client.)

If you initiate a recovery from the client with make_tape_recovery -s or make_net_recovery -s, and the client system has a lower version of Ignite-UX than the server does, behavior depends on the degree of version mismatch. If the version letters don't match, such as C.x.x and B.x.x, Ignite will display an error and the process will stop. If the version numbers do not match, Ignite will display a warning and the process will continue.

In any case, if the server has a lower version of Ignite-UX than the client, a message to this effect will be displayed and the process will stop.

As of Ignite version C.7.7, make_[tape|net]_recovery has a -u option that will update the client Ignite software to the version on the server specified by the -s option. For more information, see make_net_recovery(1M) or make_tape_recovery(1M).

Recovery Image Creation Process

The process of creating a recovery image using Ignite-UX is described as follows:

  1. Prepare the client.

    The make_net_recovery command and the make_tape_recovery -s command first check that the recovery tools installed on the client are compatible with the version on the Ignite-UX server as described in “Reconciling Client and Server Ignite-UX Versions for Recovery”.

  2. Create files and directories for the recovery image.

    The make_net_recovery and make_tape_recovery -s commands create a new directory for the client on the server in /var/opt/ignite/clients if needed. For make_tape_recovery run on the client without the -s option, the config files and log files are created in the /var/opt/ignite/recovery directory on the client.

    The commands generate a timestamp for naming the recovery archive, the configuration, and the configuration directory. The directory containing the configuration files for the recovery image is similar to the following:


    The corresponding recovery archive is named 2005-03-17,11:19 , and is in the /var/opt/ignite/recovery/archives/client directory.

    The timestamp is important for coordinating configuration files and recovery archives, and for ongoing recovery image management.

    An overview of the files is as follows:

    /var/opt/ignite/clients/client CINDEX client_name client_status config.sys host.info hw.info install.log recovery/ client_status defaults latest -> 2005-03-17,11:19 2005-03-17,11:19/ archive_content system_cfg archive_cfg control_cfg recovery.log flist manifest

    The archive_content file contains keyword and volume/disk/directory pairs that are used to generate the flist file, which defines the contents of the recovery image. See make_net_recovery(1M) and make_tape_recovery(1M) for more information on inclusion and exclusion of files in the recovery image.

  3. Run the recovery interface.

    If the -i option is specified on the command line, the recovery user interface is executed next. This interface enables users to set or change the following default values for the image:

    • Long description of the recovery image. This description adds identifying information that can help distinguish between recovery images when the timestamp is not sufficient. This information is shown by clicking Description on the Basic tab during installation configuration.

    • Maximum number of recovery images to keep. When the number of recovery images in the destination directory reaches this maximum, make_[tape|net]_recovery removes the oldest one. It uses the timestamp in the name to determine which to remove.

    • Destination host for the recovery image.

    • Destination directory for the recovery image.

      The user interface also gives you the opportunity to review and edit the archive_content file as mentioned in the previous step. When you exit the recovery user interface, the default values you entered are written to:


      The list of files included in the recovery image is written to archive_content in the /var/opt/ignite/clients/client/recovery directory.

  4. Save the system configuration.

    For all disk and volume groups, even those not included in the recovery image, make_[tape|net]_recovery backs up disk and volume group configuration information, and then stores it in the system_cfg file. For LVM, it also obtains map files for volume groups that are not part of the recovery image. The volume group configuration files and the map files generated at this stage are stored in /etc/lvmconf. This directory is included in the list of essential files, so the LVM files are included in the recovery image. For VxVM, commands are included in control_cfg that restore disk groups.

    After the volume group information is saved, make_[tape|net]_recovery creates the control_cfg file. This file includes the post_config_cmds to import all volume or disk groups that were not included in the recovery image, and to activate all volume groups that were imported. It also includes control flags, such as recovery_mode=true, to guide the behavior of Ignite-UX during recovery.

  5. Build the recovery archive.

    Next, make_[tape|net]_recovery calls make_sys_image to create the recovery archive. Then make_sys_image passes a prebuilt flist to calculate the total disk space currently used by all the files to be included in the archive. It uses this information with a compression ratio to estimate the final size of the archive. If the destination directory has sufficient free disk space for the archive, make_sys_image creates the archive using the pax command. For more information, see pax(1) and make_sys_image(1M).

  6. Prepare the configuration file.

    Once the recovery archive is created, make_[tape|net]_recovery calls make_arch_config to create the archive_cfg file to reference it. Then make_arch_config uses archive_impact to calculate the file system impacts for the recovery archive, and includes these in the sw_sel clause it writes.

  7. Update the CINDEX file.

    Lastly, make_[tape|net]_recovery uses manage_index to update the /var/opt/ignite/clients/client/CINDEX file for the client. This file contains a list of all the recovery configurations available for the client. The configuration clause for the most recently created recovery archive is similar to the following excerpt:

    cfg "2005-03-17,11:19 Recovery Archive" { description "Recovery Archive" "recovery/2005-03-17,11:19/system_cfg" "recovery/2005-03-17,11:19/control_cfg" "recovery/2005-03-17,11:19/archive_cfg" }=TRUE

Recovery Image Creation Status

You can monitor the status of the recovery image creation process by right-clicking on the client icon or clicking the Actions menu, then selecting Client Status.... The resulting dialog box details the progress as the recovery image is created with make_net_recovery as shown in Figure 15-1.

Figure 15-1 Get Archive Build Status Dialog Box

Get Archive Build Status Dialog Box

Examining Recovery Image Contents

The commands make_[tape|net]_recovery call /opt/ignite/lbin/list_expander as part of the process of determining what to include in a recovery image. You can use the list_expander command independently to determine for yourself what will be in the recovery image.

To list the files and directories included in a recovery image, use the list_expander command in the following way:

/opt/ignite/lbin/list_expander -f archive_content

where archive_content is the file that identifies keywords specifying inclusions and exclusions for the recovery image. It is the same archive_content file discussed in the "Recovery Image Creation Process" section above.

NOTE: The /var/opt/ignite/clients/client/recovery/archive_content file is overwritten whether a recovery image is successfully produced or not. Be sure the archive_content file matches the recovery image you are exploring.

Running list_expander without specifying -f archive_content causes a list of the essential recovery image files and directories to be listed.

You can also use list_expander to list disks and volume groups included in a recovery image by using the -d option:

/opt/ignite/lbin/list_expander -d -f archive_content

Omitting the -f archive_content will cause the essential list to be displayed.

The following is example list_expander -d output:

In? dsk/vg name minor# Associated disks 0 d /dev/dsk/c0t3d0 1 v /dev/vg00 0x00 /dev/dsk/c0t6d0 /dev/dsk/c0t4d0 0 v /dev/vg01 0x01 /dev/dsk/c0t1d0 0 v /dev/vg02 0x02 /dev/dsk/c0t2d0

The In? column shows, for each disk or volume group, if it will be:

2 = included in full (inc_entire specifies entire disk/volume group), or 1 = included in part (some files are included, some not), or 0 = not included at all (no files from this disk/volume group are included.)

The 0 means the disk or volume group will not be touched. The 1 or 2 means that the disk or volume group will be recreated and files from the recovery image will be restored during a recovery operation.

The dsk/vg column shows that the system has one whole disk (d) and three volume groups (v). The next column gives the names of the disks and volume groups.

NOTE: The following circumstance may cause list_expander to halt:

When processing information, list_expander uses the libc function ftw, see ftw(3C), to recursively descend the directory hierarchy.

When ftw encounters a directory containing a large number of files, all of the descendent files are processed recursively. This can cause stack size problems. For example, if the directory contained 400,000 files, the stack size must be at least 51.2 MB to support the number of recursive function calls (400,000 calls x 128 bytes/stack frame), since each ftw call allocates a stack frame of 128 bytes. In this case it is wise to allocate additional space - 64 MB is a better stack size choice.

If the stack size is not large enough, list_expander is killed due to a stack growth failure. To avoid this situation, you should configure the kernel tunable maxssiz accordingly. See the kctune(1M) manpage for more information on tuning kernel parameters.

The above information is based on the HP-UX 11i v1 ftw() libc function. The behavior of ftw() between releases or patch versions of HP-UX may change. Consider this information indicative of the potential setting required; it should not be considered authoritative.

The file system volume sizes in the recovery image can be modified when the recovery image is installed. By default, Ignite-UX ensures that there is 10 percent free space for each volume, and modifies the file system volume size accordingly. If you do not want Ignite-UX to modify the file system volume sizes automatically, add

init _hp_ignore_sw_impact=1

to your /var/opt/ignite/recovery/latest/system_cfg file, or to the /var/opt/ignite/clients/client/recovery/latest/system_cfg file.

Verifying Recovery Image Results

During a system recovery, Ignite-UX by default restores the system to the state it was in when the recovery image was created. Ignite-UX is a general-purpose installation tool. It modifies many system configuration files if changes from the recovery configuration are required, such as increasing volume sizes.

When you run make_[tape|net]_recovery, system configuration information is gathered and saved in configuration files that are used later when the system is recovered. During the system recovery you are allowed to make changes to this information, and Ignite-UX makes the appropriate changes to the system configuration. If you do not make any changes, Ignite-UX simply reapplies the same information, and there should be no change to the system after recovery.

Most of the system configuration files that Ignite-UX will modify are listed in the script, /opt/ignite/data/scripts/os_arch_post_l. The os_arch_post_l script checks for the system recovery case by checking the $RECOVERY_MODE variable. When this variable is TRUE, the os_arch_post_l script causes some configuration files to be protected from modification by using the "save_file" function. The os_arch_post_l script uses the "merge_file" function on files that Ignite-UX knows how to merge information into.

The files operated on by "merge_file", as well as those that have a commented out "save_file" line, are likely to be modified by Ignite-UX. Comments in the file explain any exceptions.

Because the list of files modified by Ignite-UX may change from release to release, it is best to look at the os_arch_post_l file on your system to see which files are saved as-is and which are merged with information from the Ignite-UX configuration files.

Creating and Using Recovery Tapes

The Ignite-UX make_tape_recovery command creates a system recovery tape that can be used to boot and recover a system that is not bootable due to corruption of the root disk or root volume group. A system can be booted and installed from the tape without user intervention, including configuration, customization, software selection, hostname, and networking information.

A bootable recovery tape can be created from the Ignite-UX server, however the client must have a local tape drive.

It is preferable to use the Ignite-UX GUI on the Ignite-UX server when running an interactive make_tape_recovery session. Executing it from the Ignite-UX GUI causes any additional server configuration of NFS mounts to be performed. Additionally, more informative progress reporting is provided, and it is easier to use that interface.

IMPORTANT: The media and data format (density and compression) of the installation tape you create must be compatible with the clients on which it will be read. For example, if you have a mixture of DDS4 and DDS5 tape drives on your systems and you wish to be able to read recovery tapes on any of them, you should only use DDS4 media, as DDS5 media will not work in DDS4 drives.

The contents of the system recovery image will always include all files and directories that are considered essential to bringing up a functional system. This essential list is predefined by make_tape_recovery and is located in the following file:


In addition to the essential list, data can be included in the recovery image on a disk/volume group, file, or directory basis. Nonessential files and directories can also be excluded.

The tape created by make_tape_recovery is completely self-contained and does not require an Ignite-UX server to install the recovery image. The make_tape_recovery recovery image contains a specially prepared LIF volume. The configuration file in the LIF volume is the configuration file for the recovery archive. The /var/opt/ignite/INDEX file in the LIF volume specifies the recovery configuration as the default for the system. The recovery tape contains additional configuration information so no user interaction is required.

Additional files needed for booting and installing are copied from /opt/ignite/boot/Rel_release and /opt/ignite/data to the LIF volume on the tape, so everything the system needs to recover is there.

NOTE: During the recovery process, when the file system is set up and the I/O tree is initialized, tape device files may be mapped differently from when the original recovery tape was made. Therefore, it is possible for a recovery tape to be created with one tape device file, for instance /dev/rmt/0m, and recovered from a different device file, such as /dev/rmt/2m, though the physical device is the same.

You can also replicate a system and create a recovery image that can be used for installing clients. The section, “Notes on Cloning Systems” describes how to make use of this process. For additional information regarding system cloning, see the Successful System Cloning using Ignite-UX white paper on the "Information Library" page of the Ignite-UX website at


IMPORTANT: If you use make_tape_recovery for recovery, your tapes should be clearly labeled with the Ignite-UX version used to create them to avoid mixing Ignite-UX versions when two-step media recovery is used. See “Tape Recovery With No Tape Boot Support — Two-Step Media Recovery” for more information.

Recovery Tape Creation Examples

The following examples are intended to assist you in using the make_tape_recovery tool.

Recovering a Minimal Operating System

To create a minimal operating system recovery tape at /dev/rmt/0mn containing only the operating system elements required to boot the system, perform the following steps:

  1. Load a writable tape in the default tape drive for your system.

  2. As superuser, enter make_tape_recovery.

    A tape will be created without further interaction.

System recovery from this tape involves booting from the tape to recover the minimum core operating system. Then you would follow up with data recovery of all user files newer than those restored from the recovery tape.

NOTE: If you are creating a recovery tape for an Itanium®-based system, you can choose to use the -D option of make_tape_recovery to specify the name of the ANSI tape volume.
Creating a System Recovery Tape of the Entire Root Disk Volume

To create a system recovery tape at the default device, /dev/rmt/0m, that includes the entire root disk in the recovery image, perform the following steps:

  1. Load a writable tape in the default tape device for your system.

  2. Enter the command:

    make_tape_recovery -x inc_entire=vg00

    A tape will be created without further interaction.

Creating a System Recovery Tape of the Root Disk Volume with /usr on a Different Volume Group

You can easily create a system recovery tape of the entire root disk, even if the /usr file system resides on a different volume group, by using the -A option of make_tape_recovery. This option has make_tape_recovery determine which disks and volume groups the specified files reside on, and then include all files from those disks and volume groups in the recovery image.

  1. Load a writable tape in the default tape device for your system.

  2. Create a system recovery image with all the disks and volume groups containing the files specified by the default essentials file list /opt/ignite/recovery/mnr_essentials, or a user-defined version that replaces it, /var/opt/ignite/recovery/mnr_essentials, by entering:

    make_tape_recovery -A -s myserver -a /dev/rmt/0m

    A tape is created on the default device, /dev/rmt/0m, without further interaction. You can boot this tape on your new system.

TIP: The use of the -p option can be particularly helpful, as it allows you to preview the processing that would take place without actually creating the tape.

Tape Recovery for PA-RISC Systems

To install a system recovery image from a tape on a PA-RISC system, use the following procedure:

  1. Load the system recovery tape in the tape drive.

  2. Boot the system.

  3. Interrupt the boot sequence by pressing Esc.

  4. Select the tape drive you want to use, and then boot from it.

  5. Allow the installation process to complete.

For more information on creating recovery tapes, see make_tape_recovery(1M).

Tape Recovery for Itanium-Based Systems

To boot from tape on an Itanium-based system you must first create a tape boot option on the EFI Boot Manager menu. Verify that your Itanium-based system has firmware support for tape boot. If there is firmware that supports tape boot available for your system, you may first need to upgrade your firmware to make this functionality available. A set of tables showing minimum firmware revisions and SCSI HBAs that support tape boot is available in the Ignite-UX Installation Booting white paper available at


The first version of Ignite-UX to support native tape boot for Itanium-based systems is C.6.8. Recovery tapes created before that version of Ignite-UX can only be used with two-step recovery. See “Tape Recovery With No Tape Boot Support — Two-Step Media Recovery” for more information on two-step recovery.

The screens shown in this example are from an HP Integrity rx1620 system. Other systems may vary in method and screen format. For information on how to configure boot devices for your system, consult your system’s hardware documentation.

IMPORTANT: Configuring an EFI menu option for tape boot requires downtime since it can only be done from the EFI Boot Manager. If you are going to use tape recovery on your Itanium-based system, consider adding the tape boot option at your next planned maintenance window.
TIP: An ideal time to test tape recovery on your unique combination of system, tape drive, and HBA, is after you have configured an EFI Boot Manager menu option for tape boot. You do not need to recover the system. If you create a recovery tape with the -I option, you will enter an interactive recovery. When you get to the interactive screens, reset the system instead of performing a recovery.
Determining the Tape Drive’s EFI Path

When adding a tape boot option to the firmware, you must identify the tape drive you will use for booting. The EFI menus will display device paths to choose from. Before beginning the tape boot configuration process at the EFI level, you must determine the device path to your tape drive so you can select the correct one to use for booting.

The ioscan -e command does not report EFI device paths for tape drives. Alternative methods must be used to determine the correct path.

The EFI device path for our example is Acpi(HWP0002,100)/Pci(1|1)/Scsi(Pun4,Lun0)

One way to identify the tape drive’s path is to use the reconnect -r EFI command to get its SCSI Physical and Logical unit numbers (Pun and Lun). The Pun and Lun numbers can be mapped to the last part of the EFI device path. Below is the output of reconnect -r for our example.

Figure 15-2 Output From reconnect -r

Output From reconnect -r

Finding the Ultrium tape drive’s Pun and Lun numbers in this example is simple because not many devices are listed.

If your system is partitionable, EFI will not automatically enumerate all connected devices. (This allows for a speedier boot.) For this reason the tape drive you want to use may not be listed. If this is the case, you will need to use the search command to list the devices on the HBA the tape drive is connected to. See your system’s Operations Guide for details on the search command.

A third way to find the EFI device path is to use the tape drive’s hardware path as a map to it. The ioscan -fkeCtape command will list the hardware path of the tape drive.

For our example, the hardware path is 0/1/1/1.4.0

Use the following diagram to map the hardware path to the EFI device path:

Figure 15-3 Mapping the Hardware Path to the EFI Device Path

Mapping the Hardware Path to the EFI Device Path
Configuring the Tape Boot Option

Reboot your system and stop the process at the EFI menu before it times-out, as shown in the figure below. Notice the last line warns that reboot will occur after the remaining seconds expire.

Figure 15-4 EFI Menu With Timer

EFI Menu With Timer

Select Boot Configuration from the Boot Menu.

Figure 15-5 Boot Configuration

Boot Configuration

Select Add Boot Entry from the Boot Configuration menu.

Figure 15-6 Add Boot Entry

Add Boot Entry

The EFI Boot Manager will then display a menu listing the available devices to choose from. Select the tape drive you wish to boot from. See Determining the Tape Drive’s EFI Path above for how to select the correct device.

Figure 15-7 List of Selectable Boot Devices

List of Selectable Boot Devices

Enter a description in the next dialog box. This is the text that will appear in the Boot Menu listing. For this example, the new boot option will be called "Ultrium Tape."

Figure 15-8 Enter a Description for the Boot Option

Enter a Description for the Boot Option

Next, you will be prompted for load options. Press Enter at this point without entering anything.

Figure 15-9 Enter Load Options

Enter Load Options

The last step is to save your edits to NVRAM. If you have made a mistake, press n, otherwise press y and the changes will be saved to NVRAM.

Figure 15-10 Save Changes to NVRAM

Save Changes to NVRAM

You will be returned to the main EFI Boot Manager menu. If you answered y to the Save changes to NVRAM question, your new boot option will appear listed with the description text you entered in Figure 15-8.

Figure 15-11 The Boot Manager Menu with the New Option

The Boot Manager Menu with the New Option

At this point you have successfully configured a tape boot option, and it may be selected from the EFI Boot Menu. For more information on creating recovery tapes, see make_tape_recovery(1M).

NOTE: When executing any Itanium-based boot using the install kernels and install file systems, the following errors will appear in the output:

execve("/sbin/sh") failed, errno 0xffffffff

execve("/bin/sh") failed, errno 0xffffffff

These errors are not indicative of any Ignite-UX problem and can be safely ignored. The failures occur because /sbin/sh and /bin/sh are not present on the system when the kernel is starting; Ignite-UX does not need them at this point. On a non-installation boot, the kernel would be attempting to run /sbin/pre_init_rc, a script.

Creating and Using Network Recovery Images

Ignite-UX enables you to create recovery images using the network and store them onto the Ignite-UX server system or any other specified system. Systems can be recovered across subnets after booting. See “Making Boot Decisions When Using the Client Console” and the sections in Chapter 10 on "Installation Using bootsys" and "Installation Using the Ignite-UX GUI" for booting options.

The make_net_recovery tool creates a system recovery image and stores it on a system that may be accessed using the network. The recovery image created by make_net_recovery is specific to the system it was created for and its identity includes hostname, IP address, networking information, etc. In the event of a root disk failure, the recovery image can be installed using Ignite-UX to recover the system.

The contents of the system recovery image will always include predefined files and directories that are considered essential to bringing up a functional system. By running make_net_recovery in interactive mode (with the -i option), the directories and files that make up the essential list can be displayed. In addition to the essential list, data can be included in the recovery image on a disk/volume group, file, or directory basis. Nonessential files and directories can also be included. See “Recovery Image Contents” for more information.

Network Recovery Server Dependency

The recovery images created by make_net_recovery are designed to work with an Ignite-UX server; you cannot remove your Ignite-UX server and still use your recovery image.

Networking Features

Two NFS mount points are established on the client by make_net_recovery. The /var/opt/ignite/clients directory on the Ignite-UX server is mounted to the client system to store configuration files that describe the client configuration and location of the recovery image. The second mount point is made to the archive_server:archive_dir (see the -a option) and is used to store the recovery image of the client system. The default storage location on the Ignite-UX server is /var/opt/ignite/recovery/archives. After successful or unsuccessful creation of the system recovery image, the NFS mount points are unmounted.

The NFS mount for the recovery image directory may be exported on a per-client basis. A separate recovery image directory is used for each client. This enables you to NFS export each directory only to the individual client owning the recovery image, which provides security.

NOTE: If clients obtain temporary IP addresses from DHCP that differ from the IP address that they use during normal operation, you must allow the client access to all of the possible IP addresses to ensure access to the recovery image. If you do not, the client may fail to mount the recovery image directory from the NFS server and the recovery will fail.

Log Files

On an Ignite-UX server, progress and errors are logged to:


On a local system, progress and errors are logged to:


Adding Clients for Recovery

You can add a new client to your Ignite-UX server for the purpose of creating recovery images if the client is already running HP-UX. Unlike installation, adding a client for recovery does not require you to reboot the client. This is useful when you have installed the operating system, customized it, and now want to be able to recover it in the event of a problem or for disaster recovery purposes.

To add a new client to your Ignite-UX server, and then create a system recovery image, use the following steps:

TIP: You can execute the Ignite-UX GUI from a different system as if you were on the Ignite-UX server by using the following commands:
  • On your host system, allow the Ignite-UX server to access your display by adding the Ignite-UX server hostname to your xhost list:

    xhost +Ignite-UX_server_hostname

  • Set the DISPLAY variable to your local host system, if necessary. For example:

    export DISPLAY=your_host_system:0

    where your_host_system is the hostname of your system.

  1. On the Ignite-UX server, as superuser enter


  2. Select Add New Client for Recovery from the Actions menu.

    Figure 15-12 Add New Client for Recovery Dialog Box

    Add New Client for Recovery Dialog Box
  3. In the Hostname box, enter the name of the client for which you want to create a recovery image.

  4. Select how you want to communicate with the client, ssh or remsh, and then click OK. Use the default, ssh, for secure encrypted communications, or the unsecured remsh.

  5. If you choose ssh, you are asked if you want to use this communication method for all subsequent recovery, as well as any installation sessions run from the Ignite-UX server. Click Yes to set ssh as the default client communication, or No if you only want to use ssh for this recovery session.

    The Ignite-UX server then attempts to contact the client to begin the recovery initialization process and create a directory to contain the client’s information. In the event access to the client is denied, as in Figure 15-13, you are asked if you want to provide the root password.

    Figure 15-13 Confirmation Dialog Box

    Confirmation Dialog Box

    Clicking Yes produces a terminal window allowing you to enter the root password, clicking No halts the addition of this client and returns you to the Ignite-UX GUI.

    Once communication with the client is established and the client directory is constructed, a client icon appears in the Ignite-UX GUI.

  6. Ensure that the client icon for which you want to create a recovery image is selected, and then select Create Network Recovery Archive from the Actions menu. You may be prompted for the root password for the client.

The network recovery tools needed on the client are automatically installed.

After some informative dialog boxes, an Include/Exclude Selection dialog box appears. To view the essential files, click Show. Essential files cannot be excluded, but you can customize the image by specifying additional volumes, directories, or files. When an item is identified as both Include and Exclude, the Exclude category takes precedence.

Examples of Network Recovery Image Creation

Create a Recovery Image from the Client

This command creates a recovery image from the client, using settings from the last invocation of Ignite-UX, and using the options file on the Ignite-UX server (myserver) in the default location, /var/opt/ignite/clients/client/recovery/ :

make_net_recovery -s myserver

Create a Recovery Tape on a Client that Includes the Volume Group, vg00

To create a recovery image from the client that includes files from all file systems in the vg00 volume group, enter:

make_net_recovery -s myserver -x inc_entire=vg00

Preview System Recovery

To preview the processing that would take place without actually creating the recovery image, enter:

make_net_recovery -s myserver -p

Recovering using the Network for PA-RISC Clients

To recover a failed disk or volume group using the recovery image:

  1. Boot the failed system using one of these methods (see “Booting PA-RISC Clients from the Console ”):

    • Use Ignite-UX after reboot with boot lan install.

    • Boot from an Ignite-UX server using bootsys if the client operating system is running.

    • Boot the failed client locally by using a boot tape previously created with make_boot_tape.

  2. Do not interact with ISL.

    If your Ignite-UX server supports installing more than one version of HP-UX, a target operating system menu will appear:

    ISL booting hpux KernelPrompt "Choose Operating System to Install:" 1. target OS is B.11.11 2. target OS is B.11.23 PA 3. target OS is B.11.31 PA 4. Exit Choose an operating system to install that your hardware supports :
  3. At the client, from the main menu, select Install HP-UX.

    1. Respond to the Network Configuration dialog box.

    2. Respond to the UI Display Options dialog box (run at the Ignite-UX server or at a client.)

    3. If working from the Ignite-UX server, select the client for the system to be recovered.

  4. Select Install/New Install.

  5. Select the recovery configuration to use, and then allow the recovery to continue.

Recovering using the Network for Itanium-Based Clients

To recover a failed disk or volume group using the system recovery image:

  1. From the EFI Boot Manager menu, you will see a prompt to select a boot option. Select Boot Configuration.

    EFI Boot Manager ver 1.10 [14.62] Please select a boot option HP-UX Primary Boot: 0/1/1/1.2.0 EFI Shell [Built-in] --------------------------------- Boot Configuration System Configuration Use ^ and v to change option(s). Use Enter to select an option
  2. The Main Menu appears and prompts you to choose an operation. Select Add a Boot Option.

    EFI Boot Maintenance Manager ver 1.10 [14.62] Main Menu. Select an Operation Boot from a File Add a Boot Option Delete Boot Option(s) Change Boot Order Manage BootNext setting Set Auto Boot TimeOut Select Active Console Output Devices Select Active Console Input Devices Select Active Standard Error Devices Cold Reset Exit
  3. Select the appropriate network interface so that this network boot option loads the appropriate file from the following menu. For example, look for entries identified with a MAC address as in this example.

    EFI Boot Maintenance Manager ver 1.10 [14.61] Add a Boot Option. Select a Volume IA64_EFI [Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part1,Si IA64_EFI [Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part3,Si IA64_EFI [Acpi(HWP0002,100)/Pci(1|1)/Scsi(Pun2,Lun0)/HD(Part1,Si Removable Media Boot [Acpi(HWP0002,0)/Pci(2|0)/Ata(Primary,Master) Load File [EFI Shell [Built-in]] Load File [Acpi(HWP0002,0)/Pci(3|0)/Mac(123456789000)] Load File [Acpi(HWP0002,100)/Pci(2|0)/Mac(987654321000)] Exit
  4. Enter an appropriate boot option name at the message prompt. For this example, the new boot option is named lan0.

  5. Exit to the main menu by pressing Esc. The new boot option now appears in the EFI Boot Manager main menu.

    EFI Boot Manager ver 1.10 [14.62] Please select a boot option HP-UX Primary Boot: 0/1/1/1.2.0 EFI Shell [Built-in] Boot from lan0 --------------------------------- Boot Configuration System Configuration Use ^ and v to change option(s). Use Enter to select an option
  6. Select the new boot option you created. The following is an example of a successful boot using the new boot option.

    Starting: Boot from lan0 @(#) HP-UX IA64 Network Bootstrap Program Revision 1.0 Downloading HPUX bootloader Starting HPUX bootloader Downloading file fpswa.efi (328192 bytes) (C) Copyright 2004 Hewlett-Packard Development Company, L.P.All rights reserved HP-UX Boot Loader for IPF -- Revision 2.018 Booting from Lan Downloading file AUTO (26 bytes) Press Any Key to interrupt Autoboot AUTO ==> boot Rel_B.11.23/IINSTALL Seconds left till autoboot - 0 AUTOBOOTING... AUTO BOOT> boot Rel_B.11.23/IINSTALL Downloading file Rel_B.11.23/IINSTALL
  7. At the client, from the main menu, select Install HP-UX.

    1. Respond to the Network Configuration dialog box.

    2. Respond to the UI Display Options dialog box (run at Ignite-UX server or at a client).

    3. If working from the Ignite-UX server, select the client for recovery.

  8. Select Install/New Install.

  9. Select the recovery configuration to use, and then allow the recovery to continue.

Retaining Recovery Images

The -n option of the make_net_recovery command allows you to retain a fixed number of recovery images on your system, the default being two images. The oldest recovery image is removed when a new recovery image is created and the specified limit is exceeded. For more information, see make_net_recovery(1M).

You might want to prevent a specific recovery image from being deleted from your system. To do this, you must rename the recovery image and the image directory, and use manage_index to reflect the new names in the CINDEX file.

The following example renames a recovery archive yyyy-mm-dd,hh:mm to Recovery_Archive.sav:

  1. Log in to the system where recovery images are stored. This could be a system other then the Ignite-UX server.

  2. Rename the recovery archive. (The path to your recovery archive might be different from the example.) The name of the saved recovery archive can be anything unique, but it should be outside the naming convention yyyy-mm-dd,hh:mm.

    # cd /var/opt/ignite/recovery/archives/client # mv yyyy-mm-dd,hh:mm Recovery_Archive.sav
  3. If the system where recovery images are stored is different from your Ignite-UX server, log in to the Ignite-UX server.

  4. Rename the recovery archive directory.

    # cd /var/opt/ignite/clients/client/recovery # mv yyyy-mm-dd,hh:mm Recovery_Archive.sav
  5. If the renamed recovery archive directory is the target of the symbolic link latest, then link latest to the new directory.

    # rm latest # ln -s Recovery_Archive.sav latest
  6. Edit the archive_cfg file in the Recovery_Archive.sav directory to reference the new recovery archive name.

    Change the archive_path variable inside the (source_type == "NET") clause to the name of the saved recovery image.

    (source_type == "NET") {   archive_path = "Recovery_Archive.sav" }else {   archive_path = "1" }
  7. Use the manage_index command to update the configuration clause name and description, and to change the directory to the archive's configuration files.

    Rename the configuration clause:

    # manage_index -m 'yyyy-mm-dd,hh:mm Recovery Archive' \ -c 'Your configuration name' \ -i /var/opt/ignite/clients/client/CINDEX

    Update the configuration clause description:

    # manage_index -y 'Your configuration description' \ -c 'Your configuration name' \ -i /var/opt/ignite/clients/client/CINDEX

    Update the archive's configuration files to the new directory.

    Use manage_index to get a list of all the files associated with the cfg clause.

    # manage_index -w -c 'Your configuration name'\ -i /var/opt/ignite/clients/client/CINDEX

    For each configuration file to rename, remove the references to the old directory. This example renames archive_cfg. The other two configuration files to move are control_cfg and system_cfg.

    # manage_index -t -c 'Your configuration name' \ -f recovery/yyyy-mm-dd,hh:mm/archive_cfg \ -i /var/opt/ignite/clients/client/CINDEX

    For each configuration file to rename, add the references to the new directory:

    # manage_index -a -c 'Your configuration name' \ -f recovery/Recovery_Archive.sav/archive_cfg \ -i /var/opt/ignite/clients/client/CINDEX

Making Recovery Configuration File Additions

Using the recovery config.local file

To have a configuration file automatically added to all new recovery configuration clauses for a given client, create a new Ignite-UX configuration file called:


For local tapes the file is located in:


This config.local file will automatically be included in your recovery configuration for this client each time you run make_net_recovery. (The make_net_recovery command is run for you when you create a recovery image using the Ignite-UX TUI or GUI.)

If you already have recovery configurations for this client and would like them to include the recovery config.local file, use the manage_index command to include a reference to recovery/config.local in all of the configuration clauses.

The following example adds the recovery config.local file to all the 11i v2 cfg clauses in the CINDEX file.

# manage_index -a -r B.11.23 -f recovery/config.local \ -i /var/opt/ignite/clients/client/CINDEX

For more information, see manage_index(1M).

Adding a depot

If you want to install a recovery image on a different hardware platform or HP-UX Virtual Partitions (vPars) software, you might have to add software to the recovery configuration in the CINDEX file.

To add software to a recovery configuration, first create a configuration file for the software depot with make_config. Then, add the configuration file to the recovery configuration clause in the client's CINDEX file.

The following example creates a configuration file sw_cfg from the depot sw_depot and adds the configuration file to all the configuration clauses for the release specified in the configuration file name (Rel_release).

# make_config -s sw_depot -c /var/opt/ignite/data/Rel_release/sw_cfg # manage_index -a -f /var/opt/ignite/data/Rel_release/sw_cfg \ -i /var/opt/ignite/clients/client/CINDEX

During recovery, the software bundles available in sw_depot will be available for selection from the user interface software tab.

For more information, see manage_index(1M).

If you want the sw_cfg configuration file to be added to all new recovery configurations created for the client, add the sw_cfg file to the config.local file. For more information, see “Using the recovery config.local file”.

Selecting File Systems During Recovery

It is possible to change the way your disks are configured when you recover using a recovery image created by make_net_recovery. If you want to use a standard HP file system layout, you can specify the disk configuration using Ignite-UX. For more information, see “Basic Tab”.

If you do not want to use a standard HP file system layout, you can modify the /var/opt/ignite/clients/client/CINDEX file for the client you are recovering. The CINDEX file contains one or more configuration clauses that refer to the recovery images you have previously created with make_net_recovery. Add a new configuration file entry to the clause you intend to recover from. If you want to add the standard HP file system choices, add the file


where release is the operating system release on the client you intend to recover. For example:


would be added for a client with the HP-UX 11.11 operating system. This new configuration file entry should be the first entry in the clause you are modifying.

When you use the Ignite-UX GUI during recovery, select the File System type you want to use on the Basic tab.

Tape Recovery With No Tape Boot Support — Two-Step Media Recovery

You can use the Ignite-UX tape recovery tool to recover your system even if there is no tape boot support on the system.

Certain configurations, which are on most HP Integrity servers, allow you to directly boot a recovery tape. For information about what configurations and minimum firmware revisions support native tape boot on HP Integrity servers, refer to the Ignite-UX Installation Booting white paper available at http://docs.hp.com/en/IUX/infolib.html.

IMPORTANT: HP recommends you boot from the Operating Environment (OE) media that corresponds to the version of Ignite-UX you used to create your recovery tape. HP supports only matched OE media and recovery tape version combinations.

Using unmatched versions might produce unpredictable results, including: missing files, error messages, system hangs, and panics.

If you have misplaced the matching OE, or are using an Ignite-UX version with no matching OE, you can make your own minimal bootable CD/DVD to support two-step media recovery. See “Creating a Boot CD/DVD or an Installation DVD”, or see the section How do I create the CD equivalent of a tape created by make_boot_tape? in the Ignite-UX Custom Configuration Files document found on http://docs.hp.com/en/IUX/infolib.html.

  1. Insert the HP-UX OE media or the bootable custom media into the appropriate drive, and boot from it. Either media must match the HP-UX version used when creating the recovery tape.

    The following interface screen appears:

    User Interface and Media Options This screen lets you pick from options that will determine if an Ignite-UX server is used, and your user interface preference. Source Location Options: [ * ] Media only installation [ ] Media with Network enabled (allows use of SD depots) [ ] Ignite-UX server based installation User Interface Options: [ ] Guided Installation (very basic installs - deprecated mode) [ * ] Advanced Installation (recommended for disk and file system management) [ ] No user interface - setup basic networking, use defaults and go [ ] Remote graphical interface running on the Ignite-UX server Hint: If you need to make LVM size changes, or want to set the final networking parameters during the install, you will need to use the Advanced mode (or remote graphical interface). [ OK ] [ Cancel ] [ Help ]
  2. Click OK to advance to the next screen:

    Media Installation This screen provides an option to switch the install source from the default CD/DVD to a recovery tape. This is helpful for those systems and for tape devices which do not support booting from a tape. [ ] CD/DVD Installation [ * ] Boot from CD/DVD, Recover from Tape [ OK ] [ cancel ] [ Help ]
  3. Select Boot from CD/DVD, Recover from Tape and click OK to advance to the Tape Drive Selection screen:

    Tape Drive Selection There are one or more tape drives detected on the system. Insert your recovery tape into one of the drives and then select that drive from the list below. Use the <tab> and/or arrow keys to move to the desired TAPE device, then press <Return/Enter> to select. HW Path Device File Description ---------------------------------------------------------- [ 0/4/1/0.0x6.0x0 /dev/rmt/c6t6dOBEST HP_SDLT600 ]
  4. Select the tape drive that contains the recovery image tape, then press Enter to start the installation of the recovery image from the chosen tape drive.

Notes on Cloning Systems

Ignite-UX offers two main options for replicating (cloning) systems. The more flexible and complex golden image method makes use of make_sys_image to create an archive of the source system, followed by manually modifying configuration files to meet your needs. A much simpler (but less flexible approach) uses make_[tape|net]_recovery. The pros and cons of each are described here.

In each case, the source system that is used must contain software that is compatible with all clients. This means that the version of HP-UX, patches, drivers, etc., must be sufficient for all systems involved. This often requires installing a superset of software and drivers onto the source system that will be used on all potential clients.

Using the make_sys_image method

Using the golden image method of creating an archive with make_sys_image and then modifying Ignite-UX configuration files to reference the archive is very flexible, but somewhat time consuming. The end result gives you:

  • The ability to install systems from network or media from either an Ignite-UX server or local clients.

  • The ability to customize the process and tune it to accommodate many different situations.

  • A "clean" system: log files and most remnants specific to the source system are removed.

  • A rebuilt kernel containing just the drivers needed by the client’s hardware.

  • The ability to install additional software or patches on top of the system archive from an SD depot. This reduces the need to recreate the archive and enables you to add support for new hardware that requires new patches or drivers without making a new archive.

See Chapter 11: “Golden Images”, for more information.

Using the make_[tape|net]_recovery method

The make_[tape|net]_recovery tools are designed to reproduce a system exactly the way it was at the time the snapshot was taken. These tools try to accommodate cloning in various ways:

  • You can change hostname and networking information.

  • You can make changes to disks and file systems during the recovery.

  • You can detect hardware model changes and rebuild the kernel.

However, their attempt to reproduce a system exactly may be undesirable:

  • The disk layout is saved "as-is" from the original system and does not have flexible logic to accommodate disks of varying sizes or locations.

  • Hardware instance numbers for devices that exist at the same paths between systems have the instance numbers preserved from the original system. This can cause non-contiguous assignments in instance numbers, which is usually only a cosmetic problem.

  • Many files that are specific to the system the recovery image was taken from are preserved. This includes many log files, etc.

  • When the kernel is rebuilt (in the "cloning" situation), drivers may be added as needed by the hardware, but unused drivers will not be removed.

Cloning a System Using make_net_recovery

The recovery configurations and archives created by make_net_recovery are stored in a separate directory on the Ignite-UX server for each client. Using the configuration and archive created by make_net_recovery on one system to install a different system involves manually copying some configuration files and allowing NFS access to the source system’s archive.

A system recovery tape created using make_tape_recovery can also be used to clone systems. The system you are installing by cloning must have a local tape drive so you can boot from the system recovery tape.

The following example illustrates how to clone a system:

  1. Use make_net_recovery or Ignite-UX to create a system recovery image of the source system.

  2. On the Ignite-UX server, if the client to be installed does not currently have a directory in /var/opt/ignite/clients but is up and running, use the Ignite-UX GUI to create that directory using Add New Client for Recovery from the Actions menu. For more information, see “Adding Clients for Recovery ”.

    If the client is not running, you will either need to boot it from the Ignite-UX server or from media in order for this directory to be created.

  3. Copy the CINDEX and recovery directory from a source client to the target client directory. If the target client has previously used make_net_recovery, it will already have a CINDEX file. If the CINDEX file for the client exists, you might want to save a copy and then edit the file to add the desired entries from the source client. The following commands copy the required files. You may specify src_client and target_client using either the MAC address or the client’s hostname, which is a symbolic link to the MAC address:

    # cd /var/opt/ignite/clients/src_client

    # find CINDEX recovery | cpio -pdvma ../target_client

  4. Give the target client NFS access to the recovery image of the source system. Typically each target client has its own directory on the source system for storing the recovery images and the directory is exported only to the individual client. To do this, log in to the system that holds the recovery image (normally the Ignite-UX server).

    For HP-UX 11i v3 systems:

    • Edit the /etc/dfs/dfstab file on the source client.

    • Append ,ro=target_client to the -o argument of the source client's line, where target_client is a fully qualified client name.

    • Run # shareall -F nfs

    For HP-UX 11i v1 and 11i v2 systems:

    • Edit the /etc/exports file on the source client.

    • Append :target_client to the end of the source client's line, where target_client is the hostname of the target system.

    • Run # exportfs -av

    See dfstab(4) or exportfs(4) for more information.

  5. Boot the target client from the Ignite-UX server using any method you prefer. When you install the system, you can select from the recovery configurations of the source system.

  6. Change the system networking parameters for the client during the installation.

For additional information regarding system cloning, see the Successful System Cloning using Ignite-UX white paper on the "Information Library" page available at the Ignite-UX website at


System Recovery Questions and Answers


Can I use a network recovery image if my system is not on the same subnet as the Ignite-UX server?

Yes, there are the commands make_boot_tape , make_ipf_tape, and make_media_install that create minimal boot media for use by any client. The media contain just enough information to boot a client and then connect to the Ignite-UX server where the tape, CD, or DVD was created. If that is the server where the client’s recovery configuration files are stored, then the client can be recovered.

It is not possible to boot all systems from a tape device. See “Tape Recovery With No Tape Boot Support — Two-Step Media Recovery”.

If you initiate recovery tape creation from the Ignite-UX server, the server will warn you if the client requires boot media. If you ignore this warning, misplace your boot media, or find that your media are for the wrong Ignite-UX server, you can always create new boot media on the server you want to use. There is no client-specific information on the media.

Notice that media created by make_boot_tape, make_ipf_tape, and make_media_install are useful not only for recovery situations, but also for ordinary installations. If you do not want to set up a boot helper for systems on a separate subnet than the Ignite-UX server, you can simply create bootable media.

For more information, see Chapter 14, make_boot_tape(1M), and make_ipf_tape(1M).

Other options include direct boot profiles (see “Direct Boot Profiles for Itanium-Based Systems”) and boot helpers (see “Ignite-UX bootp Boot Helper”).


How can I change my setup so a network recovery image is available not only on the system for which it was created, but also on other systems with very similar hardware?

Because networking information can be changed using the interface and will not be overwritten by files extracted from the image, it is natural to think about sharing recovery images for systems with identical or nearly identical hardware. But unlike shared configurations that appear in the configuration list for all clients, network recovery configurations only appear in the configuration list of the client for which they were created.

The source for shared configurations is the /var/opt/ignite/INDEX file that is created when Ignite-UX is installed, and the source for client-specific configurations is the CINDEX file that is created by make_net_recovery in the /var/opt/ignite/clients/client directory. One simple way to share a recovery configuration among two systems with similar hardware is to copy the CINDEX file and the recovery directory of the client with the image to the directory of the client without the image. The fact that the entries in CINDEX use relative paths means you do not have to change the CINDEX file when you copy it. You will need to NFS export the directory containing the image to the sharing client. For detailed information on this process, see “Cloning a System Using make_net_recovery.


I do not want to interact with the user interface after I reboot the client. How can I have my latest network recovery image chosen automatically?

As long as the client is currently booted, use bootsys -a to start the installation process on the client without the need to interact with the user interface.

Ignite-UX chooses a configuration to use based on these guidelines:

  • If /var/opt/ignite/clients/client/config exists, use the cfg clause specified there.

  • If /var/opt/ignite/clients/client/config does not exist, use the default cfg clause for the client.

    The default cfg clause for the client is the last applicable entry set to true in the CINDEX file if it exists. Otherwise, the default cfg clause is the last applicable entry set to true in the INDEX file. Because make_net_recovery sets the most recently created recovery cfg clause to true in CINDEX whenever it creates a new image, that will be the default unless it is manually changed.

To set Ignite-UX to choose the latest network recovery image automatically:

  1. Rename or remove the config configuration file currently in the client’s directory, or use the bootsys -f option.

  2. Run this from the Ignite-UX server:

    bootsys -a client

For information on automating an installation, see the descriptions of run_ui, control_from_server, and INST_ALLOW_WARNINGS in instl_adm(4).


What causes tftp errors when recovering or installing a system?

  • Only /opt/ignite and /var/opt/ignite should be needed for tftp access.

  • Check /etc/inetd.conf

  • Files in INDEX should not be in directories outside /opt/ignite and /var/opt/ignite.


What can I do when problems occur from hot-swapping disks during recovery?

Ignite-UX supports only hot-swappable disks that are completely in place and not removed when creating a recovery image. Proper software and hardware procedures must be used for hot-swap disk removal or replacement before or after recovery, but not during. The LVM command, lvlnboot, used by save_config does not work when a disk is removed and the system is in this intermediate state. If this command is not working, a recovery cannot succeed.


Why is the EFI volume not restored during a recovery?

Ignite-UX destroys the old EFI volume on the boot disk and creates a new EFI volume every time the system is installed. At no point during the installation is the old EFI volume copied and restored to the disk.

To restore the EFI volume to the disk, reinstall the application or look at the SD configure scripts for the application and then rerun the commands that put the EFI volume in place on the disk.


Why does make_net_recovery fail when the image is 2 GB or more?

The make_net_recovery command uses NFS to write/read the system image from the client to/from the server. To manage images greater than 2 GB requires that both the client and server use NFS protocol Version 3 (PV3). NFS PV3 is standard on all HP-UX 11i releases.

If you know you have NFS PV3 and are having problems, check the /etc/rc.config.d/nfsconf file for the configured parameter, MOUNTD_VER that defines the default mount to be PV2 or PV3; it must be set to 3.


Why is the LAN address different after replacing a client system?

Ignite-UX uses a separate directory for each client under /var/opt/ignite/clients. Each subdirectory is named based on the client’s LAN address. If you replace the client hardware or even the LAN interface that the old LAN address was based on, it will no longer access the same directory on the server.

The simplest solution is to obtain the new LAN address with the BCH command LanAddress or the EFI command lanaddress. Once you have the new address, manually rename the directory. You may just remove the hostname symlink (it will be recreated automatically). Note that the LAN address must be in all uppercase, and begin with 0x.

If you already booted from the client and caused the server to create a new directory, you can just remove that directory before renaming the old directory. To avoid losing the recovery information, be careful not to remove the original directory. For example:

# cd /var/opt/ignite/clients

# mv 0x00108300041F 0x00108300042A

# rm old_hostname


When recovering a system across multiple disks, how are the volumes assigned to disks?

Ignite-UX will do all it can to find a solution to refitting the volumes back to disks. If Ignite cannot find a solution, it will automatically turn off the mapping by setting the Disk Mapping value from Assigned Disk to Any. For information regarding how to set the Disk Mapping value, see “Volume Parameters” and the File System/Swap Attributes section in instl_adm(4).


Why is the tape device different between making the recovery image and using the recovery image?

During the recovery process, when the file system is set up and the I/O tree is initialized, tape device files might be mapped differently from when the original recovery tape was made. Therefore, it is possible for a recovery tape to be created with one tape device file, for instance /dev/rmt/0m, and recovered from a different device file, such as /dev/rmt/2m, even though the physical device is the same.

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