System Recovery

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 Image Contents

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

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:

Recovery Image Configuration Policies

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

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:

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

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.

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:

/opt/ignite/recovery/mnr_essentials

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

http://www.docs.hp.com/en/IUX/infolib.html

	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 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

http://www.docs.hp.com/en/IUX/infolib.html

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

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

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

Select Boot Configuration from the Boot Menu.

Figure 15-5 Boot Configuration

Select Add Boot Entry from the Boot Configuration menu.

Figure 15-6 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

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

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

Figure 15-9 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

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

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

   /opt/ignite/bin/ignite

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

   Figure 15-12 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

   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.

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:

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

/opt/ignite/data/Rel_release/config,

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

/opt/ignite/data/Rel_B.11.11/config

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.

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:

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:

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

System Recovery Questions and Answers

Question:

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”).

Question:

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”.

Question:

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:

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

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

Question:

What causes tftp errors when recovering or installing a system?

Question:

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.

Question:

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.

Question:

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.

Question:

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

Question:

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).

Question:

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.