[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: Ignite-UX FAQ

This article was archived around: 11 June 2001 09:26:06 -0600

All FAQs in Directory: hp
All FAQs posted in: comp.sys.hp.hpux
Source: Usenet Version


Ignite-UX (IUX) Frequently Asked Questions
@(#) IUX FAQ $Revision: 10.102 $ $Date: 2001/05/30 21:40:04 $ About this FAQ -------------- The current contents were created by the Ignite-UX engineering team from support questions gathered from various sources. For future editions, we invite your input via the "ignite-ux-notify" mailing list. Submissions will not be distributed to the mailing list on an individual basis, but compiled into the FAQ and distributed periodically as input dictates. Submission criteria ------------------- Acceptable: o Solutions to sticky problems you solved, from which other users might benefit. o Slick customizations that might benefit other users. o Customized uses for Ignite-UX of which other users could take advantage. Not Acceptable: o Support questions. Contact your Response Center for support. To submit, send content to "ignite-ux-notify@igniteux.fc.hp.com" with subject "FAQ". You will not receive a response, but you will be given credit in the FAQ for your contribution (unless you tell us otherwise). -------------------- Getting this FAQ web - http://software.hp.com/products/IUX/docs/iux_faq mail - null message to iux_faq@igniteux.fc.hp.com (most current) -------------------- --------------- Special Notice: The Ignite-UX product is Year 2000 compliant, beginning with the 1.45 release. --------------- TABLE OF CONTENTS ----------------- 1. Known Problems 1.1 Q: Some commands core dump and die after installing or recovering, why? 1.2 Q: Ignite GUI core dumps, why? 1.3 Q: I updated my server, now it can't find "/d_cfg_mnt_sb61/monitor_bpr". 1.4 Q: Why do hostnames longer that 8 characters not work for 10.X? 1.5 Q: I updated my server, now it complains that it "Cannot determine dump size limit" 1.6 Q: Can the GUI interface for make_tape_recovery span multiple tapes? 1.7 Q: Why do I get Warnings from pax concerning files that are not on the system when I run either make_tape_recovery or make_net_recovery? 1.8 Q: When igniting from an archive I get numerous "samreg" errors. 1.9 Q: Can an IUX server install clients on multiple subnets? 1.10 Q: Recovering a system failed, could not create a logical volume. 1.11 Q: Using bootptab entries to satisfy the DHCP request doesn't work, why? 1.12 Q: How can I keep make_net_recovery version 2.0 from erasing volume groups that contain only unmounted and raw logical volumes? 1.13 Q: When igniting 10.20 systems, I get ERRORS regarding mounting of file systems, why? 1.14 Q: Why do some applications and shells hang over NFS after igniting? 1.15 Q: bootsys -i "configuration" [sys1...] fails, why? 1.16 Q: Failures, hangs, and odd behavior caused by ENV environment variable. Why? 1.17 Q: Doing a bootsys ("push") install to J2240 omits ps2/CentIF drivers. 1.18 Q: The bootsys command occasionally hangs on 11.00 clients, why? 1.19 Q: Why does loading the 11.00 64-Bit Minimal HP-UX environment fail? 2. Server Setup 2.1 Q: Should I use DHCP or bootp? 2.2 Q: Why did it call my client "<hostname>.0x080009...."? 2.3 Q: Which version of Ignite-UX supports my hardware? 3. Config files 3.1 Q: What should go in which config file? 3.2 Q: How do I preview config file changes? 3.3 Q: Is there a way in the configuration files to ignore warings? 3.4 Q: Which config file example should I use for an 11.00 archive? 4. Recovery (make_recovery) 4.1 Q: We tried running the recovery option from a client and got tftp errors. 4.2 Q: How do I duplicate a tape made with make_recovery? 4.3 Q: Why don't the Online Diagnostics LIF files get restored? 4.4 Q: I get an "bad IPL checksum" error when booting B1000, C3000, and J5000 4.5 Q: Why do I get the error: "The minor number of the volume group exceeds the value IUX can support."? 4.6 Q: Dealing with hot swappable disks during recovery 4.7 Q: Why does make_recovery hang while trying to write the archive? 4.8 Q: Should I run make_recovery in single user mode or can users be on the system when I do the recovery? 4.9 Q: What is the maximum amount of data that a make_recovery tape can hold? 4.10 Q: Why do I get an error from pax saying: linkname greater than 100 characters? I have PHCO_20388 installed. 5. General Install 5.1 Q: Confused about the way that IUX estimates space needed for file systems. 5.2 Q: How can I set the timezone such that the install.log file is in local time? 5.3 Q: When does IUX configure software? 5.4 Q: How do I set the targets final networking information? 5.5 Q: What if I don't want to use DHCP to set networking information? 5.6 Q: Having problems installing to system with small (<1GB) root disk. 5.7 Q: How is software in a depot made available for installs? 5.8 Q: How can I know whether I can install a 64-bit OS on a system? 5.9 Q: FDDI software is in my archive, yet IUX requires that I select it, why? 5.10 Q: How many systems can I install at once - in parallel? 6. Network Install 6.1 Q: What network architectures are supported? 6.2 Q: My 715/50 won't network boot off of my IUX server, why? 6.3 Q: When I try to boot, I get the following error: IPL error: bad LIF magic 6.4 Q: How do I set up a 9.0X system as a Boot Helper? 6.5 Q: Using "control_from_server=true" & "run_ui=false" I still get prompted. 6.6 Q: bootsys -w seems to work in reverse;The client didn't wait for the server. 6.7 Q: bootsys does not work on diskless clients, how can I remotely install? 6.8 Q: Client "search lan", the server doesn't appear on the list. 6.9 Q: Bootsys fails due to insufficient space in the /stand volume, why? 6.10 Q: Can I have the IUX server and client on different subnets? 7. Media Install 7.1 Q: How do I create bootable IUX media with my configs on it? 7.2 Q: Can I make a bootable tape with an SD depot on it? 7.3 Q: Why does swinstall of patches hang during the software analysis? 7.4 Q: Why do I get dce / rpc errors during the configuration stage? 7.5 Q: How can I put an OS archive on multiple CD-ROM's? 8. Archive installs (golden images) 8.1 Q: What does this mean? gunzip: stdin: unexpected end of file 8.2 Q: Some files from my archive don't end up on the install target, why? 8.3 Q: What does "pax_iux: X: Cross-device link", "pax_iux: X: File exists", or "pax_iux: X : Device busy" mean? 8.4 Q: What HP applications are tested for use with Ignite-UX? 8.5 Q: How can the OnlineDiag LIF volumes be restored during the installation? 9. Getting Ignite-UX 9.1 Q: What is different about the Web version? 9.2 Q: Can Ignite-UX bits be retrieved via ftp rather than downloaded from the web? 9.3 Q: Is Ignite-UX available on media? 9.4 Q: How do I update my Ignite-UX server to a new version? 9.5 Q: How much of Ignite-UX do I need to install? 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: Loading superseded patches causes a failed status, how to workaround? 11. Network Recovery 11.1 Q: How can I learn more about network recovery? 11.2 Q: How does make_net_recovery differ from make_recovery? 11.3 Q: Can I still use make_recovery on a system if I am also using make_net_recovery? 11.4 Q: How can I clone a system using make_net_recovery? 11.5 Q: How can I tell which files will be included in the archive created by make_net_recovery? 11.6 Q: How can I tell which disks or volume groups will get re-created during an installation from a make_net_recovery configuration? 11.7 Q: How can I use make_net_recovery if I need to be able to recover from a tape? 11.8 Q: Which files does Ignite-UX change during an installation from a make_net_recovery configuration? 11.9 Q: How can I keep archive(s) from being deleted by make_net_recovery when new archives and configurations are created by subsequent invocations of make_net_recovery? 11.10 Q: How can I make configuration file additions to all recovery configurations for a given client? 11.11 Q: How can I select from the standard file system layouts during a recovery? 11.12 Q: How can I keep make_net_recovery version 2.0 from erasing volume groups that contain only unmounted and raw logical volumes? 11.13 Q: Why can make_net_recovery fail when the archive is 2GB or more? 11.14 Q: How can I keep make_net_recovery version 2.0 and 2.1 from core dumping when I have more than 8 volume groups? 11.15 Q: How can I keep make_net_recovery version 2.0 and 2.1 from crossing and archiving files from NFS mounts when I have symlinks from essential directories to NFS mounted directories, and when there is a symlink in the pathname to the directory? 11.16 Q: I replaced the client system, and the LAN address is now different. How can I restore the new system from the old net-recovery archive? 11.17 Q: Why do I get the error: "The minor number of the volume group exceeds the value IUX can support."? 11.18 Q: Dealing with hot swappable disks during recovery 11.19 Q: Why does make_net_recovery hang while trying to write the archive? 11.20 Q: Why does archive_impact fail during make_net_recovery ======================================================================== -------------------- 1. Known Problems -------------------- 1.1 Q: Some commands core dump and die after installing or recovering, why? A: When installing systems from an archive, or from a tape made with make_recovery or make_tape_recovery, the pax(1m) command attempts to optimize disk space by creating files with "holes" in them (sparse files) if a file contains a block of nulls. In most cases this does not cause a problem since the files will appear identical in all respects except for the amount of disk space used as reported by the "du" command. However when this happens to an executable file it can cause the executable to unpredictably die with a bus-error and core-dump. A kernel patch exists that will allow sparse executables to execute correctly. This patch should be loaded on your system prior to using make_recovery or creating an archive using make_sys_image(1M). The patches that contain the fix, are listed below. Note that these patch numbers have already been superseded and only their replacement version may be available. 10.01: PHKL_23512 (S700), PHKL_17448 (S800) 10.10: PHKL_11240 (S700), PHKL_11241 (S800) 10.20: PHKL_16750 (S700), PHKL_16751 (S800) (fixed at 10.30 & 11.00) ================================================================ 1.2 Q: Ignite GUI core dumps A: If your system has patch PHSS_12824 Motif or PHSS_13743, remove it or install PHSS_22944. PHSS_12824 was found to be bad. ====================================================================== 1.3 Q: I updated my server, now it can't 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-10-20) 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 Ignite-UX". 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.4 Q: Why do hostnames longer that 8 characters not work for 10.X? A: The Software Distributor tools (swinstall, etc) in 10.X use the system's hostname, and uname value interchangeably, and since the uname value is restricted to 8 characters, the SD tools would fail if the hostname is longer than 8. ================================================================ 1.5 Q: I updated my server, now it complains that it "Cannot determine dump size limit" A: If you have a saved client config created using a version of Ignite-UX prior to 1.51, and then update Ignite-UX to 1.51 or later, and if you bring itool up for that client with having booted the client on the server, it will give an ERROR looking something like this: ERROR: Unable to determine dump size limit for disk (8/4.8.0), release (B.10.20). Internal Ignite-UX error. The problem is that an old version of the clients' hw.info file is being examined by the new Ignite-UX. To fix things, merely boot up the client system using 'boot lan.<IP> install' (or whatever syntax your system supports) from the boot prompt, where <IP> is the IP address of your Ignite-UX server. The client hw.info file will be updated, and everything should proceed normally. ====================================================================== 1.6 Q: Can the GUI interface for make_tape_recovery span multiple tapes? A: No. This is not possible for the DART52 (IUX 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 the command make_tape_recovery on the client to be able to span multiple tapes. ====================================================================== 1.7 Q: Why do I get Warnings from pax concerning files that are not on the system when I run either make_tape_recovery or make_net_recovery? A: We are now creating a list of files to archive and are using that list in multiple places in the code. By the time the archive is actually created from this list, there is a chance that some temporary files may have been deleted or removed. If this occurs, then the Warning about a missing file will be given by pax. ====================================================================== 1.8 Q: When igniting from an archive I get numerous "samreg" errors. A: The problem is that the SAM filesets haven't been configured when certain products are trying to register themselves with SAM. The workaround is: This config stanza can be placed in /var/opt/ignite/config.local or directly in the config file with the "core" sw_source. sw_source "core" { post_load_cmd += " swconfig -xautoselect_dependencies=false -xenforce_dependencies=false SystemAdmin.SAM " } ====================================================================== 1.9 Q: Can an IUX server install clients on multiple subnets? A: There are a couple of problems with having an Ignite-UX server that is multi-homed (connected to multiple subnets). Below are the known problems and possible workarounds: 1) The instl_bootd daemon allocates IP addresses from the instl_boottab file without knowing which IP addresses are valid for the subnet that the client is requesting to boot from. Due to this lack of information, it can allocate an IP address that is not valid for the client's subnet, and thus the client will not be able to boot from the server. The workarounds for this problem are: - For every possible client that you may want to boot, assign "reserved" IP addresses in /etc/opt/ignite/instl_boottab that are tied to the client's LLA address. This will ensure that instl_bootd will allocate an appropriate address (See the comments in the instl_boottab file on how to reserve addresses). Alternatively, you can set up entries in /etc/bootptab (See question 5.5). - Configure a boot-helper system on each subnet that the client can boot from before contacting your central IUX server. See the Ignite-UX manual for details. 2) 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 install 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: - 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. ====================================================================== 1.10 Q: Recovering a system failed, could not create a logical volume. A: A defect in Ignite-UX versions A/B.1.55 and A/B.1.59 exists such that when a system is being recovered from a tape, it could fail with an error such as: ============== * Creating logical volume "vg00/lvol3" (/tmp). lvcreate: Logical volume "/dev/vg00/lvol3" already exists. ERROR: Command "/sbin/lvcreate -A n -n lvol3 -C n vg00" failed. ERROR: The configuration process has incurred an error. If you wish to push a shell for debugging purposes, go to the target machine's console and interact there. Otherwise, use the "Stop Install" action to reboot or halt the target machine. The configuration process has incurred an error, would you like to push a shell for debugging purposes? (y/[n]): ============== This happens only on systems that have logical device files with the standard names but which have a minor number that did not match the name (For example /dev/vg00/lvol3 that does not have a minor number of 3). If the time comes that you need to use a recovery tape that has this problem, the workaround involves answering yes to pushing a shell for debugging when you see the error as show above, and executing the following steps: 1) Remove the device files (char and block devices) for the logical volume that it failed to create. Examine the error message with the lvcreate command to determine the path. In the example shown above, the command would be: # rm /dev/vg00/*lvol3 2) Re-run the failed lvcreate command as shown in the error message. Write this command down, since you will need it again later in step 5. # /sbin/lvcreate -A n -n lvol3 -C n vg00 3) Type "exit 2" to allow the installation to continue. 4) The process will next fail at the lvextend step (because IUX internally removed the old logical volume that it had created temporarily to reserve the minor number). The error message would look something like: =========== lvextend: "/dev/vg00/lvol3": No such file or directory Usage: lvextend [-A Autobackup] {-l LogicalExtentsNumber | -L LogicalVolumeSize} LogicalVolumePath [ PhysicalVolumePath... | PhysicalVolumeGroupName... ] ERROR: Command "/sbin/lvextend -A n -L 600 /dev/vg00/lvol3 /dev/dsk/c1t14d0" failed. The configuration process has incurred an error, would you like to push a shell for debugging purposes? (y/[n]): =========== Answer "y" to push a shell. 5) Recall the lvcreate command you typed in in step 2. You should be able to use the ksh command history to recall and execute it. If not, then retype it as you did in step 2. # /sbin/lvcreate -A n -n lvol3 -C n vg00 6) Type in and re-run the failed lvextend command that you see in the error message: # /sbin/lvextend -A n -L 600 /dev/vg00/lvol3 /dev/dsk/c1t14d0 7) Type "exit 2" to continue the installation. ====================================================================== 1.11 Q: Using bootptab entries to satisfy the DHCP request doesn't work, why? There is a known problem with patches PHNE_17123, and PHNE_13648 to the bootpd daemon. If you are strictly using entries in /etc/bootptab such as described in question 5.5 in this document, you may have problems once these patches are on your server. The workaround is to either: - Load the patch with the fix: PHNE_19241 (11.00) or PHNE_19095 (10.X). - Remove these patches. - Or, create a dummy entry in the /etc/dhcptab file which works around the defect. The entry can look something like the entry below. You will need to set the subnet-mask for your network. 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.12 Q: How can I keep make_net_recovery version 2.0 from erasing volume groups that contain only unmounted and raw logical volumes? A: See FAQ entry 11.12. ====================================================================== 1.13 Q: When igniting 10.20 systems, I get ERRORS regarding mounting of file systems, why? A: There is a 10.20 patch PHCO_18317 that supplies a new version of /sbin/mount. This version is broken for Ignite-UX usage. If this patch is loaded via either an archive or SD, then the next swinstall session will have fatal errors that appear like this: ERROR: "c02380:/": One or more filesystems that appear in the filesystem table are not mounted and cannot be mounted. ERROR: Entry for filesystem "/dev/vg00/lvol1" in "/etc/fstab" could not be mounted. If you do not want this file system mounted, comment it out of the "/etc/fstab" file, or set the "mount_all_filesystems" option to "false". ERROR: Cannot continue the Analysis Phase until the previous errors are corrected. One workaround is to add the following to your configuration: sd_command_line += " -xmount_all_filesystems=false " However this has the unpleasant side effect that each swinstall session produces a warning message stating that file systems will not be mounted. There is a new patch PHCO_20061 that supersedes PHCO_19694. Note that recovery methods are unaffected because they are solely OS archives, and no SD activity takes place. ====================================================================== 1.14 Q: Why do some applications and shells hang over NFS after igniting? A: The reason for the hang is most likely do to a problem with the NFS file locking daemons rpc.statd and rpc.lockd caused by the action of reinstalling the system. 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 will attempt to lock the .sh_history file and hang before giving the user a prompt. When a system 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 RPC port number to use 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 system that it knows it should contact in the event that the system reboots (or rpc.statd/rpc.lockd restarts). During a normal reboot or crash, rpc.statd will contact each system in /var/statmon/sm and inform them to flush their cache regarding this client. When you reinstall a system, the /var/statmon/sm directory is wiped out. In this case, if the reinstalled system tries to re-contact a server that has cached information, the server will try to communicate over a 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 & rpc.statd on the client. At the point of the hang, the /var/statmon/sm dir will contain the name of the server, and thus rebooting or restarting the daemons will tell the server to flush it's 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. Below is an example post_config_cmd that could be placed in your /var/opt/ignite/config.local file. Replace "sys*" with your NFS server names. 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.15 Q: bootsys -i "configuration" [sys1...] fails, why? A: A defect has been found in the A/B.2.2 release of Ignite-UX. Specifically, bootsys(1M) must be modified in order to successfully push a specific configuration out to a client. The change required is as follows: vi /opt/ignite/bin/bootsys <move to line 848 in the file> if [[ "c_opt" != "$PUSH_MODE" ]]; then <change "c_opt" to "$c_opt" and save the change> bootsys -i <configuration> [sys1..] will now work correctly. This defect will be fixed in the next release of Ignite-UX after A/B.2.2. ======================================================================== 1.16 Q: Failures, hangs, and odd behavior caused by ENV environment variable. Why? A: DESCRIPTION: A defect has been found in Ignite releases A/B.2.3 and earlier that can have a wide range of possible side-effects. Some commands bundled as part of Ignite are scripts. Other commands invoke these scripts, or execute commands with calls to popen(3S) or system(3S). All of these invocation methods result in the execution of the posix shell (sh-posix(1)) which will source any file pointed to by the 'ENV' (sh-posix(1)) environment variable. This occurs whether or not the shell is invoked interactively, and thus applies under the previously mentioned circumstances. One of the major impacts that we have seen so far is the resetting of locale(1) variables within the users environment. Ignite commands such as make_recovery(1M) and make_net_recovery(1M) explicitly set all language related variables to null. They rely on the fact that data is formatted in the default "C" locale and will not function properly otherwise. Known failures include 'exit with error' by these applications. Unconfirmed results have included application hangs during the sourcing of configuration files. Other serious side effects might occur during the execution of Ignite application scripts. Aliases sourced into the execution environment of the script might seriously effect the behavior of these scripts in an unpredictable manner. SOLUTION: The ENV environment variable will be programmatically set to null in future releases. A temporary solution is to set the ENV environment variable to null while running Ignite-UX commands. This can easily be accomplished in the ksh or posix shells with the following syntax: # ENV="" <command> ======================================================================== 1.17 Q: Doing a bootsys ("push") install to J2240 omits ps2/CentIF drivers. A: A defect introduced in the B.2.5 release of Ignite-UX causes the wrong install kernel to be used on a J2240 when the "bootsys" command is used (either manually or via the "ignite" user interface). The result of the defect causes the "ps2" and "CentIf" drivers to be omitted from the resulting kernel after the J2240 system is installed. This problem will be fixed in the next release of Ignite-UX available Feb 2000 from http://software.hp.com or on the March 2000 application CD-ROM set. Workarounds until it is release include either: - Automate the addition of "ps2" and "CentIf" drivers during the installation by adding the following lines to an Ignite-UX configuration file such as /var/opt/ignite/config.local: (MODEL == "9000/782/J2240") { mod_kernel += "ps2" mod_kernel += "CentIf" } - Or, manually add the "ps2" and "CentIf" drivers to the kernel after the system is installed either using sam, or other methods. - Or, avoid doing "push" installs using "bootsys" or "ignite" to J2240 systems. Instead, initiate a network or media boot from the client. ======================================================================== 1.18 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 the load the latest remsh/rcp/rlogin/rexec patch onto the clients. In this case, you will typically see a "cat" process that never completes running on the bootsys client. 11.00: PHNE_17030 JAGab73645 (fixed at 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.19 Q: Why does loading the 11.00 64-Bit Minimal HP-UX environment fail? A: When loading the 11.00 64-Bit Minimal HP-UX environment, you may encounter errors during the software load that look like: 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 systems 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 turns requires that the ProgSupport.C-INC fileset be loaded. This C-INC fileset is not part of the HPUXMinSys64 bundle and does not get automatically loaded. 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 config file produced by make_config that you created for the core-OS 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 be: sd_software_list = "HPUXMinSys64 ProgSupport.C-INC" ======================================================================== -------------------- 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, it dynamically allocates addresses. You will probably want to use the Ignite 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 will 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 also question 5.5 (What if I don't want to use DHCP, can I still have IUX automatically determine networking information for all my clients?). ====================================================================== 2.2 Q: Why did it call my client "<hostname>.0x080009...."? 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 install, then the client name will have the LLA (hardware lan link address) appended to the hostname so it won't conflict with the prior hostname left from the prior install. This may also happen if you had to replace the LAN interface in your client system since the last time you installed it. The LLA number is attached to the LAN interface, not the system. It is only the "icon name" that has been renamed. And you can use the ignite GUI action menu to "Change icon name" to rename one or both of the clients. ======================================================================== 2.3 Q: Which version of Ignite-UX supports my hardware? A: Below is the hardware support matrix found also in the /opt/ignite/share/doc/release_note document. The information kept here in the FAQ will contain any information we can share about new hardware support in upcoming releases. ------------------------------------------------------------------- There are two main versions of Ignite-UX, the "A" and "B" versions. The "A" version is based on a HP-UX 10.20 kernel and commands. The "B" version uses the latest 11.00 kernel. Occasionally HP will release a new system that is only supported by HP-UX 10.20 and/or 11.00 for some period of time. This results in some systems only being supported by one Ignite-UX version. Below is a table that identifies systems that are supported by only one release, or that Ignite-UX does not yet support. It also lists the minimum Ignite-UX release needed to support the system if support for it was recently added. Older systems not listed in the table can be assumed to be supported by both versions. Systems | A-version | B-version | notes ======================+=================+===============+====== N-class | no | yes (B.2.0) | 1 ----------------------+-----------------+---------------+------ L-class | no | yes (B.2.0) | 1 ----------------------+-----------------+---------------+------ V-class | no | yes (B.1.48)| 1,3 ----------------------+-----------------+---------------+------ V2500 SCA | no | no | 4 ----------------------+-----------------+---------------+------ B1000, C3000, J5000 | yes (A.1.59.1)| yes (B.2.2) | 7,8 J7000 | | | ----------------------+-----------------+---------------+------ B2000 | yes (B.2.2) | yes (B.2.2) | 7,8 ----------------------+-----------------+---------------+------ A-class | yes (see note)| yes | 5 ----------------------+-----------------+---------------+------ Older series 700's | yes | no | 6 ----------------------+-----------------+---------------+------ Notes: 1) Systems are only supported by HP-UX 11.00. No plans to support 10.20 on them. Must use Ignite-UX B-version. 2) Will be supported in the upcoming Ignite-UX release indicated. 3) V-class systems require firmware version 4.3 or higher for make_recovery tape boot support. 4) V2500 SCA at its first limited release will not have Ignite-UX support. Ignite-UX will support after the general release. 5) A-class systems may require a firmware update to boot over the network from a server running the A-version. 6) The Series 700 systems not supported by HP-UX 11.00 are not supported by Ignite-UX B-version. That list is 705, 710, 715/33, 715/50, 715/75, 720, 725/50, 725/75, 730, 735, 750, and 755. In addition, systems with the graphics devices GRX, CRX, CRX-24, and CRX-48Z are not supported. 7) For 11.00 support, the B1000, B2000, C3000, J5000, and J7000 require the November 1999 or later XSWGR1100 patch bundle. 8) For 10.20 support, the B2000 requires the December 1999 or later Workstation ACE patch bundle. The B1000, C3000, J5000, and J7000 require the June 1999 Workstation ACE or later patch bundle. ======================================================================== -------------------- 3. Config files -------------------- 3.1 Q: What should go in which config file? Also, what should go in INSTALLFS? A: Here is a short description of the common uses of the various configs. Obviously there can be situations that aren't "common" and variations will occur: INSTALLFS: (accessed/modified via instl_adm(1M) ): Information that is needed at boot, such as the following: ui controls networking /var/opt/ignite/config.local Information that should be globally applied to all clients of all types the post_(load/config)_scripts run on all clients /opt/ignite/data/Rel*/config This file sets the definitions for that release and shouldn't be modified. /var/opt/ignite/date/Rel*/*_cfg Information regarding software selections/sources these files should be created by make_config(1M) (run against an SD 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 config 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 here is when the client was previously installed and the per client directory in /var/opt/ignite/clients exists and is populated with the previously resolved configs. In this case, the previously resolved config.full has precedence. ====================================================================== 3.2 Q: How do I preview config file changes? Fixing syntax problems with mod_kernels results in statements of the following form: mod_kernel += "maxdsiz " + ${_maxdsiz} There doesn't 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? A: The config.full file has the variable values replaced with the real values. So if you look in there, you should be able to see what the real mod_kernel statement became. In this case you would have seen the following: mod_kernel += "maxdsiz 0" Another option would be to have it 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 say in the configuration files "don't bother with the disk warning" ? This warning can prevent automated installs. 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 install to proceed after the warning is: env_vars += "INST_ALLOW_WARNINGS=10" ======================================================================== 3.4 Q: Which config file example should I use for an 11.00 archive? A: For setting up an OS-archive for the 11.* releases, you will need to use the config file example: /opt/ignite/data/examples/core11.cfg as a starting point instead of the "core.cfg" file. a A failure to use the core11.cfg file, or a failure to correctly modify the file will result in the message below: ERROR: The _hp_os_bitness variable is not set to \"32\" or \"64\". This variable must be set in the config file that supplies the core archive or depot. If using an archive, make sure you start with the core11.cfg example config file. When using a depot, make_config will set this automatically. ======================================================================== -------------------- 4. Recovery -------------------- 4.1 Q: We tried running the recovery system option from a client booted in IUX. We ended up with errors which seemed to point to files not being accessible via tftp. It looks like the default IUX config does not make the directories needed for recovery systems available via the /etc/inetd.conf file. The directories should either be added or the problem documented (including in the error message). A: Only /opt/ignite and /var/opt/ignite should be needed for tftp access. ======================================================================== 4.2 Q: How do I duplicate a tape made with make_recovery? A: A tape created with make_recovery contains 2 tape "files" The first tape file is written with a 2k block size, and the second with a 10k block size. The first file is a LIF file, and the second is a tar archive. If you have 2 tape drives on a system, then you can easily duplicate the tapes using 2 dd commands with a no-rewind-on-close device file for the first command. For example: dd if=/dev/rmt/0mn of=/dev/rmt/1mn bs=2k dd if=/dev/rmt/0m of=/dev/rmt/1m bs=10k If you only have 1 tape drive, and have enough disk space to hold the contents of both tape files, then you should be using something like the following: dd if=/dev/rmt/0mn of=/var/tmp/f1 bs=2k dd if=/dev/rmt/0m of=/var/tmp/f2 bs=10k <Insert blank tape now> dd if=/var/tmp/f1 of=/dev/rmt/0mn bs=2k dd if=/var/tmp/f2 of=/dev/rmt/0m bs=10k ======================================================================== 4.3 Q: Why don't the Online Diagnostics LIF files get restored? A: NOTE: This description is left in for this release. However, with the [A|B].2.4 release of Ignite-UX, LIF files should now be saved during "recovery" and restored properly. -------- Pre-[A|B].2.4 Response -------- IUX destroys the old LIF area on the boot disk and lays down new LIF volumes every time the system is installed. At no point during the installation are the old LIF volumes copied and restored to the disk. To restore the LIF volumes to the disk, reinstall the application, or look at the SD configure scripts for the application and rerun the commands which put the LIF volumes in place on the disk. For example, for the OnlineDiag bundle, the /var/adm/sw/products/LIF-LOAD/LIF-LOAD-MIN/postinstall script puts the OnlineDiag LIF volumes onto the root disk. It uses this command: /usr/sbin/diag/lif/lifload -f /usr/sbin/diag/lif/updatediaglif ======================================================================== 4.4 Q: I get an "bad IPL checksum" error when booting B1000, C3000, and J5000 A: The 1.8 revision of firmware on the B1000, C3000, and J5000 workstations has a defect that causes them to give a "bad IPL checksum" error when booting from a make_recovery tape (and possibly other bootable tapes as well). If you have one of these systems, your options are to update the system firmware once a new version with a fix is made available, or to use Ignite-UX version [A|B].2.0 or later which works around the problem. You may be able to request a new version of the Ignite-UX make_medialif script from your HP support representative prior to the 2.0 release. ======================================================================== 4.5 Q: Why do I get the error: "The minor number of the volume group exceeds the value IUX can support."? A: Both make_recovery and make_net_recovery check to ensure that they do not back up a system that Ignite-UX will be unable to recreate. The "A" version of Ignite-UX can only create volume groups with group numbers in the range 0 to 10. This is due to the maxvgs kernel tunable being set to 10 in the INSTALL kernel. In order to continue to have Ignite-UX work on systems with 32MB of memory, the kernel cannot have this parameter increased. The "B" version of Ignite-UX does not have this restriction due to reductions in the amount of memory LVM consumes. It is unusual for the root volume group to have a large volume group number, so it is uncommon to run into this with make_recovery. However, since make_net_recovery can operate on non-root volume groups it is more likely to see the error with that tool. Workarounds: - If you got into this situation by manually recreating the LVM device files, then consider renumbering them to something less then 10. - If using make_net_recovery, exclude that volume group from the archive. - Use the "B" version of Ignite-UX which is only officially supported on 11.* releases. ======================================================================== 4.6 Q: Dealing with hot swappable disks during recovery A: Certain customers have attempted to use hot swappable disk functionality to avoid changing a particular disk. Disk mirroring may also be involved. Ignite-UX supports only hot swappable disks that are completely installed, and not removed when creating a recovery image. Proper software and hardware procedures must be used for hot swap disk removal or replacement before or after recovery, but not in the middle. The LVM command lvlnboot used by save_config does not work when a disk is removed and the system is this odd state. If this command is not working, then recovery has no chance of succeeding. ======================================================================== 4.7 Q: Why does make_recovery hang while trying to write the archive? A: During archive creation, both make_recovery and make_net_recovery can hang while attempting to read files with mutually exclusive locks (see lockf(2)). A file lock set with F_LOCK enforcement will cause a process to sleep while attempting to read that file. If this is the problem then you will see a pax(1) process in the sleep state that has blocked on a locked file. How to find the offending file: A capital 'S' character in the execute permission bit for a file is one indication of this kind of lock. The tools glance(1) or gpm(1) can be used to view all files in use by a process, and will easily help you identify the locked file. Locate the pax(1) process that is attempting to archive the file and use glance or gpm to view files that it is using. You can also look at the recovery log /var/opt/ignite/logs/makrec.log2 to get a fairly accurate idea where make_recovery hung. The last entry in the log file should be the last file successfully archived. This file may be slightly inaccurate however if some output for the log file is still buffered. To see the files that are supposed to follow the last recorded entry you can run make_recovery in preview mode (make_recovery -p) to create the contents file /var/opt/ignite/recovery/arch.include. Sort the contents file with the 'sort -u' command and examine the results. Work around: The hanging behavior that is occurring is the appropriate behavior under these circumstances. There is no way to archive files while they are locked in this manner. For this reason you must exclude locked files from the archive. This also means you cannot lock files that are part of the minimal set of archive files built into make_recovery. Excluding locked files from archive: -You can run make_recovery in preview mode which will create the archive content file /var/opt/ignite/recovery/arch.include. You can edit this file to explicitly remove the offending files from the archive. Remember not to remove files that are considered part of the core OS or you may not be able to successfully recovery your system from the archive. -This problem is most often encountered with the '-A' option of make_recovery which includes the entire root volume group. If possible, move the locked files to another location outside of the root volume group. It is a recommended practice to keep user data on a separate volume group. Another option you have is to exit from applications that have a lock on files you wish to archive during the archive process. ======================================================================== 4.8 Q: Should I run make_recovery in single user mode or can users be on the system when I do the recovery? A: It is best to have the system as "quiet" as possible before making any recovery. The reason is that the file system and files should be constant as the tools first make a list of directories and files to be recovered and then does the actual recovery. In most circumstances, there will few problems if users are on the system. However, if a user adds a file or directory between the time the list was created and the actual archive is made, the file(s) and/or director(y|ies) will not be on the recovery tape. Worse, if the user deletes a file or directory, it/they will cause a recovery message stating that an expected file/directory could not be located. You do not necessarily need to put the system into single user mode, just try to make sure that the system is as "quiet" as possible with as few (no?) user interactions occuring. ======================================================================== 4.9 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 will prompt for more tapes if they are necessary. NOTE: individual files may not exceed 2GB due to a limitation in the pax command. ======================================================================== 4.10 Q: Why do I get an error from pax saying: linkname greater than 100 characters? I have PHCO_20388 installed. A: This is confusing because of the ambiguous text provided in the patch. Under symptoms, it says: 1. Pax does not handle soft/hard links properly in ustar format if the file/link names have a length >= 100 characters. The patch corrected a problem in handling linknames that were >= 100 characters. These are still limited to less than 100 characters. If you have a linkname that is longer, you will see the error message. Before the patch, this condition was not detected and pax would become confused. Now it is correctly flagged as an error. ======================================================================== -------------------- 5. General Install -------------------- 5.1 Q: There was some confusion about the way that IUX estimated needed file system sizes. IUX seemed to pad the space by about 300 MB. The 10.20+apps+patches load takes about 680 MB, but IUX wanted about 1 GB of file space to install it. Does IUX do anything other that add up the impacts statements? A: It will add 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). make_config 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-10-XX bundles all overlap quite a bit, so that when you load all of them via IUX, it estimates too much space. You should be able to add the sw_impact of all the sw_sel's that you are loading and see what that adds up to. ======================================================================== 5.2 Q: How can I set the timezone such that the install.log file is in local time? A: The TZ environment variable is what governs what timezone the message in the install.log contain. The "timezone" config file keyword does not have any effect on the messages that occur during the install, but does determine the timezone setting on the target system (the two can be independently set). To set the TZ environment variable, it is best to do so in the INSTALLFS file so that it is set as early in the process as possible. However the very first message will still be in EST since it is produced before the config file contents of INSTALLFS are read. The procedure for setting this would be: (note this sets it to MST7DT). # /opt/ignite/bin/instl_adm -d > /tmp/cur_cfg # echo 'env_vars += "TZ=MST7MDT"' >> /tmp/cur_cfg # /opt/ignite/bin/instl_adm -f /tmp/cur_cfg ======================================================================== 5.3 Q: When does IUX configure software? A: The SD configure scripts (as well as IUX post_config_{cmd|script}) are run after all software has been loaded and after the system has booted off of the target disk and final kernel. ======================================================================== 5.4 Q: How do I set the target's final networking information? A: This can be done from the "System" tab of the user interface. Or can be done via the keywords in the config files (see instl_adm(4)). ======================================================================== 5.5 Q: What if I don't want to use DHCP, can I still have IUX automatically determine networking information for all my clients? A: Yes, if you want to have 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 will be 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/inst_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. A minimal example /etc/bootptab entry would be like the entry below (with your own hostname, IP address, and hardware address, and subnet mask). Other networking information may also be specified here, or can be specified via instl_adm. The IP address of the IUX server must be specified with the instl_adm -t option. sysname:\ hn:\ vm=rfc1048:\ ht=ether:\ ha=080009352575:\ ip=15.1.51.82:\ sm=255.255.248.0:\ bf=/opt/ignite/boot/boot_lif (For a known problem using this mechanism, see item 1.11: Q: Using bootptab entries to satisfy the DHCP request doesn't work, why?) ======================================================================== 5.6 Q: On a system with two disks, an internal 400 MB and an external 1 GB, I was unable to change the root disk to the external 1 GB in the UI. The first time I tried, both disks were listed on the UI, but the second time the external disk had disappeared (this was not always true -- sometimes both disks were always listed). I then went to the file system tab in the UI, selected both disks for LVM use, but, although I had 1.4 GB of disk, the UI kept telling me I didn't have enough space. I finally realized that the external disk was on a differential interface, and that HP-UX apparently could not be booted from it. So it appeared that IUX was consulting some rules which said that this disk was not valid as a root disk. The problem was that the disk was listed on the "Root Disk" selection initially, and there was no error message when we picked it. It just reverted to the other disk. If IUX determined that this disk was not bootable, it should have said so! When we finally figured this out, we made the internal 400 MB our root disk, and added the external disk as an LVM add on. The UI kept complaining about not having enough space, so we had to install just the archive with a very small swap (even though we had 1.4 GB of disk space according to the file system screen). We then proceeded with the install. When the system booted the external disk had not been added. A: I think what you may have been running into is the following: When you pick a small disk for your root FS, and pick to use LVM, the default is to not create all the /usr, /var... volumes. You can change this back in the Additional Screen. But, if you don't have the /usr, /var... volumes created, then it tries to put all the software impact into the root (/) volume. However, the root volume must be contiguous, and thus it constrains it to fit on the 400 MB disk. Thus, it complained that there was not enough disk space. Also, the primary swap volume must be on the root disk, along with the root (/) and boot volumes (/stand). The best thing to do in this case is the following: Pick your small root disk. Pick LVM. Go into the "Additional" screen, and toggle the option to create the separate volumes to TRUE. Optionally, in the Additional screen you can also tell it to use more than the one disk. Then add any other disks from the file system tab. With this setup, the root (and /stand, swap) volumes should be small enough to fit on the 400 MB disk, though the others are allowed to cross onto the other disk. ======================================================================== 5.7 Q: How is software in a depot made available for installs? A: Change to the release directory that is appropriate for the software in the depot, then run make_config against the depot. After the config is created run manage_index to make it visible in the Ignite GUI. EXAMPLE: SD depot machine: sdsource SD depot : /var/application_depot For release : 10.20 do the following: cd /var/opt/ignite/data/Rel_B.10.20 make_config -s sdsource:/var/application_depot -c app_name.cfg manage_index -a -f /var/opt/ignite/data/Rel_B.10.20/app_name.cfg \ -c "HP-UX B.10.20 Default" ======================================================================== 5.8 Q: How can I know whether I can install a 64-bit OS on a system? A: When using the B.* version of Ignite-UX (which is capable of installing 11.00 64-bit OS), execute the following: strings /opt/ignite/boot/INSTALLFS | grep 9000 | grep 64 This will produce a list of the known system models that are 64-bit capable. If the second value listed is 64, it can only run 64-bit. If it is 32/64, it can run either 32-bit or 64-bit. If the system model being installed is not there, it is limited to 32-bit only. If you were only interested in one particular model (say a K370), execute the following: strings /opt/ignite/boot/INSTALLFS | grep 9000 | grep 64 | grep K370 If nothing is output, then the model is limited to 32-bit installs only. It is also important to note that certain D- and K-class systems will require a firmware upgrade to support 11.00 (64-bit). Ignite-UX will inform you of this fact, but it can easily get lost amongst everything being logged. Check the install.log file just after the ioscan is done. ======================================================================== 5.9 Q: FDDI software is in my archive, yet IUX requires that I select it, why? A: Ignite-UX will give an error stating that you must select the FDDI software for loading if the following conditions exist: - You are using an FDDI interface during the installation. - There is a sw_sel defined in a config file that has the string "FDDI" in the description. It gives an error prior to starting the configuration phase to avoid the situation of having a system that cannot complete the installation due to the lack of the FDDI drivers. IUX does not have any way of knowing up-front if FDDI is included in an archive and assumes that it is not - just to be safe. If you have the FDDI software in the archive, then you can avoid the error by removing it from your depot, and the re-running make_config to reflect the removal in the associated config file. You may also just select the FDDI software in which case the swinstall command will just skip loading it since it will already be on the system. ======================================================================== 5.10 Q: How many systems can I install at once - in parallel? A: Although there are no set limits in Ignite-UX, you will find that performance will decrease as you reach the limits of your network and server bandwidth. Most users have found that installing about 20 systems at a time from a single server is the most they could do while maintaining reasonable performance and avoiding network errors. 20 at a time also seems to be a reasonable number for the user to keep track of and test when they complete. You may also find it useful to stagger the installs such that they are not all doing the same operation at the same time - and don't all complete at the same time. Using the NFS access method to access archives is suggested in order to avoid a problem seen when installing many systems using the ftp access method. When many ftp and tftp processes are running to a server at once, the tftp commands start getting the error: tftp: recvfile: recvfrom: Can't assign requested address ======================================================================== -------------------- 6. Network Install -------------------- 6.1 Q: What network architectures are supported? A: Version A.1.32 added support for most of HP's supported network interfaces via the bootsys command. However only the built-in interfaces are supported for booting by the firmware on S700's and K/D-Class S800's. See the /opt/ignite/doc/share/release_note document for more information. ======================================================================== 6.2 Q: My 715/50 won't network boot off of my IUX server, why? A: older s700 require rbootd running on the server. if the server is FDDI rbootd won't run. In that case boot from media then switch the source to the IUX server. older ones use RMP not BOOTP and require rbootd to translate and handoff to bootpd. The RMP clients are the older s700 workstations and all DTCs: workstations: 705, 710, 715, 720, 725, 730, 735, 750, 755 The BOOTP clients are the s712 and future workstations, as well as K-class and D-class s800 servers. ======================================================================== 6.3 Q: When the client "searches for bootable devices", the server does appear on the list. However, when I try to boot, I get the following error: IPL error: bad LIF magic A:When I have seen this in the past, it has been caused by either: - not having tftp access to /opt/ignite and /var/opt/ignite, the /etc/inetd.conf file on the server should have an entry such as: 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. Loading Ignite-UX should have set inetd.conf, but something we have not yet figured out has been removing the entries. I suspect some area of sam... - Using a bootptab entry for the client that is referencing a non-existent boot file (bf). - A corrupted /opt/ignite/boot/boot_lif file. - Perhaps some remnants of the old cold-install product conflicting with Ignite-UX (old instl_bootd running) - A defect in the rbootd daemon delivered in patch PHNE_10139. If you have this patch loaded and do not need it for DTC devices, try removing it or updating to patch PHNE_11017 (10.20) or PHNE_11016 (10.10) ======================================================================== 6.4 Q: How do I set up a 9.0X system as a Boot Helper? A: On the install server (on one side of the gateway), do the following: cd /opt/ignite/boot You can make the changes to the actual boot files in this directory, or copy INSTALLFS to another file and make changes to that file by adding a -F option spec to the instl_adm calls below. The rest of this document assumes you just use the "real" version. These changes aren't very extensive, so this should be ok. Run: instl_adm > fs_cfg Run: cp fs_cfg fs_cfg.orig This will save a copy of the current settings, in case you need to restore them later. There already should be a file "fs_cfg.def" which may also be useful as a backup. Edit fs_cfg: Make sure the "server" spec is set to point to this machine. Make sure the "is_net_info_temporary" spec is set to "false": is_net_info_temporary=false Set proper "route_gateway" spec for the *target* machine. In other words, it should be the gateway that the target machine needs to get across to this server. This will be different from what would currently be in there. For example, there should be two lines in the file like: route_gateway[0]="15.2.48.1" route_destination[0]="default" Add the following lines (examples): ip_addr="15.2.43.1" netmask="255.255.248.0" system_name="aname" The effect of the "is_net_info_temporary=false" spec and the ip_addr, netmask, and system_name specs is to use this information for the install (thus avoiding DHCP) AND leave it in /tmp/install.vars on the target system after installation. Set_parms will then run and pick up this info as defaults. If is_net_info_temporary is set to true, the net info will be tossed. The ip_addr and system_name do not need to be (but can be) the final values, just valid temporary values. You could also set "final" net info (actually cause IUX to put it in the rc startup files) by adding additional "final" specifications for system_name, ip_address, etc. Remember, setting a "final" system_name will cause set_parms not to run, so all other needed system info (timezone, routes, etc.) should probably be set along with system_name. Run: instl_adm -f fs_cfg This applies the changes to the INSTALLFS file. All the files in the /opt/ignite/boot directory can then be copied to the helper machine's /opt/ignite/boot directory when ready. NOTE: any further changes MUST be done on the server system and copied over to the helper system. The 9.0X instl_adm command does have the 10.X functionality. On the (9.0X) helper, do the following: mkdir -p /opt/ignite/boot Edit /etc/inetd.conf: Add the following line to the tftp spec. Don't forget to add \ to the line before it for continuation: /opt/ignite Modify the instl_boots spec to be the following (add the -b option): instl_boots dgram udp wait root /etc/instl_bootd instl_bootd -b /opt/ignite/boot/boot_lif Run /etc/inetd -c to reread the config. Copy the /opt/ignite/boot stuff on the install server to /opt/ignite/boot on the boot helper machine. Make sure /usr/adm/instl_boottab on the helper has some IP addresses available/specified. To Perform the Install on the Target: Boot up the target machine to the boot admin menu, and type something like: boot lan.15.1.50.57 install where "15.1.50.57" is replaced by the IP address of the helper machine. If there's only 1 install server available on the subnet, then just typing "boot lan install" should work. At that point, the install should proceed, controlled from the server by default... ======================================================================== 6.5 Q: I put "control_from_server=true" and "run_ui=false" in the INSTALLFS, but I still get prompted for information on the client, what's wrong? A: There are a few possible answers here depending on what you are being prompted for. 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 on the server GUI. The text screen allows you to change the icon name, or switch to a client side install. If the screen is showing two or more lan interfaces to select from, then there wasn't enough information in the config files to tell it which lan to use. Once you select a lan and then select 'Install HP-UX' you should be set. If the screen is prompting you for networking information, then either DHCP didn't respond or there isn't an entry in /etc/bootptab for the client. Enter the network information, select 'Install HP-UX' and continue the install. ======================================================================== 6.6 Q: The bootsys command seems to work in reverse; if we typed "bootsys -w client" the client didn't wait for the server, if we typed "bootsys client", the client waited for the server. A: This was probably due to your running through the UI once on the server prior to running bootsys. The server drops the instruction for the client to start installing and the next time the client boots it picks that up and goes. The message ignite give tries to tell you that the install will happen the next time that "bootsys -w" is used, but does not really say it will happen automatically. And probably the next time you did a bootsys you had not gone though the UI without the client being booted from the server. ======================================================================== 6.7 Q: bootsys does not work on diskless clients, how can I remotely install? A: The bootsys command does not support rebooting diskless clients from the IUX server (neither 9.X nor 10.X diskless). There are no plans to add this functionality due to infrequent requests for it. If you really need to remotely reboot diskless clients from the Ignite-UX server, here are the steps you can take: 1) If you need to duplicate the behavior of the -w or -a options to bootsys, you will need to modify the INSTALLFS file using instl_adm to set the keywords "run_ui" and/or "control_from_sever" appropriately. Or you can do this using the ignite GUI under the Options->Server_Configuration menu (Run client installation UI option). 2) Copy the /opt/ignite/boot directory and contents to the diskless server as /opt/ignite/boot: rcp -r /opt/ignite/boot diskless-server:/opt/ignite/boot 3) Edit the client's entry in /etc/bootptab on the diskless server to set the "bf" (boot file) flag to be "/opt/ignite/boot/boot_lif" Change current bf= setting to: # vi /etc/bootptab bf=/opt/ignite/boot/boot_lif You may also need to set the bootptab entries for the gateway (gw), and subnet-mask (sm). The networking information in the bootptab file will satisfy the client's DHCP request for networking information when it boots. So it will need everything required to contact the IUX server. 4) Run setup_tftp on the diskless server to allow tftp access to /opt/ignite: # /usr/sam/bin/setup_tftp /opt/ignite # on 9.X systems # /usr/sbin/setup_tftp /opt/ignite # on 10.X systems 5) With this setup, the next time you reboot the client from the diskless server it will load the INSTALL kernel and INSTALLFS file system from the diskless server. The client will then contact the IUX server and the installation can proceed as usual. ======================================================================== 6.8 Q: Client "search lan install", the server doesn't appear on the list. A: Things to check 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 you will see messages in syslog.log such as 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/instl_boottab. - A message in syslog.log that indicates that you have no IP addresses in /etc/opt/ignite/instl_boottab is: instl_bootd: No available IP address found in: /etc/opt/ignite/instl_boottab - If the client is an older system that does not use the BOOTP protocol (like 720's, 710's, 735's, 750's) then also look in the log file /var/adm/rbootd.log - and check to make sure that the "rbootd" daemon is running. rbootd always runs, where as instl_bootd is started via inetd and only runs when needed. Also, for these older clients, there is an intentional delay built into the rbootd process when a client wants to do an install boot (as opposed to a diskless boot). This delay causes the server not to show up during the first search. Retrying the search 2 or 3 times may be necessary. ======================================================================== 6.9 Q: Bootsys fails due to insufficient space in the /stand volume, why? A: The bootsys commands needs to copy the two files: /opt/ignite/boot/INSTALL and /opt/ignite/boot/INSTALLFS from the server into the client's /stand directory. This error indicates that there is not enough space in /stand. To fix this, you may need to remove any backup kernels. Also check for kernels in the /stand/build directory (like vmunix_test). ======================================================================== 6.10 Q: Can I have the IUX server and client on different subnets? A: Yes, however it will either require 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 a server to boot from, these packets do not normally cross over subnets. This limits systems to booting from systems only on their local subnet. When your Ignite-UX server is on a remote subnet, you have basically three options: 1) Setup a "boot-helper" system on client's subnet which has the Ignite-UX.MinimumRuntime product loaded. This system will provide the client with the ability to boot the INSTALL kernel and then contact the server once it is booted. See the Ignite-UX Startup Guide for details (/opt/ignite/share/doc/sysadm.html) 2) If the client system is running HP-UX 9.X or later, you can use the bootsys(1M) command from the server to initiate the install of the client. The bootsys command copies the INSTALL & INSTALLFS files to the client's local disks and instructs it to boot from them. So this option avoids the need to do a network boot altogether. 3) Create a minimal bootable tape or CD-ROM to boot from and then point the client to the IUX server once it is booted. (See make_medialif(1M) for details). ======================================================================== -------------------- 7. Media Install -------------------- 7.1 Q: How do I create bootable IUX media with my configs on it? (v1.09) A: In order to create a bootable CD, that contains the golden system images, you will need the "make_medialif" and "instl_combine" commands shipped with Ignite-UX. make_medialif packages up the Ignite-UX components from an Ignite-UX server into a LIF volume that can be put onto a tape or CD-ROM. "instl_combine" is used to combine a LIF and a file system image into one image for use with CD's. make_medialif only deals with making the LIF area of the media. It does not deal with putting the Image archives (or SD depots) onto the media. So, basically what the steps for making a CD-ROM are: 1) Setup an Ignite-UX server and build your golden images using make_sys_image. 2) Build and test your config files to access the image(s) and get that process all working from the Ignite-UX server. 3) Modify the config files that access the archives to point to the archives as you will name them on the CD-ROM. And change the source_type from "NET" to "DSK". IUX expects to find the archive_path relative to the top directory of the CD when mounted. 4) run make_medialif to build a bootable LIF image and have it include all the config files needed, and especially the ones that you modified in step 3. 6) IUX can use either an HFS or CDFS file system on the CD-ROM. CDFS is more portable if you ever want to access it from a PC, or SUN, etc. However, HFS is probably easier to create. So, decide which way you want to go. 7) If you chose to use an HFS file system, the easiest would be to create an LVM logical volume large enough to hold your archive(s). Then, "newfs -F hfs" that device, mount it, and copy your archives to it. 8) Unmount the file system, and use the "dd" command on the logical volume device file to copy the file system image from the logical volume to a regular file. 9) Use the instl_combine tool to wrap the LIF file created with make_medialif "around" the HFS/CDFS file system image (you will need to get instl_combine from us, and which we will probably ship in a future version of IUX). 10) You can take this image that instl_combine modified, and write it to a scratch hard-disk and boot from it to test the process before writing to a CD-ROM. May save some time and $$.. 11) Write the file system image which instl_combine modified to contain the LIF contents to the CD-ROM burner. We use a public domain tool written for linux called "cdwrite". For a DDS tape, the steps are simpler. Instead of a file system on the media, the archives exist in their pure form as separate tape "files" on the media. 1) Setup an Ignite-UX server and build your golden images using make_sys_image. 2) Build and test your config files to access the image(s) and get that process all working from the Ignite-UX server. 3) Modify the config files that access the archives to point to the archives by using the archive_path to contain the tape file location of the archive (i.e. If it is in the location just after the media LIF, archive_path="1")l 4) run make_medialif to build a bootable LIF image, and have it include all the config files needed, and especially the ones that you modified in step 3. 5) Use "dd" to write the LIF file a no-rewind-on-close tape device with bs=2k: dd if=uxinstlf of=/dev/rmt/0mn bs=2k 6) Use "dd" to write the archive(s) to the tape following the LIF file (tape file location "1"), with bs=10k. dd if=uxinstlf of=/dev/rmt/0mn bs=10k ======================================================================== 7.2 Q: Can I make a bootable tape with an SD depot on it? A: Yes, a tape (or CD-ROM) can contain an SD depot. A tape can contain at most 1 depot, and 0 or more archives. A CD-ROM can have as many depots and/or archives as you have capacity for. The SD depot must come as the third tape file on the tape. The archives can be at any tape file location as specified by the "archive_path" keyword. So the second tape file can either be an archive, or can be empty. When putting an SD depot on tape, first craft your config files to have all the sw_source statements that reference the archive and the SD depot. For the SD depot, you can start with what make_config gives you, and then edit the sw_source to set source_type=MT. SD assumes that the depot is the 3rd tape file, when it detects a LIF header on the tape, so there is no need to specify where the depot is on the tape. Then using a no-rewind device (/dev/rmt/0mn) you would: - write the LIF file made by make_media_lif (bs=2k) - Write your archive, or use "mt eof" to create an empty file. - Write the SD depot using "swpackage target_type=tape ..." The tape would then end up looking like the following: ---------------------------------------------------------------- | LIF | archive/or-empty | SD-depot | other archives, or EOT | ---------------------------------------------------------------- For a CD-ROM, you can either have the SD depot exist at the top level of the CD (like the HP-UX CD-ROM's), or you can have one or more depots exist in a subdirectory on the CD. To make a config file for the depot start with the result of running make_config. Then edit it to change the source_type, and change the sd_depot_dir to be the location of the depot directory relative to the top level of the CD-ROM. ======================================================================== 7.3 Q: Why does swinstall of patches hang during the software analysis? A: If you have created a CD-ROM that uses depots containing patches and the swinstall command that is loading the patches hangs, then you may be running into a defect in the "df" command. To be sure, you can type ^C^C^C until you get a prompt asking if you want to stop the install, answer yes, then answer yes to push a debug shell. From the shell run "ps -ef" and look for a hung "df" command. The problem is caused by a defect in the "df" command. The defect is that it hangs when ever it sees a mount entry with a one-character device string (in this case the mount device is "/"). The workarounds for this problem are: - If the core OS is loaded from an archive, make sure that the latest "df" command patch is part of that archive (PHCO_15344) - If the core OS and patches are both in the same depot, and you are using the hw_patches_cfg config file to cause loading of the patches, then add the following to your config file: sw_source "core patches" { pre_load_cmd += " sed '/^. /d' /etc/mnttab > /tmp/mnt.fix && cp /tmp/mnt.fix /etc/mnttab rm -f /tmp/mnt.fix " } - This has been fixed in versions 1.50 or greater. ======================================================================== 7.4 Q: Why do I get DCE / RPC errors (RPC exceptions) during the configuration stage? There is also a 10+ minute "hang" at the end of the SD configure stage, and a failure message is printed at the end of the installation. A: There is an apparent problem with certain SD operations (e.g., swacl) when only loopback networking is enabled. This would occur if the "media only" installation option is selected. The workaround is to install using the "media with networking enabled" option and set up (perhaps temporary) networking parameters: hostname, IP address, netmask, routing, etc. This will allow the SD operations to complete normally. ======================================================================== 7.5 Q: How can I put an OS archive on multiple CD-ROM's? A: If the archive of the system you want to put onto a CD is too large, you may want to consider creating multiple independent archives each of which will fit on the CD(s). The first archive should contain the core HPUX directories. The remaining archive(s) would contain the rest of the system. The first step would be to determine what large (non-essential) directories can be omitted from the core-OS archive, and included it subsequent archive(s). In this example, we will assume the /opt directory will be put into a second archive. It may require some trial and error to exclude enough stuff to make an archive small enough to fit on the CD. Keep in mind that the LIF data on the first CD will require space as well. To create the first core OS 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 Then run make_sys_image as such: /opt/ignite/data/scripts/make_sys_image -f /tmp/specific_files \ -s local -d /var/tmp Then 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-OS 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 Now copy and edit the config file template /opt/ignite/data/examples/core11.cfg (or core.cfg for 10.20 systems) for the first core OS archive. Copy and edit the /opt/ignite/data/examples/noncore.cfg template file for the other archive(s). In addition to the changes required to make it work with a CD-ROM, 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 config files on the CDs. The first CD will contain the LIF data created using make_medialif as well as all the config files referencing all your archives. See the make_medialif(1M) man page, FAQ item 7.1, and the white paper: http://www.software.hp.com/products/IUX/docs/Customized_Install_Media_Paper.pdf 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 installs (golden images) -------------------- 8.1 Q: What does this mean? 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 looks to me as if the NFS mount succeeded, but the file was not accessible from the target machine. Several possibilities: - the file has a different name (check your config files) - the file has the wrong permissions such that it is not readable (check /etc/exports) ======================================================================== 8.2 Q: /etc/nsswitch.conf and /etc/resolv.conf files from my archive don't end up on the install target, why? A: There are certain files which IUX messes with during the configuration process (among them resolv.conf and nsswitch.conf). To end up with the archive versions of these files on your target machines, we provide 2 scripts called os_arch_post_l and os_arch_post_c. These scripts are delivered in /opt/ignite/data/scripts. You will probably only need to modify os_arch_post_l. Copy it to a new name in the same directory and then edit it. Search on resolv.conf and nsswitch.conf for directions on what to change. After the script has been changed, modify your config file which describes the archive to point to the new script. ======================================================================== 8.3 Q: What does "pax_iux: X: Cross-device link", "pax_iux: X: File exists" or "pax_iux: X : Device busy" mean? A: Both of these errors may occur when loading a system from an archive that does not have the same file-system partitioning as the system that the archive was created from. The first error (Cross-device link) is caused when two files exist as hard links in the archive, and when the two files would end up in separate file-systems. For example if you created an archive on a system that did not use LVM, in which case the root file system is all one file-system. And say you have two files, call them /usr/local/bin/f1 and /opt/myprod/bin/f2 are hard links. If you make an archive of this system, and try to apply it to a system that uses LVM and has /usr and /opt as separate file systems, this error will occur. The second and third errors (File exists, and Device busy) may occur when the archive has a symlink, or regular file, that is named the same as a directory or mount point that exists when the archive is loaded. This may happen for example if the original system that the archive was made from has a symlink like "/opt/myprod -> /extra/space". And then when you are loading a system from the archive you decide to create a mounted file-system as /opt/myprod. The pax command will fail to create the symlink because a directory exists in it's place. Is there any way to recover from this failure? yes. When the error happens you will be asked if you want to push a shell (on the target's console). Answer "yes", and from the shell just type "exit 2" to ignore the error and it will continue on. Once the system is up, then you can more easily determine what should be done with the paths it complained about. To avoid the error, the system 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 will have an OD1 option on the ordering information (CPL). This is the factory integrate option. This tells the HP factories to install the software on the customer system before it leaves the factory. HP manufacturing will load the software from a depot using the Ignite-UX process. An end user using Ignite-UX to ignite systems can load applications with Ignite-UX. All HP applications with an OD1 ordering option can be loaded with Ignite-UX from a depot. No applications are tested for proper installation or operation when included in a "golden system" archive that is loaded with Ignite-UX. They may work fine in this mode but it is up to the person producing the "golden system" archive to verify proper installation and operation. Running "swconfig -x reconfigure=true \*" after a golden installation may cause some software to properly configure itself after installation via a golden system archive. ======================================================================== 8.5 Q: How can the OnlineDiag LIF volumes be restored during the installation? A: One possibility is setup a script in the INDEX file, which will be run as a post configure script. For example, add this stanza to the /var/opt/ignite/INDEX file: scripts { "/var/opt/ignite/scripts/diag.sh" } The actual script, diag.sh, is included as an example script in the /opt/ignite/data/examples directory of the 1.50 version of IUX. It basically runs this command: /usr/sbin/diag/lif/lifload -f /usr/sbin/diag/lif/updatediaglif which copies the OnlineDiag LIF volumes onto the root disk. ======================================================================== -------------------- 9. Getting Ignite-UX -------------------- 9.1 Q: What is different about the Web version? A: Nothing, other than it is available 2-3 weeks prior to the media release. ======================================================================== 9.2 Q: Can Ignite-UX bits be retrieved via ftp rather than downloaded from the web? A: Yes but the ftp access is blind. No "ls" can be done in the ftp directory. The permissions on the "swdepot" directory do not have read access. Explicit paths would have to be given. You will need to just trust that they are there and do a "get" of them. That is why the names of the files are listed below. # ftp software.hp.com ftp> cd /dist/swdepot ftp> get ignite_10.20.tar filename choices for 10.20 servers: ignite_10.01.tar ignite_10.10.tar ignite_10.20.tar ignite_all.tar filename choices for 11.00 servers: ignite11_10.01.tar ignite11_10.10.tar ignite11_10.20.tar ignite11_11.00.tar ignite11_all.tar ======================================================================== 9.3 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, i.e., free. ======================================================================== 9.4 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 created under older versions. If you follow some simple guidelines, updating to a new version of Ignite-UX involves running "swinstall" to load 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 will preserve any changes you have made to files under the /var/opt/ignite and /etc/opt/ignite directories. Changes to any files under /opt/ignite will be LOST during the update. It is not recommended to change any files under /opt/ignite, and should only be done under rare circumstances. Guidelines for ensuring easy updates: - Do not modify any files under the /opt/ignite directory. If you need to modify any config files under /opt/ignite, copy them to an equivalent directory under /var/opt/ignite, and modify the INDEX file to use them in the new location instead. Some files and scripts have comments at the top that describe the procedure to use if you need to modify them. If you must modify files under /opt/ignite, then save a copy of your changes so you can re-apply the changes (if necessary) to the new files after updating Ignite-UX. - Make sure you load all Ignite-UX filesets you had before so you don't end up with a mixture of old filesets and new filesets. ======================================================================== 9.5 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 loading 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 load the bundle(s) for the HP-UX releases you plan to work with. For all cases the Ignite-UX.IGNT-ENG-A-MAN fileset can be omitted or removed if you do not want on-line documentation. Usage: What you need: ============================================================= Ignite-UX server to Load the Ignite-UX-XX-YY install HP-UX on clients: bundle(s) for each HP-UX release (XX-YY) which you plan to install onto clients. You can omit the Ignite-UX.OBAM-RUN fileset if your server is 11.10 or later and you don't plan on using make_net_recovery for 10.X clients. Ignite-UX server to You will need the full Ignite-UX-XX-YY support network recovery bundle for each version of HP-UX for clients: that your clients are running. Using only make_recovery You only need the filesets: command: 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 system you are running. Using only make_net_recovery The filesets a client needs will on a client: normally be pushed out by the ignite 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" To setup a system on a remote subnet that is used just to allow a client to do a network boot and then contact a remote IUX server, all you need is: Ignite-UX.MinimumRuntime ============================================================= Keep in mind that it is not a good idea to load a mixture of different versions of Ignite-UX filesets on a system. 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. ======================================================================== -------------------- 10. Loading Patches -------------------- ======================================================================== 10.1 Q: Can patches be installed at the same time the software it is patching is installed? A: Yes, It is recommended that 10.X patches be kept in a depot separate from the software they patch (this is not the case in 11.X). In this way the load_order keyword can be used inside the sw_source to force them to be loaded after the software they patch. And also, the sd_command_line keyword can be used to specify the SD option: "-x match_target=true". For 11.00 core-OS patches, they should reside in the same depot as the 11.00 core OS. This difference is due to the changes made for SD to be "patch smart". See also the document that comes with Ignite-UX called: /opt/ignite/share/doc/ace_hwe_setup ======================================================================== 10.2 Q: How do I prevent backup copies of patched files from being saved? A: When loading HP-UX patches from SD depots, the normal behavior is that the files that are patched are saved, just in case you want to remove the patch at a later date. However, doing this takes up additional space in the /var directory, and so you may want to turn that feature off. The way to turn this feature off is different depending on if you are loading 10.X HP-UX, or 11.X HP-UX. It also depends on whether the patches are coming from the core depot and being controlled by the hw_patches_cfg config file (See /opt/ignite/share/doc/ace_hwe_setup for more info on hw_patches_cfg). For 10.X releases: This feature is controlled by the existence of the file /var/adm/sw/patch/PATCH_NOSAVE. If you don't want to save the patched files, then you need to have a pre_load_cmd that touches this file. This pre_load_cmd can be at the global level or in the sw_source for the patch depot. You can remove this file in a post_load_cmd if you want this feature re-enabled after the load is done. For example: pre_load_cmd += " mkdir -p /var/adm/sw/patch touch /var/adm/sw/patch/PATCH_NOSAVE " # Put PATCH_NOSAVE back to the way it was. post_load_cmd += " rm -f /var/adm/sw/patch/PATCH_NOSAVE " Note that for patches in the core depot that are loaded via the hw_patches_cfg config file, PATCH_NOSAVE is always created and put back the way it was after the core load is complete (see the /opt/ignite/data/Rel_B.10.20/hw_patches_cfg file for details). For 11.X releases: This feature is controlled by an option to the swinstall command. That option is -xpatch_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 if you want it to specified for all loads 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 config file variable: _hp_patch_save_files and made visible to the user in the Additional screen of the UI. To specify this option at the global level (for example in the /var/opt/ignite/config.local file), you can add the line: sd_command_line += " -xpatch_save_files=false " To default the variable controlling the core patches to "NO", you can add the following to config.local (which must be listed after hw_patches_cfg in the INDEX file): init _hp_patch_save_files = "NO" ======================================================================== 10.3 Q: Loading superseded patches causes a failed status, how to workaround? A: When you are loading systems from multiple depots that contain patches, it is easy to run into the situation where patches in one depot supersede patches that have already been loaded from another. The superseded patches will prevent themselves from loading by giving an error. This error is detected by Ignite-UX which causes the icon to turn red and the final status to be a failure. To work around this problem versions 1.45 and later Ignite-UX provides a script called /opt/ignite/bin/fix_patches that can be run on each depot that contains patches. This script modifies the patch's checkinstall script so that it will "EXCLUDE" itself from loading without giving an ERROR. See the document /opt/ignite/share/doc/ace_hwe_setup for more details. There is no man page at this time for fix_patches, run "/opt/ignite/bin/fix_patches -?" for command line syntax. ======================================================================== 10.4 Q: Why do I get errors from swinstall regarding patches in 11.00 depots? A: If you see errors such as: 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 load of the core-OS, the version of swinstall that Ignite-UX placed on the system was replaced with the original (non-patched) version of swinstall that has some defects regarding patch handling. The solution is to ensure that all 11.00 core-OS (ACE/HWE/XSW) patch bundles, and individual patches, reside in the same depot as the core-OS. This configuration ensures that the patches to swinstall are loaded in the same session as the rest of the core. And thus there is never a point in time where a pre-patched swinstall is used during the installation. A common cause of this problem is a defect in the make_depots command that is fixed in the B.2.4 Ignite-UX release. The defective make_depots (which is what is used if you use the GUI to setup the depots) would put some of the patches from the XSW patch bundle into the /var/opt/ignite/depots/Rel_B.11.00/apps* depots. If you have this situation, the work around is to move the patch bundles from the apps* depot(s) into the core depot. This can be done using the swcopy and swremove commands. ======================================================================== -------------------- 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: - http://software.hp.com/products/IUX/docs/network_recovery_Slides.pdf This is a slide set first presented at Interworks '99. It describes the basic capabilities of network recovery. - /opt/ignite/share/doc/makenetrec.txt This describes the basic functionality of network recovery. It explains how to install the product and how to use it. - These manual pages are new or were modified for network recovery: - make_net_recovery(1m) - make_boot_tape(1m) - pkg_rec_depot(1m) - instl_adm(1m) - instl_adm(4) - ignite(5) - /opt/ignite/share/doc/release_note The release note lists new features and known problems with network recovery. ======================================================================== 11.2 Q: How does make_net_recovery differ from make_recovery? A: The most fundamental difference between the commands is that make_net_recovery produces a backup recovery image of a system to an Ignite-UX server, whereas make_recovery produces a similar backup to a local tape device. Based on customer feedback, there are some fundamental issues with make_recovery that the IUX team wanted to resolve when they implemented make_net_recovery. To accomplish this, a new design and a new code base was developed. The result is that the two commands behave somewhat differently. Below is a summary of some of the differences: 1) make_net_recovery can archive more than just the root volume group. You can include files from anywhere on the local file systems. Any disks that have any data archived from them will be re-initialized when the system is recovered. make_recovery limits you to the root volume group (VG), with the exception of when /usr is on a separate VG. 2) While recovering a system after using make_net_recovery, you can use the user interface to make changes to disk/file-system layouts and networking information without changing the basic behavior of the tool. Your changes will be intelligently merged in with the original configuration. By default, recovering a system is an interactive process. When recovering from a make_recovery tape, the process is non-interactive by default, and interrupting the automatic process causes many host-specific configuration files to not be restored. 3) Using the archive of one system to install a different system (cloning) is handled more cleanly when using make_net_recovery. The changes that allow cloning to work better are: intelligent merging of configuration changes, interactive execution, and automatic kernel rebuild when the system model changes. (See FAQ item 11.4 for more details on cloning). 4) By default, both make_recovery and make_net_recovery archive only a minimal set of essential files from the system. The list of minimal files used by make_net_recovery is smaller than make_recovery. In particular, no files from /var or /opt are in that list. The list of essential files for make_net_recovery are contained in /opt/ignite/recovery/mnr_essentials. 5) There is no "check_recovery" command equivalent for make_net_recovery. Because it is so easy to automate running make_net_recovery from a cron job, it is likely that recovery backups will be done on a regular basis and when a known system change happens rather than relying on a tool to detect changes. 6) The command line options to make_net_recovery are quite different from make_recovery. For example, if you want to include all files from the root volume group (vg00) in the archive, you would use the option "-x inc_entire=vg00" instead of -A. 7) make_net_recovery has a GUI that can be invoked from the server's "ignite" GUI using the "Create System Recovery Archive" action. From this GUI you can select which files/dirs, volume groups, disks are to be archived. These selections are saved for use the next time, and are used by default when running make_net_recovery from the command line if you do not supply any -x options. The idea behind this is that you can use the GUI once to configure each client, and then use a generic make_net_recovery command line in the crontab of each client. If you want to use the "ignite" GUI on clients that do not have an icon, use the "Add New Client for Recovery" option from the Actions menu. 8) The "archive_impact(1M)" command is run on the recovery archive produced by make_net_recovery. This command supplies Ignite-UX with the amount of file space consumed on each file-system. The result is that during the recovery, Ignite-UX may increase the sizes of volumes that are close to full (if it has free space in the volume group). This will also prevent you from accidentally reducing the size of a volume below the required size. 9) The software needed to run make_net_recovery is automatically pushed out to the client when using the "ignite" GUI. It is also updated if it becomes out of date. The ignite GUI creates a small "packaged-in-place" depot that is used by clients to install the subset of Ignite-UX needed for make_net_recovery. See examples section of the make_net_recovery(1M) man page for how to automate client software updates when not using the GUI. In a future release, we plan to use the code and design of make_net_recovery to replace make_recovery. At which time the two commands will have fewer differences and similar features. ======================================================================== 11.3 Q: Can I still use make_recovery on a system if I am also using make_net_recovery? A: Yes, it is possible to use both make_recovery and make_net_recovery on a single system. The only issue to be concerned about when doing this is to make sure that the version of Ignite-UX that is installed on the system is consistent. To run make_recovery on a system, most of the Ignite-UX product must be installed. To run make_net_recovery, only a small portion of the Ignite-UX product needs to be installed. It's important that the Ignite-UX filesets installed on a given machine be of the same revision. The simplest way to keep everything consistent is to always install Ignite-UX from a recovery depot built on the Ignite-UX server. This depot can be constructed by running the following: pkg_rec_depot -f on the Ignite-UX server. This creates the /var/opt/ignite/depots/recovery_cmds depot which contains the entire Ignite-UX product. After this depot has been created, swinstall everything from it onto each of your target machines. If you will be doing network recovery from the "ignite" graphical user interface on the server, this installation step happens automatically. As of the A.2.0 and B.2.0 releases, if you try to run make_recovery and the Ignite-UX product is not consistently installed (all filesets do not have the same revision), you will be given an error. If this happens, re-install the Ignite-UX product as described above. ====================================================================== 11.4 Q: How can I clone a system 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 system to install a different system involves manually copying some configuration files, and allowing NFS access to the source system's archive. The steps to clone a system using make_net_recovery are: 1) Use make_net_recovery (or the "ignite" GUI) to create a system recovery archive of the source system. 2) Login to the Ignite-UX server. 3) If the target system to be installed does not currently have a directory in /var/opt/ignite/clients but is up and running, then use the "ignite" GUI to create that directory using the "Add New Client for Recovery" action. If the system is not running, you will either need to boot the client from the Ignite-UX server (or for a tape made with make_boot_tape) in order for this directory to be created. 4) Copy the CINDEX and recovery directory from the source client to the target client directory. Note that if the target client has previously used make_net_recovery then it will already have a CINDEX file. If the CINDEX file for the target system exists already, you may want to save a copy, and/or hand edit the file to add the desired entries from the source client. The commands below will copy the required files, you may specify <src-client> and <target-client> using either the LAN addresses (e.g. 0x0060B04AAB30), or by using the client's hostname (which is a symlink to the LAN 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 system. To do this, login to the server that holds the archive (normally the Ignite-UX server). 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 will need to edit the /etc/exports file to allow access to both the source and target clients: # vi /etc/exports (append ":target-client" to the end of the source-client's line) # exportfs -av 6) Now you can boot the target-client from the Ignite-UX server (using any method you wish). Then when you install the system, you can select from the recovery configurations of the source system. ====================================================================== 11.5 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 FAQ item 11.6, replacing the -d option (which lists the disks and/or volume groups) with the -l option (which instead lists the individual directories and files that will be included in the archive). ====================================================================== 11.6 Q: How can I tell which disks or volume groups will 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 is a file specifying what is to be archived. See the make_net_recovery(1m) man pages for details on the format of the input_file. make_net_recovery can take input from an input file, no input, or input from the command line with the x option. list_expander can take input from an input file, or no input, but does not have an x option like make_net_recovery does, so to see the result of using x options, put them in a file and pass list_expander the file name. If you used the GUI to specify what is to be included in the archive, then the input file can be found on the 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 itself. Omitting the '-f input_file' will cause list_expander to use only the essential files as input. This will show what disks or volume groups will get re-created 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 Column two shows that the system has one whole disk (d) and three volume groups (v). Column three gives the names of the disks and volume groups. Column one shows, for each disk or volume group, if it will be: 2 = included in full (INC_ENTIRE dsk/vg specified), 1 = included in part (some files included, some not), or 0 = not included at all (no files from this dsk/vg are included). A 0 means the disk or volume group will NOT be touched. A 1 or 2 means that the disk or volume group WILL be re-created, and files from the archive will be restored. ====================================================================== 11.7 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 method 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 will contain everything needed to recover your system, including the archive of your system. During recovery, no access to an Ignite-UX server is needed. A description of the process required to construct such a tape can be found in the /opt/ignite/share/doc/makenetrec.txt file. The second method is useful when you do not have the ability to boot the target machine via the network, but are still able to access the Ignite-UX server via the network for your archive and configuration data. This could happen if your machine does not support network boot or if the target machine 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. See make_boot_tape(1m) for details. ===================================================================== 11.8 Q: Which files does Ignite-UX change during an installation from a make_net_recovery configuration? A: During a system recovery, Ignite-UX strives to restore the system 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 system configuration files. When you run make_net_recovery, a lot of system configuration information is gathered and saved in config files that are used later when the system is recovered. During the system recovery the user is allowed to make changes to this information, in which case Ignite-UX will make the appropriate changes to the system configuration. If a user does not make any changes, then it simply re-applies the same information and you should see no change to the system in the end. Most of the system configuration files that Ignite-UX will modify are listed in the script: "/opt/ignite/data/scripts/os_arch_post_l". The os_arch_post_l script checks for the system recovery case by checking the $RECOVERY_MODE variable. When this variable is TRUE, the os_arch_post_l script causes some configuration files to be protected from modification by using the "save_file" function. os_arch_post_l uses the "merge_file" function on files that Ignite-UX knows how to intelligently merge information into. 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 the file explain any exceptions. Because the list of files modified by Ignite-UX may change from release-to-release, it is best to look at the os_arch_post_l file on your system to see which files are saved as-is and which are merged with information from the IUX config files. ===================================================================== 11.9 Q: How can I keep archive(s) 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 system. 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 archive(s) are removed as new archives are created. The number of archives that get removed is based on the number of archives specified to be saved (the -n option to make_net_recovery). One way to ensure that known "good" archives are saved would be to specify the number of archives to save to be greater then the maximum number of archives you plan to store on the system at any given time. This would cost disk space. An alternative and better approach to saving known "good" archives is to rename the archive and edit the configuration file to include the new archive name. The steps below explain this process in detail: 1. Login to the system where the archive is being stored. (NOTE: This system could be different from the Ignite-UX Server). 2. Rename the archive. (The path to the archive may be different than the example below). The name of the archive to save can be anything unique, but it should be outside the naming convention "yyyy-mm-dd,hr:min" cd /var/opt/ignite/recovery/archives/<system_name> mv old_archive_name saved_archive_name Example: % 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 system. 4. Edit the following to reference new archive name: /var/opt/ignite/clients/<client>/recovery/<old_archive_name>/archive_cfg Change the archive_path variable inside the (source_type == "NET") conditional to the name of the saved archive. Example: (source_type == "NET") { archive_path = "Recovery_Archive.0511.save" }else { archive_path = "1" } 5. (Optional) Edit the cfg tag entry in the file: /var/opt/ignite/clients/<client>/CINDEX so the that configuration will be unique and descriptive when it is viewed via the Ignite-UX User Interface. Example: Change from: cfg "1999-05-13,06:51 Recovery Archive" { description "Weekly System Recovery Archive" . . } To: cfg "Saved Recovery Archive" { description "Weekly System Recovery Archive" . . } ===================================================================== 11.10 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 will automatically be included into your recovery configuration for this client each time you run the make_net_recovery command. Note that make_net_recovery is run for you when you use the graphical user interface 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.11 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 that you intend to recover from. If you want to add HP's 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.10.20/config would be added for a client with the HP-UX 10.20 operating system. This new configuration file entry should be the first entry in the clause you are modifying. When you bring up the user interface during recovery, select the "File System" type you wish to use on the "Basic" tab. ======================================================================== 11.12 Q: How can I keep make_net_recovery version 2.0 from erasing volume groups that contain only unmounted and raw logical volumes? A: make_net_recovery version 2.0 has a bug in it which causes volume groups that contain only unmounted and raw logical volumes to be re-created but not restored, causing loss of data. When recovering a system, the user can specify to not recreate these volume groups, so that data is not lost. However, the user will need to manually import these volume groups after recovery. This problem has been fixed with version 2.1 ======================================================================== 11.13 Q: Why can make_net_recovery fail when the archive is 2GB or more? A: make_net_recovery uses NFS to write/read the system archive from the client to/from the server. To manage archives greater than 2GB requires that both the client and server use NFS protocol version 3 (PV3). NFS PV3 is available for HP-UX 10.20 when the Networking ACE set of patches are loaded. And is standard on 11.00. If you know you have NFS PV3, and are having problems, then check the following: - If you are using the "A" version of Ignite-UX, you must have version A.2.1 or later. - If you are using the "B" version, you must have B.2.0 or later. - Some NFS patches in the past have caused problems with >2GB files. These problems have been fixed in patches: 10.20: PHNE_22117 (s700 and s800) 11.00: PHNE_22125 - If your NFS server is running 10.20 with the newer NFS patches, then the /etc/rc.config.d/nfsconf file has a configurable parameter (MOUNTD_VER) which determines if the default mount should be PV2 or PV3. This must be set to 3. - If your clients are running 10.20 with the newer NFS patches, then the /etc/rc.config.d/nfsconf file must have the parameter "MOUNT_VER" set to 3. ======================================================================== 11.14 Q: How can I keep make_net_recovery version 2.0 and 2.1 from core dumping when I have more than 8 volume groups? A: make_net_recovery and the Network Recovery GUI (mnr_ui) version 2.0 and 2.1 have a bug which causes core dumping on systems with more than 8 volume groups. A downloadable fix is due to be available on the web the first week of September of 1999. ( http://software.hp.com/products/IUX ) This problem will be fixed with version 2.2 ======================================================================== 11.15 Q: How can I keep make_net_recovery version 2.0 and 2.1 from crossing and archiving files from NFS mounts when I have symlinks from essential directories to NFS mounted directories, and when there is a symlink in the pathname to the directory? A: make_net_recovery (in IUX versions 2.0 and 2.1) may cross and archive NFS mounts if an essential directory has a symbolic link to something that is NFS mounted, and the path to the NFS mounted directory contains a directory which is a symlink. A downloadable fix is due to be available on the web the first week of September of 1999. ( http://software.hp.com/products/IUX ) This problem will be fixed with version 2.2 ======================================================================== 11.16 Q: I replaced the client system, and the LAN address is now different. How can I restore the new system from the old net-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 (i.e. LANIC, LLA, MAC address, etc). If you replace the client hardware - or even the LAN card that the old LAN address was based on, then it will no longer access the same directory on the server. The simplest solution is to obtain the new LAN address, which you can do from the boot-ROM console command LanAddress (actual command may vary from system to system). Once you have the new address, then manually rename the directory. You may just remove the hostname symlink (it will be recreated automatically). Note that the LAN address must be in all upper-case, and begin with 0x. If you already booted the client from the server which caused it to create a new directory, you can just remove that directory before renaming the old directory. Be careful not to remove the original directory or else you will loose the recovery information. For example: # cd /var/opt/ignite/clients # mv 0x00108300041F 0x00108300042A # rm oldhostname ======================================================================== 11.17 Q: Why do I get the error: "The minor number of the volume group exceeds the value IUX can support."? A: See question: 4.6 ======================================================================== 11.18 Q: Dealing with hot swappable disks during recovery A: See question: 4.7 ======================================================================== 11.19 Q: Why does make_net_recovery hang while trying to write the archive? A: During archive creation, both make_recovery and make_net_recovery can hang while attempting to read files with mutually exclusive locks (see lockf(2)). A file lock set with F_LOCK enforcement will cause a process to sleep while attempting to read that file. If this is the problem then you will see a pax(1) process in the sleep state that has blocked on a locked file. How to find the offending file: A capital 'S' character in the execute permission bit for a file is one indication of this kind of lock. The tools glance(1) or gpm(1) can be used to view all files in use by a process, and will easily help you identify the locked file. Locate the pax(1) process that is attempting to archive the file and use glance or gpm to view files that it is using. Another method that can be used to determine the offending file is to examine the partially created archive file. Archive files by default are located in: Serverhost:/var/opt/ignite/recovery/archives/<hostname> The following command will allow you to view the last files to be archived: gzcat <archive file> | tar -tvf - | tail You can utilize the list_expander utility (see FAQ entry 11.5) to see the files that should be included in the archive in the archive order. Compare the last entries in the incomplete archive against the list_expander results to figure out the file that pax was working on when it hung. Work around: The hanging behavior that is occurring is the appropriate behavior under these circumstances. There is no way to archive files while they are locked in this manner. For this reason you must exclude locked files from the archive. This also means you cannot lock files that are part of the minimal set of archive files built into make_net_recovery. You can can control the contents of the archive using the '-x' option of make_net_recovery(1M), or with the content description file /var/opt/ignite/clients/0x{LLA}/recovery/archive_content. See the make_net_recovery(1M) man page for rules on how to control archive inclusions and exclusions. EXAMPLE: make_net_recovery -s <server> \ -x inc_entire=vg00 -x exclude=<locked file/dir> The command above will write a recovery archive to the server in the default file system location and include all contents on the root volume group 'vg00' except for the excluded 'locked file/dir'. This example assumes that the locked file/directory was located within the volume group we are archiving. Note: Exclusions are hierarchical so you are also excluding all files and directories under 'locked file/dir' if it is a directory. Remember that you cannot exclude files or directories that are included in the essentials list. See the make_net_recovery(1M) man page for more information on the essential list of files and directories. Other options include unlocking files to be archived or moving files that need to be locked to locations on the file system that will not be archived. For a quick resolution you can exit from applications that have locks on files you wish to archive during the archive process. ======================================================================== 11.20 Q: Why does archive_impact fail during make_net_recovery A: A patch was issued for ksh(1M) which in turn causes corrupt parameter processing. The corruption occurs when archive_impact is run as a part of a make_net_recovery. The patch is: PHCO_21185. Work around: PHCO_21185 has been superseded by PHCO_22020. Please remove PHCO_21185 and install PHCO_22020. ======================================================================== End of FAQs Sources for this document: web - http://software.hp.com/products/IUX/docs/iux_faq mail - null message to iux_faq@igniteux.fc.hp.com (most current)