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