Ignite-UX FAQ ================================================================================ Ignite-UX (IUX) Frequently Asked Questions ＠(#) IUX FAQ $Revision: 10.155 $ $Date: 2005/03/16 18:09:49 $ About this FAQ -------------- At the release of Ignite-UX version C.6.0, all FAQ entries were removed that applied to HP-UX 10.x or Ignite-UX versions prior to B.4.0. The current contents of this FAQ were created by the Ignite-UX engineering team from questions gathered from various sources. You may obtain a copy of this FAQ from: http://docs.hp.com/en/IUX/faq.html TABLE OF CONTENTS ----------------- 1. Known Problems ----------------- 1.1 Q: I updated my server; now it cannot find "/d_cfg_mnt_sb61/monitor_bpr". 1.2 Q: Can the Ignite-UX GUI for make_tape_recovery span multiple tapes? 1.3 Q: Why do I get Warnings from pax concerning files that are not on the client when I run either make_tape_recovery or make_net_recovery? 1.4 Q: When igniting from an archive, why do I get numerous samreg errors? 1.5 Q: Can an Ignite-UX server install clients on multiple subnets? 1.6 Q: Using bootptab entries to satisfy the DHCP request does not work. Why? 1.7 Q: Why do some applications and shells hang over NFS after igniting? 1.8 Q: The bootsys command occasionally hangs on 11.00 clients. Why? 1.9 Q: Why does installing the 11.00 64-Bit Minimal HP-UX environment fail? 1.10 Q: Why do the iux_postconfig scripts associated with EMS KRM sometimes fail? 1.11 Q: Why does ioscan core dump when running make_tape_recovery or make_net_recovery? 1.12 Q: Can I run make_net_recovery from a PA-RISC server to create an archive for an Itanium 2-based client or vice versa? 1.13 Q: Why does installing or recovering a client via NFS from an HP-UX 11i v1 Ignite-UX server take so long compared to an 11.0 server? 1.14 Q: Why can I not use Ignite-UX with my Rev. A C3700/J6700 systems? 1.15 Q: My VxVM installation has stopped with the message: ERROR: Disk group dg02:cannot create: Disk group exists and is imported. What is the problem and how can I resolve it? 1.16 Q: Is SecurePath (previously known as AutoPath) supported by Ignite-UX during installation or recovery? 1.17 Q: Why is install.log so difficult to read? 1.18 Q: Why does "Match What Target Has" not work on the Ignite-UX.BOOT-KERNEL-?A filesets prior to Ignite-UX C.6.0? 1.19 Q: Why is the message 'Cannot open /dev/vx/rdsk/rootdg/standvol' output during an IPF install via golden image? 2. Server Setup --------------- 2.1 Q: Should I use DHCP or bootp? 2.2 Q: Why did it call my client <hostname>.0x080009.... ? 3. Configuration Files ---------------------- 3.1 Q: What should go in which configuration file? Also, what should go in INSTALLFS? 3.2 Q: How do I preview configuration file changes? 3.3 Q: Is there a way to set the configuration files to ignore the disk warnings, which can prevent automated installations? 3.4 Q: Which configuration file example should I use for an HP-UX 11.00 archive? 4. Recovery (make_tape_recovery & make_net_recovery) ---------------------------------------------------- 4.1 Q: We tried running the recovery system option from a client booted in Ignite-UX, which generated errors. What files need to be accessible for tftp? 4.2 Q: How do I duplicate a tape made with make_recovery? 4.3 Q: How do I deal with hot-swappable disk devices during recovery? 4.4 Q: What is the maximum amount of data that a make_recovery tape can hold? 4.5 Q: How do I boot correctly from a recovery tape on a V-class system? 4.6 Q: How do I include all volume/disk groups into a recovery tape? 4.7 Q: Are multi-byte characters supported in file names in Ignite-UX? 4.8 Q: Can you move a volume that was created in a non-root volume to the root volume during recovery? 4.9 Q: How can I create empty volume groups during system restoration? 5. General Install ------------------ 5.1. Q: How does Ignite-UX estimate needed file system sizes? Does it do anything other than add up the impacts statements? 5.2. Q: When does Ignite-UX configure software? 5.3. Q: How do I set the client's final networking information? 5.4. Q: I do not want to use DHCP, can I still have Ignite-UX automatically determine networking information for all my clients? 5.5. Q: How can I make software in a depot available for installations? 5.6. Q: FDDI software is included in my archive, yet Ignite-UX requires that I select it. Why? 5.7. Q: How many clients can I install simultaneously or in parallel? 5.8. Q: My installations are hanging; what is going on? 5.9. Q: How large can I create a single swap space using Ignite-UX? 5.10. Q: Why do the text fields in the Ignite-UX TUI not accept my input, and the dialogs re-open or loop? 6. Network Install ------------------ 6.1 Q: When the client searches for bootable devices, the Ignite-UX server does appear on the list. When I try to boot, I get the error: IPL error: bad LIF magic. Why? 6.2 Q: I set "control_from_server=true" and "run_ui=false" in the INSTALLFS, but I still get prompted for information on the client. What is wrong? 6.3 Q: The bootsys command seems to work in reverse; if we typed bootsys -w client the client did not wait for the server, if we typed bootsys client , the client waited for the server. Why? 6.4 Q: When executing "search lan install" on the client, the Ignite-UX server does not appear in the list. Why? 6.5 Q: The bootsys command fails due to insufficient space in the /stand volume. Why? 6.6 Q: Can I have the Ignite-UX server and client on different subnets? 6.7 Q: My Itanium 2-based client fails to boot with a PXE-E16 error. Why? 7. Media Install ---------------- 7.1 Q: Why do I get DCE/RPC errors (RPC exceptions) during the configuration stage? 7.2 Q: How can I put an operating system archive on multiple CDs? 8. Archive Installs (Golden Images) ----------------------------------- 8.1 Q: What does the following gunzip error indicate? 8.2 Q: The "/etc/nsswitch.conf" and "/etc/resolv.conf" files from my archive do not end up on the client. Why? 8.3 Q: What do these errors mean: pax_iux: X: Cross-device link, pax_iux: X: File exists, or pax_iux: X : Device busy? 8.4 Q: What applications are tested for use with Ignite-UX? 9. Obtaining Ignite-UX ---------------------- 9.1 Q: What is different about the Web version? 9.2 Q: Is Ignite-UX available on media? 9.3 Q: How do I update my Ignite-UX server to a new version? 9.4 Q: How much of Ignite-UX do I need to installation? 9.5 Q: How can I copy Ignite-UX from media to a local depot such that Ignite-UX from this new local depot will be installable on all HP-UX B.11.* systems? 10. Loading Patches ------------------- 10.1 Q: Can patches be installed with software? 10.2 Q: How do I prevent backup copies of patched files from being saved? 10.3 Q: Why do I get errors from swinstall regarding patches in HP-UX 11.00 depots? 10.4 Q: Why are patches left in an installed state when I install the Support Plus patch bundle along with HP-UX 11.x from CD? 11. Network Recovery -------------------- 11.1 Q: How can I learn more about network recovery? 11.2 Q: How can I clone a client using make_net_recovery? 11.3 Q: How can I tell which files will be included in the archive created by make_net_recovery? 11.4 Q: How can I tell which disks or volume groups get re-created during an installation from a make_net_recovery configuration? 11.5 Q: How can I use make_net_recovery if I need to be able to recover from a tape? 11.6 Q: Which files does Ignite-UX change during an installation from a make_net_recovery configuration? 11.7 Q: How can I keep archives from being deleted by make_net_recovery when new archives and configurations are created by subsequent invocations of make_net_recovery? 11.8 Q: How can I make configuration file additions to all recovery configurations for a given client? 11.9 Q: How can I select from the standard file system layouts during a recovery? 11.10 Q: I replaced the client machine and the LAN address is now different. How can I restore the new machine from the old client network recovery archive? 11.11 Q: Dealing with hot swappable disks during recovery. 11.12 Q: Why does archive_impact fail during make_net_recovery? 11.13 Q: How can I restore VxVM DCO log volume groups? 11.14 Q: Are the layered/striped/mirrored VxVM volumes included in the recovery archive when a client recovery archive is created? 11.15 Q: Can I run make_tape_recovery/make_recovery in single user mode? If so, how? 11.16 Q: Why are there invalid disk device files left behind after some recoveries? =============================================================================== ---------------------------------------- 1. Known Problems ---------------------------------------- 1.1 Q: I updated my server; now it cannot find "/d_cfg_mnt_sb61/monitor_bpr". A: This is caused by having a mix of Ignite-UX fileset revisions on your server. In most cases it happens when you update only one release bundle (like Ignite-UX-11-23) even though you install other releases from that server. An easy way to check for this case is to look at the output from the command swlist IUX. All the filesets should have the same revision; if not, then you need to install all consistent versions. If you have "boot helper" systems, they also need to have the Ignite-UX product updated to match the same revision as the server that they reference. =============================================================================== 1.2 Q: Can the Ignite-UX GUI for make_tape_recovery span multiple tapes? A: No. This is not possible for the Ignite-UX A.3.2 release. We use pax as the tool to create the archive tape and there is no current communication between pax and the GUI to prompt the user on the GUI when pax requests a second tape. You need to use make_tape_recovery on the client to be able to span multiple tapes. =============================================================================== 1.3 Q: Why do I get Warnings from pax concerning files that are not on the client when I run either make_tape_recovery or make_net_recovery? A: If files are removed from the client between the time the list of files to be archived is created and the time the files are actually archived, warnings are generated. For more information, refer to make_tape_recovery(1M) and make_recovery(1M). =============================================================================== 1.4 Q: When igniting from an archive, why do I get numerous samreg errors? A: The problem is that the SAM filesets have not been configured when certain products are trying to register themselves with SAM. The workaround is as follows: Place this configuration stanza in "/var/opt/ignite/config.local" or directly in the configuration file with the core sw_source: sw_source "core" { post_load_cmd += " swconfig -xautoselect_dependencies=false / -xenforce_dependencies=false SystemAdmin.SAM " } =============================================================================== 1.5 Q: Can an Ignite-UX server install clients on multiple subnets? A: There is one known problem with having an Ignite-UX server that is multi-homed (connected to multiple subnets): The "server" keyword that specifies the IP address for your Ignite-UX server can only correspond to one of the LAN interfaces. If each subnet is routed such that all clients can use the one IP address to contact their server, then the installation will work. However, it is more efficient for the client to use the server's IP address that is connected directly to the client's own subnet. If a client is on a subnet that does not have a route to the IP address specified by "server", then it will not be able to contact the server after it boots. The workarounds for this problem are as follows: - Manually correct the server's IP address on the networking screen that appears on the client console when you boot the client. - Use a boot-helper on each subnet. When using a boot helper, the server's IP address can be specified correctly on each helper system. For more information, refer to the "Ignite-UX Administration Guide". =============================================================================== 1.6 Q: Using bootptab entries to satisfy the DHCP request does not work. Why? A: There is a known problem with the bootpd daemon on HP-UX B.11.00 until patch PHNE_19241. If you are strictly using entries in /etc/bootptab, you may have problems once these patches are on your server. The workaround is to choose to: - Install the patch with the fix: PHNE_19241 (B.11.00). - Remove these patches. - Wait until a new patch with a fix is released. - Or, create a dummy entry in the "/etc/dhcptab" file which works around the defect. You will need to set the subnet mask for your network. The entry can look something like this: DHCP_POOL_GROUP:\ pool-name=BLUE_SUBNET_POOL:\ subnet-mask=255.255.255.0 :\ lease-time=120:\ addr-pool-start-address= 192.11.22.254:\ addr-pool-last-address= 192.11.22.254: =============================================================================== 1.7 Q: Why do some applications and shells hang over NFS after igniting? A: The reason for the hang is most likely due to a problem with the NFS file locking daemons rpc.statd and rpc.lockd, caused by the action of reinstalling the client. Many applications use file locking and can hang in this situation. Most common is user home directories that are NFS mounted, in which case sh and ksh attempt to lock the .sh_history file and hang before giving you a prompt. When a client is running and has an active NFS mount with a server in which files have been previously locked, both the client and server cache information about each other. Part of the information that is cached is what the RPC port number uses to contact the rpc.lockd daemon on the server and client. This RPC port information is cached in memory of the running rpc.statd/rpc.lockd process on both the server and client sides. The rpc.statd process keeps a file in the directory /var/statmon/sm for each client that it knows to contact in the event that the client reboots (or rpc.statd/rpc.lockd restarts). During a normal reboot or crash, rpc.statd will contact each client in /var/statmon/sm and inform them to flush their caches regarding this client. When you reinstall a client, the /var/statmon/sm directory is wiped out. In this case, if the reinstalled client tries to re-contact a server that has cached information, the server will try to communicate over an old RPC port. The communication will fail for rpc.lockd and any file locking done by an application over that NFS mount will hang. There are a several ways to avoid and/or fix the problem if it happens: - If you are using bootsys to install clients, use the -s option to allow the client to shutdown normally and thus inform servers that it is going down. - If you experience a hang, you can reboot the client, or kill/restart rpc.lockd and rpc.statd on the client. At the point of the hang, the /var/statmon/sm directory will contain the name of the server, and thus rebooting or restarting the daemons will tell the server to flush its cache. If more than one server is involved you may end up doing this multiple times until all servers are notified. - As part of the installation, create a file for each server in /var/statmon/sm which contains the server's name. This will cause the first boot to generate a crash recovery notification message to each server, causing them to purge the stale port information. The following is an example post_config_cmd stanza that could be placed in your /var/opt/ignite/config.local file: post_config_cmd += " mkdir -p /var/statmon/sm for server in sys1 sys2 sys3 do echo $server > /var/statmon/sm/$server chmod 0200 /var/statmon/sm/$server done " =============================================================================== 1.8 Q: The bootsys command occasionally hangs on 11.00 clients. Why? A: If you are experiencing the bootsys command hanging after copying over the required files to the client, you may need to install the latest remsh/rcp/rlogin/rexec patch onto the clients. You will typically see a cat process that never completes running on the bootsys client. 11.00: PHNE_17030 JAGab73645 (fixed at 11i v1 [11.11]) A workaround is to kill the remsh process on the server that was invoked by the bootsys command. The bootsys operation should complete successfully after this. =============================================================================== 1.9 Q: Why does installing the 11.00 64-Bit Minimal HP-UX environment fail? A: When installing the 11.00 64-Bit Minimal HP-UX environment, you may encounter errors during the software installation that are similar to the following: The prerequisite "PHKL_19142.C-INC,r=1.0" for fileset "PHKL_21306.C-INC,r=1.0" cannot be successfully resolved. ERROR: The dependencies for fileset "PHKL_21306.C-INC,r=1.0" cannot be resolved (see previous lines). You must resolve the above dependencies before operating on this fileset or change the "enforce_dependencies" option to "false". In addition, on clients that have USB hardware, the kernel build process that follows will fail. The problem is that several required patches depend on the PHKL_19142 patch, which in turn requires that the ProgSupport.C-INC fileset be installed. This C-INC fileset is not part of the HPUXMinSys64 bundle and does not get automatically installed. A future release of Ignite-UX will include a newer version of swinstall that will automatically select the ProgSupport.C-INC dependency. In the meantime, you can workaround this problem by manually editing the configuration file produced by make_config that you created for the core operating system depot. In this config-file, search for a line that reads: sd_software_list = "HPUXMinSys64,r=B.11.00,a=HP-UX_B.11.00_64,v=HP" And change it to: sd_software_list = "HPUXMinSys64 ProgSupport.C-INC" =============================================================================== 1.10 Q: Why do the iux_postconfig scripts associated with EMS KRM sometimes fail? A: On some HP-UX 11.x clients you might see the following errors when recovering a client from a make_recovery or make_tape_recovery tape, or a make_net_recovery image: Executing: "/var/adm/sw/products/EMS-KRMonitor/KRMON-RUN/iux_postconfig". ERROR: Cannot install a dlkm driver. ERROR: Cannot configure a dlkm driver. ERROR: The script: "/var/adm/sw/products/EMS-KRMonitor/KRMON-RUN/iux_postconfig" failed, exit code was 1. The reason for this is when the recovery archive was created, the kernel the client was running was not created correctly (the DLKM information was out of sync). You should always use kmupdate to move a new kernel into place after creating it with mk_kernel, this will move the DLKM information into place when the new vmunix is moved into place at the next shutdown. To solve this problem, create a kernel in the way described above then recreate the recovery tape or network recovery archive. You should not see this message the next time you use the new tape or network recovery archive (the old tape or network recovery archive will always show this problem). =============================================================================== 1.11 Q: Why does ioscan core dump when running make_tape_recovery or make_net_recovery? A: It is possible for ioscan to core dump due to the value set for the COLUMNS environment variable in versions prior to HP-UX 11i. When the -n option is used, ioscan uses the COLUMNS variable to determine how wide the screen is when formatting the names of device files. If a core dump occurs, you will see messages similar to the following: sh: 13061 Floating exception(coredump) WARNING: pclose of ioscan returned: 34816 Should this happen, unset COLUMNS, and then rerun make_tape_recovery or make_net_recovery. If you are using an xterm, hpterm, or dtterm to run make_tape_recovery or make_net_recovery, do not resize the terminal window to a smaller size, instead minimize it if it is in the way. This problem should not happen from 11i (any version) onwards where the defect has been fixed. =============================================================================== 1.12 Q: Can I run make_net_recovery from a PA-RISC server to create an archive for an Itanium 2-based client or vice versa? A: For Ignite-UX release B.5.3 and later, this happens automatically. For Ignite-UX release B.5.2 and previous releases, you can but you must execute additional steps. Although the B.4.0 and later versions of Ignite-UX can be installed on both Itanium 2-based and PA-RISC clients, make_net_recovery cannot automatically swpackage the network recovery tools into /var/opt/ignite/depots/recovery_cmds depot for a mismatched platform client. For example, a server is an Itanium 2-based system with the B.4.0 version of Ignite-UX installed and is being used for PA-RISC clients. When make_net_recovery is run from the GUI to create a recovery archive of a particular PA-RISC client, an error similar to this appears: Error Message: swinstall(1M) failed to install recovery tools from: "funhouse: /var/opt/ignite/depots/recovery_cmds" Note: The following procedure is only required if you are running a version of Ignite-UX prior to B.5.3. To avoid this issue, you must execute the following steps: 1. Run the following command to generate the IUX-Recovery bundle in /var/opt/ignite/depots/recovery_cmds on the Itanium 2-based server: # /opt/ignite/lbin/pkg_rec_depot 2. Run swcopy to copy the entire Ignite-UX product with the right Software Distributor architecture for the client. For example: # swcopy -x layout_version=0.8 -s <depot_path> B5725AA ＠ \ /var/opt/ignite/depots/recovery_cmds where <depot_path> is the depot location where Ignite-UX is found. For example the mount point of the media or the path to a serial depot from which Ignite-UX was obtained from the web. 3. Ensure that the correct bundles are now in /var/opt/ignite/depots/recovery_cmds by entering: # swlist -l bundle -s /var/opt/ignite/depots/recovery_cmds # Initializing... # Contacting target "systemA"... # # Target: systemA:/var/opt/ignite/depots/recovery_cmds # IUX-Recovery C.6.0.66 Ignite-UX network recovery tool subset Ignite-IA-11-22 C.6.0.66 HP-UX Installation Utilities for Installing 11.22 IA Systems Ignite-UX-11-00 C.6.0.66 HP-UX Installation Utilities for Installing 11.00 Systems Ignite-UX-11-11 C.6.0.66 HP-UX Installation Utilities for Installing 11.11 Systems Ignite-UX-11-23 C.6.0.66 HP-UX Installation Utilities for Installing 11.23 Systems 4. To launch Ignite-UX, enter: # ignite Now, you can create archives for different hardware architectures from this Itanium 2-based server. The same steps can be used on PA-RISC servers to accomplish the same thing. =============================================================================== 1.13 Q: Why does installing or recovering a client via NFS from an HP-UX 11i v1 Ignite-UX server take so long compared to an 11.0 server? A: To answer this we need to look at some background before looking at what options are available for resolving this issue. If you use 100BT or 1000BT interface,s you must check the duplex setting of the port on the switch that the Ignite-UX client is connected to. When a client boots, the kernel driver automatically negotiates the speed and duplex settings of 100BT and 1000BT interfaces. If autonegotiation fails, the interface defaults to half-duplex (the speed may vary depending on the speed of the switch port). When a normal client boots, its startup scripts are used to change the interface speed and duplex values to match that of the switch port. If the switch port is set to full duplex, you will have a duplex mismatch. This causes a problem for interfaces connected to switches that have not been set to autonegotiate. These interfaces will run at half duplex for the duration of the installation. From observation the duplex value reduces the throughput that NFS over TCP can achieve, but NFS over UDP performance does not seem to suffer. Ignite-UX uses an 11i installation kernel with versions Ignite-UX B.3.x, so if the Ignite-UX server is an 11i system the transport for NFS will be TCP and performance will suffer. HP-UX 11.0 only uses UDP for NFS by default so the performance problems are not seen. There are several solutions available: 1. Change the switch duplex setting of the client being installed to autonegotiate for the duration of the installation. 2. Change the _hp_nfs_mount_opts in the INSTALLFS to force udp to be used as the protocol. For example: # instl_adm -d -F /opt/ignite/boot/INSTALLFS > /tmp/installfs.out Edit /tmp/installfs.out to add the following line: _hp_nfs_mount_opts="-oproto=udp" (or change the _hp_nfs_mount_opts variable if it already exists to add -oproto=udp) then save the changes back into the INSTALLFS after saving the file: # instl_adm -F /opt/ignite/boot/INSTALLFS -f /tmp/installfs.out 3. Ignite-UX version B.4.1 and above provides the libraries needed to use the lanadmin -X option with 100BT and 1000BT interfaces on PA-RISC clients. You can add the lanadminoptions to be applied to a LAN interface with the _hp_lanadmin_args variable in the INSTALLFS use the same commands as in option 2. An example of what you would need to add to put a 100BT LAN interface into 100 full duplex mode would be: (lan[].driver == "btlan") { _hp_lanadmin_args="-X 100FD" } Please consult the documentation for lanadmin(1M) for more information about the options that are available. 4. Store your recovery archives and golden images on an 11.0 NFS server, because NFS will use UDP as the transport. This also works around the issue. Note that this would involve manual changes to your existing Ignite-UX configuration files to point a recovery or installation process to the correct NFS server. Note: If the Ignite-UX server is multi-homed and connected to one or more non-ethernet networking technologies over which it provides Ignite-UX installation/recovery services, you should consider options 1, 2, or 3 only. Ignite-UX will attempt to use the _hp_lanadmin_args settings on the network interface you are using for installation. (You will see errors from lanadmin if the options you have provided are not applicable to that interface.) =============================================================================== 1.14 Q: Why can I not use Ignite-UX with my Rev. A C3700/J6700 systems? A: The Rev. A C3700 and J6700 models were two short-lived systems that had the PA-8700 2.2 chipset revision and 1.6 firmware revision. They were only supported on HP-UX 11.00. Since the WINSTALL kernel is 11i v1-based and PHKL_27152 (or one of its predecessors) is included in that kernel, it is not possible to boot the installation kernel on these systems. They must be upgraded to Rev. B, which includes the PA-8700 2.3 chipset. There is a service note, A7277A, which addresses this situation. =============================================================================== 1.15 Q: My VxVM installation has stopped with the message: ERROR: Disk group dg02:cannot create: Disk group exists and is imported. What is the problem and how can I resolve it? A: This is a known issue with Ignite-UX and VxVM installations involving disk group names that were used on disks in a prior installation though not the current installation. Care should be taken when creating extra VxVM disk groups other than rootdg via the Ignite-UX GUI. During installation, no validation is done on a disk group name to see if it conflicts with a disk group name already in use for another unused disk on the system. If the name conflicts with another disk group, the attempt to create a disk group of the same name fails. This is a feature of VxVM to prevent the creation of duplicate disk groups. If you do encounter this problem, you are presented with something like the following: * Starting VxVM * Creating VxVM Disk "c17t13d0" (1/0/12/0/0/4/1.13.0). * Creating VxVM Disk "c17t12d0" (1/0/12/0/0/4/1.12.0). * Creating VxVM Disk "c17t11d0" (1/0/12/0/0/4/1.11.0). * Creating VxVM Disk "c17t10d0" (1/0/12/0/0/4/1.10.0). * Adding disk "c17t10d0" to rootdg. * Enabling VxVM * Creating disk group "dg01". * Creating disk group "dg02". vxvm:vxdg: ERROR: Disk group dg02: cannot create: Disk group exists and is imported ERROR: Command "/sbin/vxdg init dg02 dg0201=c17t12d0 dg0202=c17t13d0" failed. The configuration process has incurred an error, would you like to push a shell for debugging purposes? (y/[n]): If the affected disk group contains any important volume like /usr, /opt or /var, this installation is unlikely to succeed as those volumes are needed in order to boot and bring a system up. If the volumes are not essential, then it may be possible to ignore all the errors and the system may continue to boot. There may be additional VxVM errors beyond this initial one. - To continue and ignore the error, answer "y", and at the shell prompt type "exit 2". Then press return. Or - If you do not wish to continue the installation, answer "n". The system reboots, and then you must reinstall avoiding the use of duplicate disk group names. One potential workaround for this problem is to set the control parameter clean_all_disk to true in *INSTALLFS (refer to instl_adm(4) for more information on this keyword). However, this is not recommended in most instances and extreme caution is urged because when this variable is set to true, ALL the disks found on the system are cleaned, which may not be desirable. All data is lost on all disks on the system when this variable is set, even if the disks are not explicitly selected for the installation. In a SAN environment or MC/ServiceGuard cluster, the system you are installing may be able to see disks currently used by other systems. Setting clean_all_disks to true removes the data from them as well, which is not a desirable situation. However, this does clean off the disk group data from the other disks on the system, thus eradicating the duplicate disk group names. Note that LVM has the same sort of problem, but it would be observed when the duplicate group is imported back via vgimport. VxVM is different in that the problem is detected at volume group creation time. VxVM looks at all the disks on the system, and not just those selected for use in the current installation. =============================================================================== 1.16 Q: Is SecurePath (previously known as AutoPath) supported by Ignite-UX during installation or recovery? A: The SecurePath product is not supported by Ignite-UX for installation or recovery in versions prior to C.6.0.x; Ignite-UX version C.6.0 delivers support for SecurePath for Hsx disks in non-root volume group. However, any SecurePath for Hsx disks in the root volume group fail to be recovered using the Ignite-UX recovery tool for the following two reasons: 1. When the SecurePath for Hsx product is installed on a system, the hardware address of all EVA disk luns change once the product is installed and the system reboots. During the recovery process, if LVM volume groups exist on the EVA array, importing those volume groups may fail. Further, if the boot disk resides on an EVA array, the system fails to boot and is most likely due to an LVM configuration failure panic. 2. The SecurePath for Hsx product is not included in the installation kernel and is not part of the core HP-UX Operating System, so Ignite-UX is unable to fully support the use of this product. =============================================================================== 1.17 Q: Why is install.log so difficult to read? A: The installation messages that are logged into install.log are obtained by Ignite-UX from multiple sources including the standard output (stdout) and standard error (stderr of Software Distributor and the contents of swagent.log. It is not possible to control how these messages are logged into install.log, thus the file can be confusing. If you want to verify the installation of a product, HP recommends that you examining the swagent.log file directly, rather than the Ignite-UX install.log file. =============================================================================== 1.18 Q: Why does "Match What Target Has" not work on the Ignite-UX.BOOT-KERNEL-?A filesets prior to Ignite-UX C.6.0? A: The Ignite-UX.BOOT-KERNEL-?A ancestor was incorrectly set when including these two filesets in the product specification file (PSF). Since these filesets did not have a correct ancestor, they could not be matched with the "Match What Target Has" directive in the swinstall GUI. This problem was corrected with the C.6.0 version of Ignite-UX. The workaround for this problem is as follows: 1. To copy the Ignite-UX depot to a new location for modification, enter: # swcopy -s $PWD/<current_package_location> B5725AA \ ＠ /tmp/B5725AA.depot 2. To use the swlist command to display the current ancestors for the filesets, enter: # swlist -a ancestor -l fileset ＠ /tmp/B5725AA.depot Messages similar to the following appear: Ignite-UX Ignite-UX.BOOT-KERNEL-IA HPUX-Install.BOOT-KRN-700 Ignite-UX.BOOT-KERNEL Ignite-UX.BOOT-KERNEL-PA HPUX-Install.BOOT-KRN-700 Ignite-UX.BOOT-KERNEL 3. To add the missing ancestor to the Itanium-based fileset, enter: # swmodify -a ancestor=Ignite-UX.BOOT-KERNEL-IA \ Ignite-UX.BOOT-KERNEL-IA ＠ /tmp/B5725AA.depot 4. To add the missing ancestor to the PA-RISC fileset, enter: # swmodify -a ancestor=Ignite-UX.BOOT-KERNEL-PA \ Ignite-UX.BOOT-KERNEL-PA ＠ /tmp/B5725AA.depot =============================================================================== 1.19 Q: Why is the message 'Cannot open /dev/vx/rdsk/rootdg/standvol' output during an IPF install via golden image? A: It is caused by the major number change between B.11.23 first release and B.11.23 September 2004 for vxvm volumes. You will see this message if the golden image was created on a system running B.11.23 first release, and then the golden image is installed using version 'C' of Ignite-UX. You can move the kernel build a little earlier in the process to avoid the message, though the message is not harmful. post_load_cmd += " unset SW_INITIAL_INSTALL /usr/sbin/mk_kernel -f -o /stand/vmunix " =============================================================================== ---------------------------------------- 2. Server Setup ---------------------------------------- 2.1 Q: Should I use DHCP or bootp? A: As with anything, there are some advantages and disadvantages to both BOOTP and DHCP. In general, DHCP allows you to specify more complete networking information. However, there are no really good tools to manage the database so that you can enforce the LLA <-> IP-address mapping ahead of time. By its very design, DHCP dynamically allocates addresses. You will probably want to use the Ignite-UX GUI to set up the range of IP addresses that you will want your server to manage with DHCP, if you have not already done so. You need to use SAM to make any future changes to the DHCP address pool. If you are dealing with multiple subnets you will either need to have one DHCP server on each subnet or set up bootp relay agents. See question 5.4 (I do not want to use DHCP, can I still have Ignite-UX automatically determine networking information for all my clients?) also. =============================================================================== 2.2 Q: Why did it call my client "<hostname>.0x080009...."? A: If your client has multiple LAN interfaces, and you have previously installed the client using one interface, and then later chose to use the other interface during the installation, then the client name will have the LLA (link-level address) appended to the host name so that it does not conflict with the prior host name left from the prior installation. This may also happen if you had to replace the LAN interface in your client since the last time you installed it. The LLA number is attached to the LAN interface, not the client. It is only the name of the icon that has been renamed. You can use the Ignite-UX GUI "Action" menu to "Change icon name" to rename one or both of the clients. =============================================================================== ---------------------------------------- 3. Configuration Files ---------------------------------------- 3.1 Q: What should go in which configuration file? Also, what should go in INSTALLFS? A: Here is a short description of the common uses of the various configurations. Obviously, there can be situations that are not "common" and variations will occur: - INSTALLFS (accessed/modified via instl_adm(1M)) - Information that is needed at boot, such as GUI controls and networking. - /var/opt/ignite/config.local - Information that should be globally applied to all clients and defines the post_[load/config]_scripts run on all clients. - /opt/ignite/data/Rel_<release>/config - This file sets the definitions for that release and should not be modified. - /var/opt/ignite/date/Rel_<release>/*_cfg - Information regarding software selections/sources. These files should be created by make_config(1M) (run against an Software Distributor depot) or in the archive case, edited versions of the examples in /opt/ignite/data/examples/[core|noncore].cfg. When Ignite-UX is run for a client, all of these configuration files are combined and parsed. If there are conflicting or duplicate definitions, the order in which the files appear in the INDEX file determines the precedence with the last file listed (typically config.local) having precedence over all but the INSTALLFS definitions. A potential breakdown can occur if the client was previously installed and the per client directory in /var/opt/ignite/clients exists and is populated with the previously resolved configurations. In this case, the previously resolved config.full has precedence. =============================================================================== 3.2 Q: How do I preview configuration file changes? A: DESCRIPTION: Fixing syntax problems with mod_kernels results in statements of the following form: mod_kernel += "maxdsiz " + ${_maxdsiz} There does not seem to be a way to preview the effects of these types of statements. Can a comment be added to the config.full with the string that was being output? SOLUTION: The config.full file has the variable values replaced with the real values so if you review this file, you should be able to see what the real mod_kernel statement has become. In this case, you would see the following: mod_kernel += "maxdsiz 0" Another option would be to have the configuration file push a shell prior to the kernel build using a post_load_cmd: post_load_cmd += "/sbin/sh;" =============================================================================== 3.3 Q: Is there a way to set the configuration files to ignore the disk warnings, which can prevent automated installations? A: We do have an environment variable which should do what you need. Look in instl_adm(4) for INST_ALLOW_WARNINGS. This can be used to keep you from going interactive when warnings are received. You will need to put the setting of this environment variable in INSTALLFS for it to have effect. The line you would add to allow an automated installation to proceed after the warning is as follows: env_vars += "INST_ALLOW_WARNINGS=10" =============================================================================== 3.4 Q: Which configuration file example should I use for an HP-UX 11.00 archive? A: For setting up an operating system archive for the 11.00 releases, use the configuration file example /opt/ignite/data/examples/core11.cfg as a starting point. A failure to use the core11.cfg file, or a failure to correctly modify the file results in the following message: ERROR: The _hp_os_bitness variable is not set to 32 or 64. This variable must be set in the configuration file that supplies the core archive or depot. If using an archive, make sure you start with the core11.cfg example configuration file. When using a depot, make_config will set this automatically. =============================================================================== ---------------------------------------- 4. Recovery (make_tape_recovery & make_net_recovery) ---------------------------------------- 4.1 Q: We tried running the recovery system option from a client booted in Ignite-UX, which generated errors. What files need to be accessible for tftp? A: Only /opt/ignite and /var/opt/ignite are needed for tftp access. =============================================================================== 4.2 Q: How do I duplicate a tape made with make_recovery? A: For this information, refer to copy_boot_tape(1M). =============================================================================== 4.3 Q: How do I deal with hot-swappable disk devices during recovery? A: Ignite-UX only supports hot-swappable disks that are completely installed and present 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 transitional state. If this command is not working, then recovery has no chance of succeeding. =============================================================================== 4.4 Q: What is the maximum amount of data that a make_recovery tape can hold? A: A make_recovery tape can hold as much data as will fit on the tape. If make_recovery is run in the foreground it prompts for more tapes if they are necessary. Note: Individual files on HP-UX 11.00 may not exceed 2 GB due to a limitation in the pax command. Files from HP-UX 11i v1 on may be larger than 2 GB, but may not exceed 8 GB. =============================================================================== 4.5 Q: How do I boot correctly from a recovery tape on a V-class system? A: When booting from a recovery tape on a V-class system using an incorrect boot string, it is possible that the following errors are generated: Command: bo 4/2/0.1.0 VINSTALL Device : 4/2/0.1.0 File : hpux Arguments : hpux VINSTALL Loading : hpux.....175984bytes Loaded 110448 + 65536 + 865264 start 0xd01c88 Boot :tape(4/2/0.1.0;0)VINSTALL tape(4/2/0.1.0;0)VINSTALL:cannot open, or executable Exec failed : No such file or directory The correct method for booting any kernel from a tape is to add a colon (:) to the start of the kernel name. The colon tells the bootloader that it must read the kernel from the LIF at the start of the media. Without the colon, the bootloader attempts other methods to read the kernel, but it does not attempt to install it from a LIF. The above errors are the result of the bootloader attempting to read the kernel from an HFS file system, which on a tape is not possible. Older releases of the bootloader prepended a colon (:) to the VINSTALL kernel name. The bootloader for 11i v1 does not allow for this behavior. In this case, the correct boot string would be: bo 4/2/0.1.0 :VINSTALL Not: bo 4/2/0.1.0 VINSTALL For machines other than the V-class, always use :INSTALL to represent the installation kernel when manually booting from tape or an installation CD. The bootloader automatically changes it to :WINSTALL on systems that require a 64-bit kernel for installation. =============================================================================== 4.6 Q: How do I include all volume/disk groups into a recovery tape? A: To include all volume and disk groups on the system into a recovery tape (can be used with make_net_recovery as well) use the following command: # make_tape_recovery -A -x inc_cross=/ The make_tape_recovery man page defines inc_cross as follows: -x inc_cross=file|dir Includes the file or directory in the recovery archive and crosses mount points to access any directories that are mounted or files contained in directories that are mounted. =============================================================================== 4.7 Q: Are multi-byte characters supported in file names in Ignite-UX? A: At this time, multi-byte characters are not supported in file names. =============================================================================== 4.8 Q: Can you move a volume that was created in a non-root volume to the root volume during recovery? A: When you recover a system using a recovery archive, you can extend the existing logical volume size in the Ignite-UX GUI, "File System" tab. However, the current tool does not allow you to create a new logical volume instead of using the old one. =============================================================================== 4.9 Q: How can I create empty volume groups during system restoration? A: When using make_*_recovery tools in an off-site disaster recovery situation, you may desire to have all the volume groups on the system recreated during the restore operation even though only the root volume group data is backed up with make_*_recovery. This may be the case when you use other tools (such as fbackup/frecover, Veritas netbackup, Omniback, etc.) for backing up the non-root data. This can be accomplished by specifying at least one file in each non-root volume group to be included in the backup. The way the make_*_recovery works is that if any files from a volume group are included, the restoration process will recreate that volume group during the recovery. So if only one file is specified for inclusion from the volume group, the entire group will be recreated, and of course, that one file will be restored. A more complicated command line would be necessary to accomplish this, and "-A" would no longer be an option (which is what is used today). An example would be: make_net_recovery -x inc_entire=vg00 \ -x include=/myDataVolume/anyFile ... This would backup the entire vg00 volume group and the one file "anyFile" from the directory "myDataVolume". Assuming that myDataVolume is on the other volume group, the layout of the other volume group will be saved and restored during recovery (along with "anyFile"). =============================================================================== ---------------------------------------- 5. General Install ---------------------------------------- 5.1 Q: How does Ignite-UX estimate needed file system sizes? Does it do anything other than add up the impacts statements? A: Ignite-UX adds in minfree (normally 10%) to the amount required by the software impact. You may have software bundles that have overlapping contents: filesets and/or files. The make_config command makes sw_impact statements for each bundle without doing anything special to guard against over-counting when the bundles overlap. For example, the Ignite-UX-11-XX bundles all overlap so when you install all of them using Ignite-UX it estimates too much space. You should be able to add the sw_impact of all the sw_sels that you are installing and to calculate the required file system size. =============================================================================== 5.2 Q: When does Ignite-UX configure software? A: The Software Distributor configuration and Ignite-UX "post_config_cmd" and "post_config_scriptd" scripts are run after all software has been installed and the client has booted the final kernel from the target disk. =============================================================================== 5.3 Q: How do I set the client's final networking information? A: This can be done from the "System" tab of the Ignite-UX GUI, or using the keywords in the configuration files (refer to instl_adm(4)). =============================================================================== 5.4 Q: I do not want to use DHCP, can I still have Ignite-UX automatically determine networking information for all my clients? A: Yes. If you want more control over the allocation of IP addresses and their mappings to your clients, you can configure entries in /etc/bootptab for each client. Because BOOTP is a subset of DHCP, the client's request for a DHCP server is satisfied with the BOOTP response. If you also specify a boot file (bf) of /opt/ignite/boot/boot_lif in the bootptab entries, then you do not need any additional entries in /etc/opt/ignite/instl_boottab. In this case, you would then boot the clients using "boot lan" instead of "boot lan install". Only clients known in /etc/bootptab would be able to boot if you do not use instl_boottab. sysname:\ hn:\ vm=rfc1048:\ ht=ether:\ ha=080009352575:\ ip=15.1.51.82:\ sm=255.255.248.0:\ bf=/opt/ignite/boot/boot_lif Note: There is a known problem using this mechanism that you should review; see question 1.6 (Using bootptab entries to satisfy the DHCP request does not work. Why?) also. =============================================================================== 5.5 Q: How can I make software in a depot available for installations? A: You should change to the release directory that is appropriate for the software in the depot, then run make_config against the depot. After the configuration is created, run manage_index to make it visible in the Ignite-UX GUI. For example, for the following situation: SD depot machine: sdsource SD depot: /var/application_depot For release: 11.23 You would execute the following: # cd /var/opt/ignite/data/Rel_B.11.23 # make_config -s sdsource:/var/application_depot -c app_name.cfg # manage_index -a -f /var/opt/ignite/data/Rel_B.11.23/app_name.cfg \ -c "HP-UX B.11.23 Default" =============================================================================== 5.6 Q: FDDI software is included in my archive, yet Ignite-UX requires that I select it. Why? A: Ignite-UX generates an error indicating that you must select the FDDI software for installing if the following conditions exist: - You are using an FDDI interface during the installation. - There is a sw_sel defined in a configuration file that has the string FDDI in the description. Ignite-UX provides the error prior to starting the configuration phase to avoid the client being unable to complete the installation due to the lack of the FDDI drivers. Ignite-UX does not have any way of detecting the inclusion of FDDI software in an archive so it assumes that it is not. If you have the FDDI software in the archive, you can avoid the error by removing it from your depot then rerunning make_config to reflect the removal in the associated configuration file. Alternatively, you can select the FDDI software, which causes the swinstall command to skip installing it since it is already on the client. =============================================================================== 5.7 Q: How many clients can I install simultaneously or in parallel? A: Although there are no set limits in Ignite-UX, you will find that performance decreases as you reach the limits of your network and server bandwidth. Most users have found that installing about twenty (20) clients at a time, from a single server, is the limit while maintaining reasonable performance and avoiding network errors. This seems to be a reasonable number for you to keep track of and test when the installations complete. Also, you may find it useful to stagger the installations so that they are not all doing the same operation at the same time, thus do not all complete at the same time. Using the NFS access method to access archives is suggested in order to avoid a problem that occurs when installing many clients using the ftp access method. When many ftp and tftp processes are running to a server at once, the tftp commands start generating the following error: tftp: recvfile: recvfrom: Can't assign requested address =============================================================================== 5.8 Q: My installations are hanging; what is going on? A: In certain circumstances installations may hang and could be due to a problem with swagentd. If you are using an operating system archive, the hang occurs after the following message appears in: * Running "/opt/upgrade/bin/tlinstall -v" and correcting transition link permissions. If you are using swinstall only, the hang occurs after the following message appears in install.log: * Setting primary boot path to "<some hardware path>" At this point in the process, Ignite-UX attempts to start swagentd. Because of a signal problem with swagentd, the parent process waits infinitely for a signal from the child process which cannot occur. If you press "CTRL-C" on the client console, you see a message similar to the following appears: NOTE: run_cmd: Process: 223 (/usr/sbin/swagentd): killed by signal: 2. ERROR: swagentd returned an error. You are asked if you want to push a shell, and you should answer yes. You can exit, and then ask Ignite-UX to ignore the problem to continue the installation. Ignite-UX falsely believes that swagentd has not started and attempts to start it whenever it does a subsequent swinstall. This results in an error because the child process is in fact running. Assuming no other problems occur, the installation should complete successfully. Ignite-UX has incorporated patched versions of swagentd into its SYSCMDS archives. However, if you are using an operating system archive the archive may contain an older unpatched swagentd that gets deposited on top of the SYSCMDS version. This older, unpatched version then gets used and the hang may occur. In this case, the operating system archive requires a patched swagentd to fix the problem, and then it must be rebuilt. If this is not possible, you can instead use a post_load_cmd script to copy a fixed swagentd from the Ignite-UX server onto the client after the archive is unpacked. Note that changing seemingly unrelated things like disk drives, file system layout, language choice, and so forth, may eliminate the hang though this is not guaranteed. =============================================================================== 5.9 Q: How large can I create a single swap space using Ignite-UX? A: In general, Ignite-UX allows you to create up to 32 GB of swap space in total during the installation process. Any amount of swap space in excess of 32 GB is not enabled by Ignite-UX. It requires adjustment of the kernel parameters swchunk and maxswapchunks post installation to fully enable any amount exceeding 32 GB. There are individual size restrictions on the primary swap and all dump logical volumes that depend on operating system revision and firmware limitations in disk controllers. These volumes are limited in how far they can span from the beginning of the physical disk. The limits for HP-UX 11.00 and later are 4 GB or limited only by size of disk, depending on firmware. (Most PCI controllers and more modern systems do not impose specific limits. Older systems, like K and D series, do have restrictions on dump.) If these limits are exceeded, Ignite-UX produces an error message and the installation is not allowed to proceed. To use a large amount of swap, you must ensure that you have sized the swap related kernel parameters to allow for the total swap space configured. Ignite-UX automatically increases the kernel tunable maxswapchunks up to its maximum of 16384 to allow for more swap. If the amount of swap created is more than 32 GB, you must increase the kernel tunable swchunk from its default of 2048. Ignite-UX will not do this automatically. If there is insufficient kernel resources configured to allow you to use the swap being created, you a message appears indicating this during the installation process. This message may not be accurate if you change swchunk using a configuration file as Ignite-UX assumes that swchunk is 2048 and does not take into account any changes to its value. You can manually increase swchunk once the installation process is complete using SAM. To increase swchunk during an Ignite-UX installation you can place a line like the following in the Ignite-UX configuration: mod_kernel += "swchunk 4096" With swchunk set to 4096, you are able to utilize up to 64 GB of swap, assuming that Ignite-UX had to set maxswapchunks to its maximum value of 16384. Note: Ignite-UX does not detect any changes you make to swchunk, it limits the total size of all swap space to 32 GB. To calculate how much swap can be utilized you multiply swchunk by maxswapchunks, for example: 16384 * 4096 = 67108864 Since swchunk is measured in KB 67108864 / (1024*1024) = 64 GB. Ignite-UX lets you configure more space in swap space than what the kernel can use so getting swchunk and maxswapchunks set correctly for a large configuration is important. Currently the maximum supported value of swchunk is 16384. This gives a total of 256 GB of addressable swap with both swchunk and maxswapchunks set to 16384. Try not to over configure the amount of swap that can be addressed when setting values for maxswapchunks and swchunk. These values are used to allocate kernel memory that is used to keep track of swap resources, setting them too large wastes memory. To efficiently use kernel memory keep swchunk as a power of 2 (for example: 2048, 4096, 8192, 16384, etc.). When choosing values try to keep swchunk to the lowest value that you can, and then choose the value needed for maxswapchunks to address the swap needed. On a system that actively swaps memory to a swap space there may be performance implications when increasing swchunk past its default of 2048. The HP-UX Memory Management White Paper (mem_mgt.txt located in /usr/share/doc) contains detailed information about how swap is controlled inside the kernel. Additionally, to create logical volumes as unused logical volumes rather than swap logical volumes you can configure them to be used for swap after the installation process has completed. This is only important if you need the swap spaces allocated in a particular order. =============================================================================== 5.10 Q: Why do the text fields in the Ignite-UX TUI not accept my input, and the dialogs re-open or loop? A: The text fields within the Ignite-UX TUI do not recognize keyboard input when the "Insert" key is active. Make sure that the the "Insert" key is inactive when entering data in the TUI by pressing it. =============================================================================== ---------------------------------------- 6. Network Install ---------------------------------------- 6.1 Q: When the client searches for bootable devices, the Ignite-UX server does appear on the list. When I try to boot, I get the error: IPL error: bad LIF magic. Why? A: Typically, this has been caused by one of the following situations: - Not having tftp access to /opt/ignite and /var/opt/ignite, the /etc/inetd.conf file on the server should have an entry similar to: tftp dgram udp wait root /usr/lbin/tftpd tftpd\ /opt/ignite\ /var/opt/ignite If not, fix inetd.conf and run "inetd -c". Kill any tftpd processes that may be running. Installing Ignite-UX should set inetd.conf. - Using a tftp entry for the client that is referencing a nonexistent boot file (bf). - A corrupted /opt/ignite/boot/boot_lif file. - Some remnants of the old cold installation product are conflicting with Ignite-UX. For example, an old instl_bootd is running. =============================================================================== 6.2 Q: I set "control_from_server=true" and "run_ui=false" in the INSTALLFS, but I still get prompted for information on the client. What is wrong? A: Review the following possible answers dependent on the prompt that you received: - If the screen is showing the client name in an editable field and a "Cancel" button at the bottom of the screen, then all is well and there should be an icon waiting for you in the Ignite-UX server GUI. The text screen allows you to change the icon name, or switch to a client-side installation. - If the screen is showing two or more LAN interfaces to select from, there was not enough information in the configuration files to tell it which LAN to use. Once you select a LAN, and then select "HP-UX" and the installation continues. - If the screen is prompting you for networking information, then either DHCP did not respond or there is not an entry in /etc/bootptab for the client. Enter the network information, select "Install HP-UX" and continue the installation. =============================================================================== 6.3 Q: The bootsys command seems to work in reverse; if we typed: # bootsys -w client the client did not wait for the server, if we typed: # bootsys client the client waited for the server. Why? A: This is probably because you ran through the GUI once on the Ignite-UX server prior to running the bootsys command. The server drops the instruction for the client to start installing and the next time the client boots it uses this dropped instruction. The message Ignite-UX generates attempts to tell you that the installation will happen the next time "bootsys -w" is used, but does not indicate that it happens automatically. It is likely that the next time you executed a bootsys command, you had not used the GUI without the client being booted from the Ignite-UX server. =============================================================================== 6.4 Q: When executing "search lan install" on the client, the Ignite-UX server does not appear in the list. Why? A: Check the following on the Ignite-UX server that you are trying to boot from are: - Messages from instl_bootd in /var/adm/syslog/syslog.log. If you need to add more IP addresses to /etc/opt/ignite/instl_boottab, messages are written to syslog.log similar to the following: instl_bootd: Denying boot request for host: 080009F252B3 to avoid IP address collision. Try booting again in 214 seconds, or add more IP addresses to /etc/opt/ignite - A message in syslog.log that indicates that you have no IP addresses in /etc/opt/ignite/instl_boottab similar to the following: instl_bootd: No available IP address found in: /etc/opt/ignite/instl_boottab =============================================================================== 6.5 Q: The bootsys command fails due to insufficient space in the /stand volume. Why? A: The bootsys commands needs to copy the two files: # /opt/ignite/boot/Rel_<release>/*INSTALL # /opt/ignite/boot/Rel_<release>/*INSTALLFS where <release> is the operating system release, from the server into the client's /stand directory. This error indicates that there is not enough space in /stand on the client. To correct the error, you may need to remove any backup kernels. Additionally, check for kernels in the /stand/build directory (like vmunix_test). =============================================================================== 6.6 Q: Can I have the Ignite-UX server and client on different subnets? A: Yes. It requires that you setup a boot-helper on the remote subnets, or limit yourself to using the bootsys command. Because the network boot firmware uses a broadcast BOOTP packet to find an Ignite-UX server to boot from, these packets do not normally cross over subnets. This limits clients to booting from Ignite-UX servers only on their local subnet. When your Ignite-UX server is on a remote subnet, you have basically three options: - Set up a boot-helper system on the client's subnet that has the IUX.MinimumRuntime product installed. This boot-helper system provides the client with the ability to boot the INSTALL kernel, and then contact the server once it is booted. For more information, refer to Appendix B in the "Ignite-UX Administration Guide" at: http://docs.hp.com/en/IUX/infolib.html - Use the bootsys(1M) command from the Ignite-UX server to initiate the installation of the client. The bootsys command copies the *INSTALL and *INSTALLFS files to the client's local disks and instructs it to boot from them. This option avoids the need to do a network boot. - Create a minimal bootable tape or CD to boot from, and then point the client to the Ignite-UX server once it is booted. For more information, refer to make_medialif(1M). =============================================================================== 6.7 Q: My Itanium 2-based client fails to boot with a PXE-E16 error. Why? A: A "PXE-E16: Valid PXE offer not received" error indicates that the client did not receive a valid message from either a BOOTP or DHCP server. Itanium2 based clients differ from PA-RISC clients because the Ignite-UX instl_bootd boot protocol server can not be used. The "Configure Booting IP Addresses" button on the "Server Configuration" tab of the Ignite-UX GUI and the /etc/opt/ignite/instl_boottab file do not apply to Itanium 2-based clients. Instead, a BOOTP/DHCP server such as HP-UX bootpd must be configured and /etc/bootptab entries made for each client. If this Ignite-UX server has been configured and the client still does not boot, the following is a checklist of items to verify: Check inetd for the following: ___ Check /etc/inetd.conf to make certain bootps and tftp entries have been uncommented. ___ Was inetd restarted or given an option to re-read the configuration files (inetd -c), after they were edited? Is the inetd process running? ___ Check for entries in /var/adm/inetd.sec that may cause inetd to deny service to certain clients. ___ Check /var/adm/syslog/syslog.log to make certain inetd was restarted, and that no bad messages were found. Check for messages from bootpd and tftpd. Check bootpd for the following: ___ Check the /etc/bootptab entry. Make certain the MAC address matches the client MAC address. Use "dhcptools -v" to validate the format of the /etc/bootptab file. ___ Check for entries in /etc/dhcpdeny to insure that bootpd is not set up to deny service for particular clients. ___ Check /var/adm/syslog/syslog.log for a message from bootpd that indicates it was started when a bootpd packet was received. Check tftpd for the following: ___ Check the tftp line in /etc/inetd.conf to make certain /opt/ignite and /var/opt/ignite directories are listed. ___ Check the tftpd connection manually by using the tftp command; for example: prompt% tftp [server-name] tftp> get /opt/ignite/boot/nbp.efi /tmp/nbp.efi Received n bytes in s seconds =============================================================================== ---------------------------------------- 7. Media Install ---------------------------------------- 7.1 Q: Why do I get DCE/RPC errors (RPC exceptions) during the configuration stage? A: In addition to these errors, there is a 10+ minute hang at the end of the SD configure stage and a failure message appears at the end of the installation. There is an apparent problem with certain SD operations (for example, swacl) when only loopback networking is enabled. This occurs if the media-only installation option is selected. The workaround is to install using the "media with networking enabled" option and set up these networking parameters: hostname, IP address, netmask, routing, etc. This allows the Software Distributor operations to complete normally. =============================================================================== 7.2 Q: How can I put an operating system archive on multiple CDs? A: If the archive you want to put onto a CD is too large, you should consider creating multiple independent archives each of which fits on a CD. The first archive should contain the core HP-UX directories; the remaining archives would contain the rest of the system. Use the following procedure to create these archives: - Determine what large (non-essential) directories can be omitted from the core operating system archive, and included it subsequent archives. In this example, we are assuming that the /opt directory will be put into a second archive. It may require some trial and error to exclude enough data to make an archive small enough to fit on the CD. In addition, keep in mind that the LIF data on the first CD requires space. - Create the first core operating system archive, use the make_sys_image command and use the -f option to specify a file that contains a list of directories that should be excluded. For example, if you want to exclude /opt from the archive, create a file (/tmp/specific_files) that contains: + NO_ARCHIVE /opt - Run make_sys_image as such: # /opt/ignite/data/scripts/make_sys_image \ -f /tmp/specific_files -s local -d /var/tmp - Create your second archive containing the rest of the system (in this example, the /opt directory). Note that the archive content must "not" contain absolute paths. This is especially true for core operating system archives, but is a good idea for other archives as well. Using pax to create the tar archive: # cd / # pax -wx ustar -f - opt | gzip > /var/tmp/archive2.tar.gz - Copy and edit the configuration file template /opt/ignite/data/examples/core11.cfg for the first core operating system archive. - Copy and edit the /opt/ignite/data/examples/noncore.cfg template file for the other archives. In addition to the changes required to make it work with a CD, make sure to change the sw_source definition in this file, to add the line: change_media=TRUE Now you can put these archives and configuration files on the CDs. The first CD contains the LIF data created using make_medialif as well as all the configuration files referencing all your archives. For more information, refer to make_medialif(1M) and the "Customized Install Media White Paper" at: http://docs.hp.com/en/IUX/infolib.html The second and subsequent CDs need to only contain a file system containing the archive. Do not use instl_combine on the subsequent CDs as they should not have a LIF area. =============================================================================== ---------------------------------------- 8. Archive Install (Golden Images) ---------------------------------------- 8.1 Q: What does the following gunzip error indicate? gunzip: stdin: unexpected end of file pax_iux: The archive is empty. ERROR: Cannot load OS archive (HP-UX Core Operating System Archives) A: It appears that the NFS mount succeeded, but the file was not accessible from the client. Check the following possibilities: - The file has a different name so check your configuration files for errors. - The file has the wrong permissions such that it is not readable so check your /etc/exports file. =============================================================================== 8.2 Q: The /etc/nsswitch.conf and /etc/resolv.conf files from my archive do not end up on the client. Why? A: There are certain files which Ignite-UX modifies during the configuration process, among them resolv.conf and nsswitch.conf. To end up with the archive versions of these modified files on your clients, Ignite-UX provides two scripts called os_arch_post_l and os_arch_post_c to aid you. These scripts are delivered in the /opt/ignite/data/scripts directory. You will probably only need to modify os_arch_post_l to achieve your goal. Copy this file to a new name in the same directory and then edit it searching on resolv.conf and nsswitch.conf for instructions regarding what must be changed. After the script has been changed, modify your configuration file that describes the archive so that it points to the new script. =============================================================================== 8.3 Q: What do these errors mean: pax_iux: X: Cross-device link, pax_iux: X: File exists, or pax_iux: X : Device busy? A: Both of these errors may occur when installing a client from an archive that does not have the same file system partitioning as the client on which the archive was created. The first error, "pax_iux: X: Cross-device link", is caused when two files exist as hard links in the archive, and if these two files would reside in separate file systems. For example, if you created an archive on a client that did not use LVM the root file system is all one file system and the files, /usr/local/bin/f1 and /opt/myprod/bin/f2, are hard linked. If you make an archive of this client then try to apply it to a client that uses LVM and has /usr and /opt as separate file systems this error occurs. The second and third errors, "pax_iux: X: File exists and pax_iux: X : Device busy", can occur when the archive has a symbolic link (symlink), or regular file that is named the same as a directory or mount point that exists when the archive is installed. For example if the original client on which the archive was made has a symlink like /opt/myprod -> /extra/space, and when you are installing a client from the archive you decide to create a mounted file system as /opt/myprod. The pax command fails to create the symlink because a directory exists in its place. You can recover from this failure when the error happens because, on the client's console, you are asked if you want to push a shell. Answering yes, and then typing exit 2 from the shell you can ignore the error and continue the installation. Once the client is up, you can more easily determine what to do with the paths that created the errors. To avoid the errors, the client that the archive is created from should not contain hard links between directories that are likely to be created as separate file systems. =============================================================================== 8.4 Q: What HP applications are tested for use with Ignite-UX? A: HP applications that have been tested with Ignite-UX have an OD1 option on the HP Corporate Product List (CPL), which indicates the factory integrate option. This option directs HP factories to install the software on the your client before it leaves the factory. HP manufacturing installs the software from a depot using the Ignite-UX process. You can install all HP applications identified with an OD1 ordering option from a depot. No applications are tested for proper installation or operation when included in a golden image archive that is installed with Ignite-UX. They may work fine in this mode but it is up you to verify proper installation and operation. Running "swconfig -x reconfigure=true \*" after installation may cause some software to properly configure itself after installing from a golden image archive. =============================================================================== ---------------------------------------- 9. Obtaining Ignite-UX ---------------------------------------- 9.1 Q: What is different about the Web version? A: Nothing, other than the software may be available prior to the media release. Additionally, you can download one depot containing all supported operating system releases. =============================================================================== 9.2 Q: Is Ignite-UX available on media? A: If you have subscription service for the Application Media Release then Ignite-UX is available to you on the media without a codeword. In other words, free. =============================================================================== 9.3 Q: How do I update my Ignite-UX server to a new version? A: In general, each new version of Ignite-UX is compatible with any scripts or configuration files that were delivered with older versions. If you follow some simple guidelines, updating to a new version of Ignite-UX involves running swinstall to install the new version; this is the same procedure as installing it for the first time. There is no need to remove the old version. Updating to a new version of Ignite-UX preserves any changes you have made to files under the /var/opt/ignite and /etc/opt/ignite directories. Changes to any files under /opt/ignite are "LOST" during the update. HP does not recommend changes to any files under /opt/ignite. Guidelines for ensuring easy updates: - Do not modify any files under the /opt/ignite directory. If you need to modify any configuration files under /opt/ignite, copy them to an equivalent directory under /var/opt/ignite then modify the INDEX file to use them in the new location instead. Some files and scripts contain comments that describe the recommended modification procedure to use. If you must modify files under /opt/ignite, then save a copy of your changes so you can restore the changes to the new files after updating Ignite-UX if necessary. - Make sure you install all of the Ignite-UX filesets you had previously so you do not end up with a combination of old filesets and new filesets. =============================================================================== 9.4 Q: How much of Ignite-UX do I need to install? A: Depending on what you are using Ignite-UX for, you may be able to reduce the disk space usage by not installing the full product. Below is a list of typical usages and a list of what parts of Ignite-UX you need. If you are not concerned with disk space, it is easiest just to install the bundles for the HP-UX releases you plan to work with. For all cases the IUX.IGNT-ENG-A-MAN fileset can be omitted or removed if you do not want on-line documentation. - Ignite-UX server to install HP-UX on clients - Install the Ignite-UX bundles for each HP-UX release which you plan to install onto clients. You can omit the IUX.OBAM-RUN fileset if your server is 11.10 or later. - Ignite-UX server to support network recovery for clients - Install the full Ignite-UX bundle for each version of HP-UX that your clients are running. - Using only make_recovery on clients - Install only the following filesets: Ignite-UX.RECOVERY Ignite-UX.BOOT-KERNEL Ignite-UX.FILE-SRV-<release> Ignite-UX.MGMT-TOOLS where <release> is the HP-UX release of the operating system you are running. - Using only make_net_recovery on a client - The filesets a client needs are normally installed by the Ignite-UX GUI to each client from the depot created by pkg_rec_depot(1M). The only filesets required for make_net_recovery on the client are: Ignite-UX.RECOVERY Ignite-UX.MGMT-TOOLS - A network boot helper system - To setup a client on a remote subnet that is used just to allow clients to boot from the network, and then contact a remote Ignite-UX server, all you need is Ignite-UX.MinimumRuntime. Keep in mind that it is not a good idea to install a combination of different versions of Ignite-UX filesets on a client. So if you decide to update just a subset of Ignite-UX, you may want to use swremove to remove the portions you no longer need. =============================================================================== 9.5 Q: How can I copy Ignite-UX from media to a local depot such that Ignite-UX from this new local depot will be installable on all HP-UX B.11.* systems? A: The media versions of Ignite-UX have the "os_release" attribute set to match the revision of the media (i.e., B.11.00 or B.11.11 or B.11.23, etc). A user may copy the Ignite-UX bundles from media into a local depot and run swmodify to change the value of the "os_release" attribute to be "wide open" (i.e., it will then be installable on all HP-UX B.11.* systems). See the sample script at: /opt/ignite/data/scripts/examples/open_media_iux =============================================================================== ---------------------------------------- 10. Loading Patches ---------------------------------------- 10.1 Q: Can patches be installed with software? A: Yes. The "load_order" keyword can be used inside the sw_source to force the patches to be installed after the software they are intended to patch. Also, the "sd_command_line" keyword can be used to specify the Software Distributor option as follows: -x match_target=true HP-UX 11.00 core operating system patches should reside in the same depot as the 11.00 core operating system. This difference resulted from the changes made to Software Distributor to be "patch smart". =============================================================================== 10.2 Q: How do I prevent backup copies of patched files from being saved? A: When installing HP-UX patches from SD depots, the normal behavior is that the patched files are saved in case you want to remove the patch at a later date. However, this takes up additional space in the /var directory so you may want to turn that feature off. This feature is controlled by an option to the swinstall command as follows: -x patch_save_files=false|true You can use the "sd_command_line" keyword either at the global level, or within individual sw_source clauses depending on whether you want it to be specified for all installations or just certain ones. Be aware that for patches in the core depot, this option is specified by the /opt/ignite/date/Rel.B.11.**/hw_patches_cfg file. It is controlled by the configuration file variable, _hp_patch_save_files, and made visible to the user in the "Additional" tab of the Ignite-UX GUI. To specify this option at the global level (for example in the /var/opt/ignite/config.local file), you can add the following line: sd_command_line += "-xpatch_save_files=false" To set the default variable that controls the core patches to "NO", add the following line to config.local (which must be listed after hw_patches_cfg in the INDEX file): init _hp_patch_save_files = "NO" =============================================================================== 10.3 Q: Why do I get errors from swinstall regarding patches in HP-UX 11.00 depots? A: If you see errors similar to the following: ERROR: The fileset PHSS_16931.C-KRN,l=/,r=1.0 is a sparse or patch fileset which may only be installed upon a previously installed base fileset. The specification for the required base fileset is OS-Core.C-KRN,l=/,r=B.11.00. Since fileset OS-Core.C-KRN,l=/,r=B.11.00 is being excluded due to the errors shown above, fileset PHSS_16931.C-KRN,l=/,r=1.0 will also be excluded. A likely cause is that during the installation of the core operating system the version of swinstall that Ignite-UX placed on the client was replaced with the original (non-patched) version of swinstall that contained issues regarding patch handling. The solution is to ensure that all HP-UX 11.00 core operating system (ACE/HWE/XSW) patch bundles and individual patches reside in the same depot as the core operating system. This configuration ensures that the patches to swinstall are installed in the same session as the rest of the core operating system, thus there is never a point in time when a prepatched swinstall can be used during the installation. =============================================================================== 10.4 Q: Why are patches left in an installed state when I install the Support Plus patch bundle along with HP-UX 11.x from CD? A: When Ignite-UX installs the core operating system and patch bundle from the Install CD, it installs the software with the SD-UX option "defer_configure" set to true, and then the Support Plus patch bundle is installed. Ignite-UX can install patches that supersede patches installed as part of the core operating system patch bundle. Superseded patches cannot be moved into a configured state by swconfig when it is eventually performed. This is because the superseded patches now on the client are no longer applicable to that patch, it is only applicable to the patch that superseded it. To correctly determine if a patch is really in an installed state you should look at the setting of both "patch_state" and state in the swlist output. For example: # swlist -l patch -a state -a patch_state | grep PH If the "patch_state" is applied (the patch has not been superseded) and the state is installed, this may indicate an issue and you should configure the patch with the swconfig command. If the "patch_state" is superseded or committed, you do not have to worry about the state. However, if you remove any patches and a previously superseded patch changes to have a "patch_state" of applied, you must run swconfig manually to configure the patch if its state attribute is installed. Note: Do "NOT" manually modify the state attribute of an installed or committed patch to be configured with the swmodify command. =============================================================================== ---------------------------------------- 11. Network Recovery ---------------------------------------- 11.1 Q: How can I learn more about network recovery? A: In addition to the information in this FAQ, there are several other sources of information on network recovery: - The "System Recovery" chapter in the "Ignite-UX Administration Guide" at: http://docs.hp.com/en/IUX/infolib.html - These manpages are applicable to network recovery are as follows: * make_net_recovery(4) * make_boot_tape(1M) * pkg_rec_depot(1M) * instl_adm(1M) * instl_adm(4) * ignite(5) - The Ignite-UX Release Notes that detail new features, enhancements and known problems with the product. It is located in Information Library and in the /opt/ignite/share/doc/release_note directory. =============================================================================== 11.2 Q: How can I clone a client using make_net_recovery? A: 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 client to install a different client involves manually copying some configuration files, and allowing NFS access to the source client's archive. The steps to clone a client using make_net_recovery are as follows: 1. Use make_net_recovery or the Ignite-UX GUI to create a recovery archive of the source client. 2. Login to the Ignite-UX server. 3. If the client to be installed does not currently have a directory in /var/opt/ignite/clients on the Ignite-UX server but is up and running, then use the Ignite-UX GUI to create that directory using the "Add New Client for Recovery" task. If the client is not running, you either need to boot the client from the Ignite-UX server or for a tape made with make_boot_tape so that this directory is created. 4. Copy the CINDEX file and recovery directory from the source client to the target client directory. Note that if the client has previously used make_net_recovery then it already has a CINDEX file. If a CINDEX file for the target client exists, you may want to save a copy or hand edit the file to add the desired entries from the source client. The following commands copy the required files. You can specify "src-client" and "client" using either the MAC addresses (for example, 0x0060B04AAB30) or the client's host name which is symbolically linked to the MAC address. # cd /var/opt/ignite/clients/<src-client> # find CINDEX recovery | cpio -pdvma ../<target-client> 5. Give the target client NFS access to the archive of the source client by logging into the Ignite-UX server that holds the archive. Typically each client has its own directory for storing the archives, and the directory is exported only to the individual client. In this case, you must edit the /etc/exports file to allow access to both the source and target clients as follows: # vi /etc/exports (append ":target client" to the end of the source client's line) # exportfs -av 6. Now, boot the client from the Ignite-UX server using any method you wish. When you install the client, you can select from the recovery configurations of the source client. =============================================================================== 11.3 Q: How can I tell which files will be included in the archive created by make_net_recovery? A: Execute "/opt/ignite/lbin/list_expander" as described in the next FAQ question, replacing the -d option (which lists the disks and/or volume groups) with the -l option, which lists the individual directories and files that will be included in the archive). =============================================================================== 11.4 Q: How can I tell which disks or volume groups get re-created during an installation from a make_net_recovery configuration? A: Execute the following from the client: # /opt/ignite/lbin/list_expander -d -f <input_file> where <input_file> specifies what is to be archived. Refer to make_net_recovery(4) for details on the format of <input_file>. The make_net_recovery command can take input from an input file, no input, or input from the command line with the x option. The list_expander command can take input from an input file, or no input, but does not have an x option like make_net_recovery does. To see the result of using x options, put them in a file and passlist_expander the file name. If you used the Ignite-UX GUI to specify what is to be included in the archive, then the input file can be found on the Ignite-UX server in: # /var/opt/ignite/clients/<client>/recovery/archive_content You can copy this file from the server to the client, then run list_expander against that file. Omitting the -f <input_file> causes list_expander to use only the essential files as input. This shows which disks or volume groups are recreated for the minimal archive. The following is an example of the 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 first column shows, for each disk or volume group, if it will be: 2 = included in full (INC_ENTIRE dsk/vg specified); the disk or volume group is re-created and files from the archive are restored 1 = included in part (some files included, some not); the disk or volume group is re-created and files from the archive are restored 0 = not included at all (no files from this dsk/vg are included); the disk or volume group will *NOT* be touched The second column shows that the client has one whole disk (d) and three volume groups (v). The third column gives the names of the disks and volume groups. =============================================================================== 11.5 Q: How can I use make_net_recovery if I need to be able to recover from a tape? A: There are two ways you can recover from a tape with make_net_recovery. The following method that you choose depends on your needs: - The first method is useful when you want to create a totally self-contained recovery tape. The tape will be bootable and contain everything needed to recover your client, including the archive of your client. During recovery, no access to an Ignite-UX server is needed. - The second method is useful when you do not have the ability to boot the client using the network, but are still able to access the Ignite-UX server using the network for your archive and configuration data. This could happen if your client does not support network boot or if is is not on the same subnet as the Ignite-UX server. In these cases, use make_boot_tape to create a bootable tape with just enough information to boot and connect with the Ignite-UX server. The configuration files and archive are then retrieved from the Ignite-UX server. For more information, refer to make_boot_tape(1M). =============================================================================== 11.6 Q: Which files does Ignite-UX change during an installation from a make_net_recovery configuration? A: During a client recovery, Ignite-UX strives to restore the client back to the way it was. However, Ignite-UX is a general purpose installation tool and as such it has the capabilities of modifying many client configuration files. When you run make_net_recovery, client configuration information is gathered and saved in configuration files that are used later when the client is recovered. During the client recovery you are allowed to make changes to this information, then Ignite-UX makes the appropriate changes to the client configuration. If you do not make any changes, then Ignite-UX simply reapplies the last installation information and makes no changes to the client's configuration. Most of the client configuration files that Ignite-UX modifies are listed in the script: /opt/ignite/data/scripts/os_arch_post_l. The os_arch_post_l script checks for the client 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 into which Ignite-UX knows how to intelligently merge information. The files operated on by merge_file, as well as those that have a commented out "save_file" line are those that are likely to be modified by Ignite-UX. Comments in this 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 script on the client to see which files are saved as-is and which are merged with information from the Ignite-UX configuration files. =============================================================================== 11.7 Q: How can I keep archives from being deleted by make_net_recovery when new archives and configurations are created by subsequent invocations of make_net_recovery? A: You may want to prevent known good archives from being deleted from your client. The make_net_recovery tool provides the -n option, which allows you to specify the number of archives to save. To preserve disk space, the oldest archives are removed as new archives are created. The number of archives that are removed is based on the number of archives you specified to be saved using the make_net_recovery -n. One way to ensure that known good archives are saved is to specify the number of archives to save to be greater than the maximum number of archives you plan to store on the client at any given time. This method has the potential to use a great deal of disk space. An alternative, better approach to saving known good archives is to rename the archive and edit the configuration file to include the new archive name. The following procedure explains this process in detail: 1. Login to the system where the archive is being stored; this system could be different from your Ignite-UX server. 2. Rename the archive. The name of the archive to save can be anything unique, but it should be outside the naming convention: "yyyy-mm-dd,hr:min". For example: # cd /var/opt/ignite/recovery/archives/system_name/ # mv old_archive_name saved_archive_name # mv 1999-05-11,15:14 Recovery_Archive.0511.save 3. If the archive server is different from the Ignite-UX server, login to the Ignite-UX server. 4. Edit the following file to reference the new archive name: # /var/opt/ignite/clients/<client>/recovery/<old_archive>/archive_cfg Change the archive_path variable inside the (source_type == "NET") conditional to the name of the saved archive. For example: (source_type == "NET") { archive_path = "Recovery_Archive.0511.save" } else { archive_path = "1" } 5. Optionally, you can edit the <cfg> entry in the file /var/opt/ignite/clients/<client>/CINDEX so the that configuration is unique and descriptive when it is viewed using the Ignite-UX GUI. For example, change: cfg "1999-05-13,06:51 Recovery Archive" { description "Weekly System Recovery Archive" . . . } to: cfg "Saved Recovery Archive" { description "Weekly System Recovery Archive" . . . } =============================================================================== 11.8 Q: How can I make configuration file additions to all recovery configurations for a given client? A: Create a new Ignite-UX configuration file called /var/opt/ignite/clients/0x<LLA>/recovery/config.local. This config.local file is automatically included into your recovery configuration for this client each time you run the make_net_recovery command. The make_net_recovery command is run for you when you use the Ignite-UX GUI for network recovery. If you already have recovery configurations for this client and would like them to include the config.local file, edit the /var/opt/ignite/clients/0x<LLA>/CINDEX file to include a reference to recovery/config.local in all of the configuration clauses. =============================================================================== 11.9 Q: How can I select from the standard file system layouts during a recovery? A: It is possible to change the way your disks are configured when you recover from an image saved by make_net_recovery. To do so, you must modify the /var/opt/ignite/clients/0x<LLA>/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 from which you intend to recover. If you want to add the HP standard 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.23/config would be added for a client with the HP-UX 11.23 operating system. This new configuration file entry should be the first entry in the clause you are modifying. When you launch the Ignite-UX during recovery, select the file system type you wish to use on the "Basic" tab. =============================================================================== 11.10 Q: I replaced the client machine and the LAN address is now different. How can I restore the new machine from the old client network recovery archive? A: 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 (MAC address, LLA, etc.). If you replace the client hardware or the LAN card that the old LAN address was based on, then it can no longer access the same directory on the Ignite-UX server. The simplest solution is to obtain the new LAN address, which you can do from the boot-ROM console using a command like LanAddress (the actual command may vary depending on the hardware architecture). Once you have the new address then manually rename the directory under /var/opt/ignite/clients. You may remove the symbolic link to the host name because it is recreated automatically. The LAN address must be all in uppercase and begin with 0x. If you have already booted the client from the server, which caused it to create a new directory, you can remove that directory before renaming the old directory. Be careful not to remove the original directory or you will lose the recovery information. For example: # cd /var/opt/ignite/clients # mv 0x00108300041F 0x00108300042A # rm old_hostname =============================================================================== 11.11 Q: Dealing with hot swappable disks during recovery. A: See question 4.3 (Dealing with hot swappable disks during recovery.). =============================================================================== 11.12 Q: Why does archive_impact fail during make_net_recovery? A: The PHCO_21185 patch issued for ksh(1M) causes corrupt parameter processing. The corruption occurs when archive_impact is run as a part of a make_net_recovery command. Software patch PHCO_21185 has been superseded by PHCO_22020. Remove patch PHCO_21185 and install PHCO_22020 to correct this failure. =============================================================================== 11.13 Q: How can I restore VxVM DCO log volume groups? A: The make_net_recovery/make_tape_recovery tools will create a recovery archive for a client while preserving the configurations for all VxVM (VERITAS Volume Manager) volumes except data change object (DCO) log volumes. After recovering from the archive, the DCO log volume configurations will be lost and must be reconfigured using VxVM commands. There are basically two methods of reconfiguring lost DCO log volumes; choose the method that is appropriate for your situation: - Wait until the client is recovered and then execute the following VxVM command: # vxassist -g rootdg addlog homevol logtype=dco Repeat execution of this command until all the DCO volumes are restored. or - Manually create an Ignite-UX configuration file that executes the VxVM commands as part of the actual recovery process. This method integrates the VxVM commands into an Ignite-UX configuration file. For make_net_recovery, create a new Ignite-UX configuration file called /opt/ignite/clients/0x<LLA>/recovery/config.local; while for make_tape_recovery, create a new file called /var/opt/ignite/recovery/config.local. The respective config.local file is automatically included in your recovery configuration for this client each time make_net_recovery/make_tape_recovery is run. An example of a config.local file that restores DCO log volumes after the recovery completes follows: ###### Begin user changes to add DCO log volumes ####### post_config_cmd +=" vxassist -g rootdg addlog homevol logtype=dco " ###### End user changes to add DCO log volumes ###### After creating this config.local file, it is a good practice to run "instl_adm -T -f config.local" to ensure that the syntax is correct. Commands in post_config_cmd are executed automatically after the client is restored. =============================================================================== 11.14 Q: Are the layered/striped/mirrored VxVM volumes included in the recovery archive when a client recovery archive is created? A: No. The make_tape_recovery and make_net_recovery tools do not back up the layered/striped/mirrored VxVM volumes. You need to perform the following actions during and after the recovery: - During recovery, since the volume definition for layered/striped/mirrored volumes may not exist, you may need to manually define a volume for recovery and resize other volumes appropriately. Ignite-UX may have adjusted the size of other volumes so the client could be recovered. However, this may fail due to a lack of disk space and force an interactive recovery. In any event, you should choose an interactive recovery then verify that the VxVM volume layout will be appropriate after recovery. - After recovery you need to recreate the original volume configuration. In other words, set up the previous layered/striped/mirrored VxVM volume configuration. For more information, refer to "VERITAS Volume Manager 3.x Administrator's Guide" at the HP technical documentation web site at: http://docs.hp.com/hpux/os/11i/oe/ =============================================================================== 11.15 Q: Can I run make_tape_recovery/make_recovery in single user mode? If so, how? A: Yes. You can use these tools after booting or shutting down to single user mode. Choose the appropriate procedure for your situation. After you have booted to single user mode, use this procedure: 1. Mount all file systems: # /sbin/mountall 2. Disable DNS so that /etc/hosts is used: # mv /etc/resolv.conf /etc/resolv.conf.save 3. Set your client's host name: # /sbin/rc1.d/S320hostname start 4. Set up loop back networking: # /sbin/rc2.d/S008net.init start 5. Start the networking daemon: # swagentd 6. Start the recovery tool you intend to use [make_tape_recovery/make_recovery]: # [make_tape_recovery/make_recovery] Note: The -s option of make_tape_recovery is not supported in the single user mode. 7. When complete, return the resolv.conf file to it's original location: # mv /etc/resolv.conf.save /etc/resolv.conf After you have shutdown to single user mode, use this procedure: 1. Mount all file systems: # /sbin/mountall 2. Start the SD-UX daemon: # swagentd -r 3. Start the recovery tool you intend to use [make_tape_recovery/make_recovery]: # [make_tape_recovery/make_recovery] Note: The -s option of make_tape_recovery is not supported in the single user mode. =============================================================================== 11.16 Q: Why are there invalid disk device files left behind after some recoveries? A: When Ignite-UX performs a recovery operation, it can create device files for disks that are discovered when the client boots from the installation kernel. During the recovery process, Ignite-UX performs actions to preserve the original instance numbers of those disks. After the final client boot, the disks will have the original instance numbers; however, Ignite-UX does not attempt to clean up disk devices which no longer have hardware devices associated with them. The existence of these device files presents no problem to HP-UX. This is only known to cause problems with one third party product as it expects all disk devices to have hardware associated with them. To remove the device files that no longer have hardware associated with them, the following commands should be executed: # lssf /dev/*dsk/* | grep '\?\?\?' # rmsf "names of files found with the previous command" =============================================================================== End of FAQ