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