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
Ignite-UX All the filesets should have the same revision; if not,
then you need to install all consistent versions.
If you have
boot helper
systems, they also need to have the Ignite-UX product updated to match
the same revision as the server that they reference.
Top
A: No. 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.
Top
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_net_recovery(1M).
Top
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 "
}
Top
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.
Top
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
"
Top
A: On some HP-UX 11.x clients you might
see the following errors when recovering a client from a
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).
Top
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 interfaces,
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-UXserver is an
11i system the transport for NFS will be TCP and performance will
suffer. HP-UX 11.00 only uses UDP for NFS by default so the performance
problems are not seen. There are several solutions available:
- Change the switch duplex setting of the client being installed to
autonegotiate for the duration of the install.
- 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
- Ignite-UX provides the libraries needed to use the lanadmin
-X option with 100BT and 1000BT interfaces. You can add the lanadmin options to be
applied to a LAN interface with the
_hp_lanadmin_args variable in 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 lanadmin(1M)
for more information about available options.
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, 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.)
Top
A: This is a known issue with Ignite-UX
and VxVM installs involving disk group names that were used on disks in
a prior installation though not the current install.
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 install. 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.
Top
A: It depends on what SecurePath is
controlling. Ignite-UX does not support active/passive EVA GL
(EVA3000/EVA5000) disk arrays because of multiple known issues. For
more information about potential issues you may encounter, please read
the latest version of the Ignite-UX release notes and search for EVA.
You should note that these issues do
NOT affect active/active EVA GL or any EVA XL disk arrays. These disk
arrays are fully supported for use with Ignite-UX.
Top
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.
Top
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
"
Top
A: HP has not tested Ignite-UX through a firewall.
It should be possible to configure a
firewall such that Ignite-UX functions properly. For more information,
see the "Configuring Bastille to Operate with Ignite-UX" white paper
available in the 11i v2 (B.11.23) documentation collection on
http://docs.hp.com
As the white paper above indicates, HP
does support Ignite-UX in conjunction with Bastille on HP-UX 11i v2.
The white paper describes how to configure Bastille on both Ignite-UX
servers and clients.
Top
A: When installing or recovering a
system, Ignite-UX takes a small amount of space (a few MB) in each of
the
/ and
/usr file systems to hold
some commands that Ignite-UX will use. Some of these commands are used
during the installation or recovery of HP-UX, and some are used after
the first reboot.
If the
/ or
/usr file
systems are nearly full when creating a golden image (and
configuration) or recovery archive, or when installing an SD depot
where the impacts will leave file systems nearly full, and you have set
_hp_ignore_sw_impacts to 1 as follows:
init _hp_ignore_sw_impacts=1
It is possible that you may encounter
a file system full problem during recovery or installation. Normally,
the configuration variable that controls how much free space should be
in a file system increases the size of a file system so there is at
least 10% free; 10% being the default value. This default value
guarantees that there is enough free space for an installation or recovery.
Setting
_hp_ignore_sw_impacts
to 1 means that Ignite-UX will not resize the file systems according to
impacts to guarantee some free space. If you set
_hp_ignore_sw_impacts to
1, you must ensure that there is some free space available in
/ and
/usr during installation
or recovery (at least 20MB) to avoid file system full issues.
If you do not set
_hp_ignore_sw_impacts
to 1, you can ignore this information. This issue is most likely to affect
you if you create a recovery archive in which you have set
_hp_ignore_sw_impacts to 1
in the installation file system or
config.local
files and you have a nearly full
/
or
/usr file system.
Top
A: The C.6.5.61 (December 2005) and newer
versions of Ignite-UX contain the B.11.23 patch PHKL_33110 which
includes install kernels to resolve an issue where files on ISO9660
media cannot be correctly read if they are 2 GB or greater in size.
When encountering this problem the symptoms look like.
* Loading software: Begin
* Installing boot area on disk.
* Formatting HP Service Partition.
* Enabling swap areas.
* Backing up LVM configuration for "vg00".
* Processing the archive source (hp client archives).
* Thu Nov 03 12:37:56 EST Starting archive load of the source \
(B.11.23 client archive IA).
* Completed 0% of archive
gunzip: stdin: unexpected end of file
pax_iux: The archive is empty.
ERROR: Cannot load OS archive (B.11.23 client archive IA)
The configuration process has incurred an error
would you like to push a shell for debugging
purposes? (y/[n]):
Patch PHKL_33110 contains the defect fixes for JAGaf44970 and JAGaf67476.
NOTE: Ignite-UX version C.6.8 contains the equivalent fix for HP-UX 11.11.
Top
A: To reduce the amount of time it takes
to perform a network boot, you should use an Ignite-UX server that is
running a tftp daemon (tftpd) that supports the "tsize" option.
When the firmware on an Itanium-based
system is downloading a file (i.e. booting), it first attempts to
determine the size (in bytes) of the file. If the tftp daemon (tftpd)
on the server does not support the "tsize" option, the client downloads
the file using the following steps:
- Download the entire file (not storing the data), counting the bytes
- Allocate a buffer which is the exact size of the file
- Download the entire file (again) into the allocated buffer.
The B.11.11 patch that enables the "tsize" feature is PHNE_32825, which was posted on 20-Mar-2006.
NOTE: HPVM requires this patch
if you are installing a virtual machine from an Ignite-UX server
running B.11.11. Not having this patch installed on the server will
cause the network boot to fail because of a firmware defect. No tftpd
patch is required for B.11.23 onwards as the tftpd daemon supports the
"tsize" option from first release.
Top
A: This error is caused by the way device
special files are managed while restoring a prior instance number
assignment of the ext_bus class devices (this instance number appears
in the device file names for disks following the 'c' character).
For VxVM, the device files must not be
renamed prior to the kernel knowing about the new instance assignments,
and for LVM/whole disk, they must be renamed prior. So when the system
has a mixture of VxVM and LVM/whole-disk there is a chance that device
files used by one or the other need to be exchanged resulting in a conflict.
In the case of fibre channel devices,
the kernel can sometimes assign different instances for the ext_bus
devices each time the system boots Ignite-UX. So in these cases, if you
get the error, simply rebooting and retrying may result in success.
If retrying does not resolve the
problem, you can work around the problem for recovering a system by doing:
- When using an Ignite server to do a network recovery, on the Ignite server, do:
- Edit the "system_cfg" file under the correct directory for the recovery you are doing.
For example: /var/opt/ignite/clients/{client}/recovery/latest/system_cfg
- Comment-out (using the '#' char) the "hw_instance_num" keyword for the ext_bus device referenced
by the hardware path in the error message.
- The result of doing this is
that disk devices attached to that ext_bus will be assigned a different
instance number and have a different device file name than before.
- It is possible to still run
into the problem with just the one line disabled. You can either keep
trying and disabling the next entry, or disable all hw_instance_num
lines if desired.
- When using a tape recovery, you
cannot disable just the one hw_instance_num value as you can with a
network recovery. For tape:
- From the first UI screen, select the "Advanced Options" menu.
- From the "Advanced Options" menu, select "Edit (vi) config file"
- From the vi editor, add one line such as:
hw_instance_num = 0 "ioa" "sba" 0
- This will override the hw_instance_num values from the other config files on the tape.
- The system will not attempt to restore any prior device file naming because of this.
Top
A: If an Ignite-UX version C.6.8 - C.6.10 was used to create
a recovery image, and then an Ignite-UX version C.7.1 - C.7.6 was used to recover that image,
you might see errors like this:
ERROR: 0x40041e30: IOTree::parse_io_info_line:io_info version is not
understood: 0.5
ERROR: Fatal error while parsing io.info file
ERROR: Cannot initialize I/O data: unable to parse
/var/opt/ignite/clients/0x00306E48CE61/io.info file.
The cause of these ERROR messages is that versions C.6.8 - C.6.10 of Ignite-UX create a version
0.5 io.info file. When a recovery is attempted with versions C.7.1 - C.7.6 of Ignite-UX, it is
unable to parse the old 0.5 version of the io.info file.
To work around this issue, you can do ONE of the following:
- Run Actions -> Refresh Client from the Ignite user interface.
- Use "Boot Client" from the Actions menu to boot the client in preparation for installing from
the Ignite user interface.
- Use the client's console to boot from the Ignite-UX server.
- Delete the io.info file in the client's directory.
Top
A: Only /opt/ignite and /var/opt/ignite are needed for tftp access.
Top
A: For this information, refer to
copy_boot_tape(1M).
For information on how to copy a recovery tape for an HP Integrity
server, see the document KBNL00000970 in ITRC titled, "How do I
duplicate a recovery tape from a HP Integrity server?"
Top
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. Please also refer to the discussion regarding SAS disks in
the Ignite-UX release notes for version C.6.8.
Top
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 that to include files larger than
2GB but less than 8GB you may need to install patches. On
HP-UX 11i v1 (B.11.11) you must have PHCO_28414 or later installed. On HP-UX 11i v2 (B.11.23)
you should have PHCO_31634 or later installed. Otherwise files will be limited to
being less than 4GB in size.
Top
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 filesystem, 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.
Top
A: To include all volume and disk groups
on the system into a recovery tape (which can also be used with
make_net_recovery) use the
following command:
make_tape_recovery -A -x inc_cross=/
The
make_tape_recovery
manpage 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.
Top
A: At this time, multi-byte characters
are not supported in file names.
Top
A: When you recover a system using a
recovery archive, you can extend the existing logical volume size in
the
File System
tab of the Ignite-UX GUI. However, the current tool does not allow you
to create a new logical volume instead of using the old one.
Top
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).
Top
A: Answer yes to push a shell, then move
the file aside to a new name that will not conflict with any other file
name. For example:
# mv "/sbin/%sh" "/sbin/%sh.remove"
Then continue the recovery
installation process by typing
exit
2 and then pressing Return. If you move the files to a name
that has something in common, they will be easier to find and remove
post-recovery.
NOTE:
Files starting with
% (such as
/sbin/%sh) are created by
Ignite-UX during a recovery or installation session. These files remain
on a system if an error occurred during the last recovery or
installation before they could be cleaned up. Problems during recovery
or installation should be investigated immediately; failing to do so
can cause problems with subsequent recoveries.
Top
A: When recovering an Itanium-based
system from a recovery image created with
make_tape_recovery
that does not support
Itanium®-based
tape boot, you must perform a two-step recovery. This requires both a
recovery tape of the system and bootable CD or DVD containing the same
revision of Ignite-UX; for example, C.6.6.
x.
If you are using a version of
Ignite-UX that does not have a corresponding set of Operating
Environment media, you must create a custom bootable CD or DVD to
recover from the recovery tape. Instructions on how to create this
bootable media are available from the following locations:
- In the
"Creating Your Own Installation Media" chapter of the Ignite-UX Administration Guide,
available in the Information Library.
- In the Ignite-UX
Custom Configuration Files document, available in the Information Library,
locate the following section:
"How do I create the CD equivalent of a tape created by make_tape_recovery?".
NOTE: make_media_install, found
in
/opt/ignite/data/scripts/examples,
is an example script delivered with Ignite-UX C.6.2.
x and
greater. You can use this script as a guideline to create a bootable CD
or DVD that may be used for dual-media recovery.
Top
A: Ignite-UX provides no functionality to
allow you to retain custom settings for minor numbers in device files.
A significant fraction of device files are recreated using the
insf -e command after a
recovery or golden image installation. This includes the
/dev/async device file (which
will be used in the examples below).
You do have several options:
- Change your per-system post recovery instructions to remind you to look at the
setting of /dev/async
(the minor number) to ensure it is as it should be for this system.
- Write a startup script that looks at /dev/async
and verifies that it has the minor number you would expect. If it is
not the expected value, recreate it in the startup script.
It is important to note that anyone can run the
insf -e
command that would create this device file, not just Ignite-UX during a recovery.
NOTE: If the
/dev/async
device file needs to be customized, make the change before the database starts.
Top
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.
Top
A: The Software Distributor configuration
and Ignite-UX
post_config_cmd
and
post_config_script
scripts are run after all software has been installed and the client
has booted the final kernel from the target disk.
Top
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)).
Top
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/inst_boottab. In
this case, you would then boot the clients using
boot lan instead of
boot lan install. Only
clients known in
/etc/bootptab
would be able to boot if you do not use
instl_boottab.
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 this
question.
Top
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"
NOTE: The
make_config command
only works on bundles. If the software is not contained within a
bundle, you must either create bundles for it using the
make_bundles command
or manually create configuration files for your software.
Top
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
re-running
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.
Top
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 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
ftpand
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
NOTE: You may need to make SD
configuration changes to cope with a large number of concurrently
installing clients. Please read the section on performance
considerations for SD-UX based installs in the manual "Ignite-UX Custom
Configuration Files" available at:
http://docs.hp.com/en/IUX/infolib.html
Top
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 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: 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.
Top
A: On HP-UX 11.23 and above, the
restriction on swap spaces being less than or equal to 32GB has been
removed. The same is not true of HP-UX 11.11, Ignite-UX will
limit the size of a swap space to be 32GB or less.
To fully enable any amount exceeding
32GB on HP-UX 11.11, it requires adjustment of the kernel
parameters
swchunk
and
maxswapchunks
post installation.
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.11 and later are 4GB 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 32GB, 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, 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
swchunkduring
an Ignite-UX installation you can place a line like the following in
the Ignite-UX configuration:
mod_kernel += 'swchunk 4096'
With
swchunkset
to 4096 you are able to utilize up to 64GB 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 256GB of addressable swap with both
swchunkand
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).
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
swchunkpast
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.
Top
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.
Top
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 non-existent 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.
Top
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.
Top
A: This is probably you ran through the
GUI once on the Ignite-UX server prior to running
bootsys. 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 that
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.
Top
A: Check the following on the Ignite-UX
server that you are trying to boot from:
- 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
Top
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).
Top
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 the Ignite-UX
Administration Guide.
- Use
the bootsys
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).
On HP Integrity servers, use direct boot profiles (if your system supports
them) and directly contact a remote Ignite server without needing a
boot helper.
Top
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.
Itanium®-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/inst_boottab
file do not apply to
Itanium®-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 an /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
Top
A: No. Clients whose primary LAN is
configured with HP Auto-Port Aggregation, APA, bundle tag J4240AA, can
only be successfully installed with
/opt/ignite/bin/bootsys
if the LAN is deaggregated during the bootsys process. During the HP-UX
installation process, the APA software is not present and therefore the
virtual LAN configuration is not valid.
Also, on systems that only have an APA
network interface, during an Ignite-UX recovery operation the Ignite
user interface (itool) will not display any networking information.
If a system has an auto port aggregate
(APA) configured, Ignite-UX does not support cloning using that
recovery archive. It is only supported to recover the archive to the
system on which it was created. This assumes that the lan interfaces
are still configured for APA, on the switch they are connected to, in
exactly the same way as when the archive was created.
Top
A: No. Ignite-UX does not currently
support installation over IPv6.
Top
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.
Top
A: If the archive you want to put onto a
CD is too large, you should consider using a DVD instead. If your
system only has a CD writer, you should then 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 in 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 follows:
/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
Ignite-UX Administration Guide
chapter on creating your own installation media.
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.
Top
A: HP-UX 11i v3 (B.11.31) for September 2007, HP-UX 11i v2 (B.11.23)
for December 2007, or a later release is needed for vMedia install.
Top
A: If vMedia and the HP-UX kernel perform a very
fast, simulated USB DVD device attach during boot, installation will work as if
the vMedia DVD were a build-in DVD device.
It is much more likely the HP-UX kernel will not discover the boot source
device and Ignite-UX will complain that the source device is not found:
WARNING: Could not find Q_BOOT device. \
Cannot determine what the boot device was.
ERROR: Could not get io-device data (ioscan)
WARNING: Could not find source device in ioscan output. You must select
from the list of devices below to use for the source device:
A few seconds after these messages are displayed, a USB attach message will show
on the console. Use the r (rescan) option to request Ignite-UX to repeat I/O
inventory to allow discovery of the vMedia device. After rescan, select the
vMedia device from the list of possible source devices. This is required because
the kernel will not determine the boot source during rescan. After selection
of the source device, installation will then continue normally.
Top
A:
gunzip: stdin: unexpected end of file
pax_iux: The archive is empty.
ERROR: Cannot load operating system archive (HP-UX Core
Operating System Archives)
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.
Top
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.
Top
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,
_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 it's 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 soft links between
directories that are likely to be created as separate file systems.
Top
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. HPmanufacturing 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.
Top
A: Usually 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.
On some occasions, the web release will contain additional fixes not present
in the media release.
Top
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.
Top
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. If you are unsure of
exactly what to install to perform the update, please read the white
paper, "Installing and Updating Ignite-UX" available from the following
URL:
http://docs.hp.com/en/IUX/infolib.html
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 mixture of old filesets and new filesets.
Top
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.
- 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. It may be easier to install the B5725AA bundle (for
versions of Ignite-UX before C.7.0) or IGNITE (for versions of
Ignite-UX from C.7.0), note that the IGNITE bundle is the same as the
B5725AA bundle - it is only a new name.
- Using
only make_tape_recovery
on clients - Create the recovery commands depot on your
Ignite server and install the HP-UX release specific bundle applicable
to your system, or if you have downloaded Ignite-UX from the Web,
install the release specific version of Ignite-UX from that depot. that
bundle contains everything required to create a recovery tape.
- 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 bundle IUX-Recovery should be installed from the recovery commands
depot to support.
- 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 mixture 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.
Top
A: The media versions of Ignite-UX have
the
os_release
attribute set to match the revision of the media (i.e., B.11.11 or
B.11.23 or B.11.31). 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
Top
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:
-xpatch_save_files=false|true
You can use the
sd_command_line
keyword either at the global level, or within individual
sw_source clauses
depending on whether you want it to be specified for all installs 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"
Top
A: When Ignite-UX installs the
core-operating system and patch bundle from the Installation 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.
Top
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.
- The following manpages are applicable to network recovery:
- make_net_recovery(1M)
- 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.
- The recovery white papers, "Successful System Cloning using Ignite-UX" and
"Successful System Recovery using Ignite-UX" at:
http://docs.hp.com/en/IUX/infolib.html
Top
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:
- Use make_net_recovery or the
Ignite-UX GUI to create a recovery archive of the source client.
- Login to the Ignite-UX server.
- 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.
- 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 hostname which is symbolically linked to the MAC address.
cd /var/opt/ignite/clients/src-client
find CINDEX recovery | cpio -pdvma ../target-client
- 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. For Ignite-UX
servers running releases prior to 11.31, you must edit the /etc/exports
file to allow access to both the source and target clients as follows:
- #vi /etc/exports
- Append tt class="computeroutput">:target to the end of the source client's line.
- #exportfs -av
where target
is the hostname of the target system. See exports(4)
for more information.
For Ignite-UX servers running 11.31 or later, you must edit the
/etc/dfs/dfstab file to allow access to both the source and target
clients as follows:
- #vi /etc/dfs/dfstab
- Append ,ro=target
to the -o argument
of the source client's line.
- #shareall -F nfs
where target
is a fully qualified client name. Note that since this client
should not be creating an archive, the client will not have write
access to the archive directory. See dfstab(4)
for more information.
- 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.
Top
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).
Top
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(1M)
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 pass
list_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 re-created for the minimal archive.
The following is an example of the output:
In? dsk/vg name minor# Associated disks
0 d /dev/dsk/c0t3d0
1 v /dev/vg00 0x00 /dev/dsk/c0t6d0 /dev/dsk/c0t4d0
0 v /dev/vg01 0x01 /dev/dsk/c0t1d0
0 v /dev/vg02 0x02 /dev/dsk/c0t2d0>
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.
Top
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)
Top
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 re-applies 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.
Top
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:
- Login
to the system where the archive is being stored; this system could be
different from your Ignite-UX server.
- 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
- If the archive server is different from the Ignite-UX server, login to the
Ignite-UX server.
- Edit the following file to reference the new archive name:
/var/opt/ignite/clients/client/recovery/old_archive_name/archive_cfg
Change the archive_path variable
inside the (source_type ==
"NET") conditional to the name of the saved archive. For
example:
(source_type == "NET") {
archive_path = "Recovery_Archive.0511.save"
} else {
archive_path = "1"
}
- 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"
.
.
.
}
Top
A: Create a new Ignite-UX configuration
file called
/var/opt/ignite/clients/0xLLA/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/0xLLA/CINDEX
file to include a reference to
recovery/config.local
in all of the configuration clauses.
Top
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/0xLLA/CINDEX
file for the client you are recovering.
The
CINDEX file contains one or more
configuration clauses that refer to the recovery images you have
previously created with
make_net_recovery.
Add a new configuration file entry to the clause that you intend to
recover from. If you want to add 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.
Top
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 hostname because it is
recreated automatically. The LAN address must be all in upper-case 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 oldhostname
Top
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.
Top
A: The
make_net_recovery/
make_tape_recovery tools
will create a recovery archive for a client with 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.
Top
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 documentation at the HP Technical
Documentation Web site.
Top
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:
- Mount all file systems:
/sbin/mountall
- Disable DNS so that /etc/hosts is used:
mv /etc/resolv.conf /etc/resolv.conf.save
- Set your client's hostname, where hostname
is the name of your client:
/sbin/rc1.d/S320hostname start
- Set up loop back networking:
/sbin/rc2.d/S008net.init start
- Start the networking daemon:
swagentd
- Start the recovery tool you intend to use make_[tape|net]_recovery:
make_[tape|net]_recovery
NOTE:The -s option of make_tape_recovery
is not supported in the single user mode.
- 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:
- Mount all file systems:
/sbin/mountall
- Start the SD-UX daemon:
swagentd -r
- Start the recovery tool you intend to use make_[tape|net]_recovery:
make_[tape|net]_recovery
NOTE: The -s option of make_tape_recovery
is not supported in the single user mode.
Top
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
A: In situations where a system needs additional software installed to support
restoring a recovery archive onto a different hardware platform, or perhaps a vPar or HPVM, you can load additional
software from a depot during the recovery.
To do this, generate a config file using make_config for the depot containing the additional software. Then
add the path to that config file to each recovery clause desired in the /var/opt/ignite/clients/<client>/CINDEX file.
The example below will create a config file and add it to all entries in the client's CINDEX file.
# make_config -s <depot> -c /var/opt/ignite/data/Rel_B.XX.YY/sw.cfg
# manage_index -a -f /var/opt/ignite/data/Rel_B.XX.YY/sw.cfg \
-i /var/opt/ignite/clients/<client>/CINDEX
You may instead choose to save the config file for the client in the path "/var/opt/ignite/clients/0x<LLA>/recovery/config.local".
In which case each time a new recovery archive is made, the config.local file will be automatically added to the new
CINDEX entry. (See
FAQ item 11-8.)
During a system recovery, the software bundles available in the depot will be available for selection
from the user interface.
Top
A: If you try to initiate a recovery session on a client from the Ignite-UX server GUI and you see the following warning:
Warning: untrusted X11 forwarding setup failed: xauth key data not
generatedWarning: No xauth data; using fake authentication data for
X11 forwarding.
check the setting of the "ForwardX11Trusted" variable in
/opt/ssh/etc/ssh_config on the server.
If it is "no," try setting it to "yes."
Top
