Numerous samreg errors
Installing from an image returns numerous samreg errors.
The problem is that the SAM filesets have not been configured when certain products are trying to register
themselves with SAM.
The work-around is to place the following configuration clause in /var/opt/ignite/config.local or in the configuration file that contains
the sw_source clause of the core
operating system.
sw_source "core"
{
post_load_cmd += "swconfig -xautoselect_dependencies=false
-xenforce_dependencies=false SystemAdmin.SAM -xreconfigure=true"
}
|
|
| |
|
| NOTE: Due to formatting limitations, unintended line
wraps exist in the previous example; the post_load_cmd line should not wrap in your configuration file. You verify the syntax with the instl_adm -T command. |
|
| |
|
Problem Installing Clients on Multiple Subnets
Problems occur
when installing clients on multiple subnets.
Executing a LAN boot of
clients on multiple subnets to a single, multi-homed Ignite-UX server
has the following limitations:
The instl_bootd daemon allocates IP addresses
from the instl_boottab file and matches
the IP addresses with the subnet from which the request came. If the instl_boottab file does not contain an IP address that
is valid for the client's subnet, the client will not be able
to boot from the server. Due to this lack of information, it can allocate
an IP address that is not valid for the client’s subnet, and
thus the client will not be able to boot from the server.
The workarounds for this problem are:
For every subnet from
which you may want to boot clients, you must have at least one IP
address that is valid for that subnet in /etc/opt/ignite/instl_boottab. This ensures that instl_bootd can allocate an
appropriate address.
For every possible client
that you may want to boot, assign "reserved" IP addresses in /etc/opt/ignite/instl_boottab that are tied to the client's
MAC address. This ensures that instl_bootd allocates
an appropriate address (see the comments in the instl_boottab file on how to reserve addresses).
Alternatively, you can
set up entries in /etc/bootptab for every client
that you want to boot from the Ignite-UX server.
Configure a boot helper system on each subnet that the client can
boot from before contacting your central Ignite-UX server. See “Ignite-UX bootp Boot Helper”.
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, it will not be able to
contact the server after it boots.
Workarounds
for this problem are:
Manually correct the server’s
IP address on the networking dialog box 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.
Too Much File Space Needed
Ignite-UX requests
more file system space than expected.
Ignite-UX adds the value of _hp_addnl_fs_free_pct(normally 10 percent) to the amount required by the software impact.
The configuration variable, _hp_addnl_fs_free_pct can be set in any configuration file. It
is set to a default value of 10 percent in each default release configuration
file. You can set this value using the Additional... button on the Basic tab in the Ignite-UX GUI during an interactive
installation. For more information, see “Basic Tab”.
You may have software bundles that have overlapping contents (filesets
or files or both). 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 quite a bit so when you install
all of them using Ignite-UX, it estimates too much space. To find
the space needed, add the sw_impact of all the sw_sel software you
are installing.
Debugging SD During Cold-Installation
How do I monitor Software
Distributor operations during cold-installations from the Ignite-UX
server?
Software Distributor debugging can be enabled
on a per-session basis without modifying the Ignite-UX server configuration
files. From the initial Ignite-UX menu on the client, select Advanced Options then Edit config file. This invokes vi and
you could add, for example:
env_vars += "SDU_DEBUG_RPC=1"
sd_command_line += "-x logdetail=true -x loglevel=2"
|
Additionally, these configuration statements can be added to the
Ignite-UX server configuration file /var/opt/ignite/config.local if debug output is wanted for multiple clients or for multiple installation
sessions and avoids adding them interactively each time.
Booting Errors on PA-RISC Systems
Error:IPL error: bad LIF magic
Possible problems are:
The tftp service does not have 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, correct the inetd.conf file and run inetd -c. Kill any tftpd processes that may be running. Installing Ignite-UX
should set up inetd.conf. The tftp service can also be configured using SMH or SAM.
Using a bootptab entry for the client that is referencing a nonexistent boot file
(bf).
A corrupted /opt/ignite/boot/boot_lif file.
Booting Error on Itanium-Based
Systems when using /etc/bootptab
Error:PXE-E16: Valid PXE offer not received.
Exit status code: Invalid Parameter
When using /etc/bootptab to
define Ignite-UX boot services, a number of
problems can be introduced resulting in this error. The following
checklist can be used to isolate the problem:
Check inetd:
Check /etc/inetd.conf to make certain bootps and tftp entries have been uncommented. Make certain
the tftp line contains /opt/ignite and /var/opt/ignite paths.
Signal inetd to reread the configuration files (inetd -c) after the files are edited. If the inetd process is not running, start it using:
/sbin/init.d/inetd start
Check /var/adm/syslog/syslog.log to make certain inetd was restarted and no bad
messages are found. Specifically check for messages from bootpd and tftpd.
Check for entries in /var/adm/inetd.sec that may cause inetd to deny service to certain clients.
Check bootpd:
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 ensure that bootpd is not set 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.
If packets were not received, use a tool such
as tcpdump to check for network packets. Verify
that bootp packets are being seen by the system.
If you do not have tcpdump on your system, you
can download it for either HP-UX 11i v1 or HP-UX 11i v2 from the HP
Internet Express Website at
https://h20293.www2.hp.com/portal/swdepot/try.do?productNumber=HPUXIEXP1111
or
http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXIEXP1123
Check to see if there
are other systems on the network that may also be replying to the
booting client system.
Check to see if the system
booting is on a different subnet to the bootp server
to ensure that any router between the two allows the forwarding of bootp requests. The configuration is router specific.
Check tftpd:
Check the tftp line in /etc/inetd.conf to make certain that
the /opt/ignite and /var/opt/ignite directories are listed.
Check the tftpd connection manually by using the tftp command,
for example:
$ tftp [server-name]
tftp> get /opt/ignite/boot/nbp.efi /tmp/nbp.efi
Received [n] bytes in [s] seconds
tftp> quit
Problems Pointing to Client Over Network
The control_from_server=true and run_ui=false variables are in [W|V|I]INSTALLFS, but I still get prompted for
information on the client.
Possible problems are:
If the dialog box is showing
the client name in an editable field and a Cancel button at the bottom of the dialog box, then all is well and there
should be an icon waiting for you on the Ignite-UX GUI. The text box
enables you to change the icon name or switch to a client side install.
If the dialog box is showing
two or more LAN interfaces to choose from, then there was not enough
information in the configuration files to tell
it which LAN to use. Once you select a LAN and select Install HP-UX, you should be set.
If the dialog box is prompting
you for networking information, then either DHCP did not respond or there is no entry in /etc/bootptab for the client. Enter the network information, select Install HP-UX and continue the install.
Applications Hang After Igniting
Some applications
and shells hang over NFS after igniting.
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 system. Many applications
use file locking and can hang in this situation. Most common are user
home directories that are NFS mounted, in which case sh and ksh will
attempt to lock the .sh_history file
and hang before giving you a prompt.
When a system is running and has an active NFS
mount with a server in which files have been previously locked, both
the client and server cache information about each other. Part of
the information that is cached is what RPC port number to use to contact
the rpc.lockd daemon on the server and client.
This RPC port information is cached in memory
of the running rpc.statd/rpc.lockd process on both the server and client sides. The rpc.statd process keeps a file in the directory /var/statmon/sm for each system that it knows it should contact in the event that
the system reboots (or rpc.statd/rpc.lockd restarts). During a normal reboot or crash, rpc.statd will contact all systems in /var/statmon/sm and inform them to flush their cache regarding this client.
When you reinstall a system, the /var/statmon/sm directory is wiped out. In this case, if the reinstalled system
tries to recontact 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 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, 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 that contains the server’s name. This will cause the first boot to generate a crash recovery notification message
to each server, causing it to purge the stale port information. Following
is an example post_config_cmd that
could be placed in your /var/opt/ignite/config.local file. Replace sys* with your NFS
server names.
post_config_cmd += "
mkdir -p /var/statmon/sm
for server in sys1 sys2 sys3
do
echo $server > /var/statmon/sm/$server
chmod 0200 /var/statmon/sm/$server
done
"
|
The bootsys Command Seems
to Work in Reverse
With bootsys -w client, the client does not wait for the server. With bootsys client, the client
waits for the server.
This was probably due to running through the GUI
once on the server prior to running bootsys. The
server drops the instruction for the client to start installing, and
the next time the client boots it picks that
instruction up and goes. Ignite-UX tells you that the installation
will happen the next time bootsys -w is used, but
does not say it happens automatically. Then, the next time you run bootsys, you did not use the GUI without the client being
booted from the server.
Server Not Listed
The search lan install command does not list the server.
Check these items on the Ignite-UX
server from which you are trying to boot:
Messages from instl_bootd /var/adm/syslog/syslog.log. If you need to add more IP addresses to /etc/opt/ignite/instl_boottab, you will see messages in syslog.log such as
the following:
instl_bootd: Denying boot request for host: 080009F252B3 to
avoid IP address collision. Try booting again in 214 seconds, or
add more IP addresses to /etc/opt/ignite/instl_boottab.
|
A message in syslog.log that indicates that you have no IP addresses
in /etc/opt/ignite/instl_boottab is:
instl_bootd: No available IP address found in:
/etc/opt/ignite/instl_boottab
|
If the client is an older
system that does not use the BOOTP protocol (like 720s, 710s, 735s, 750s), then also look in the log
file /var/adm/rbootd.log, and check to make sure
the rbootd daemon is running. The rbootd daemon always runs, whereas instl_bootd is started
using inetd and only runs when needed.
Also, for these
older clients, there is an intentional delay built into the rbootd process when a client wants to do an installation boot (as opposed to a diskless boot). This prevents the
server from showing up during the first search. Retrying the search
two or three times may be necessary.
The bootsys Command Fails
with Insufficient Space
The bootsys command fails
due to insufficient space in the /stand volume.
The bootsys command must copy
the two files, /opt/ignite/boot/Rel_release/[W|V|I]INSTALL and
/opt/ignite/boot/Rel_release/[W|V|I]INSTALLFS
from the server into the client’s /stand directory. This error indicates that there is not
enough space in /stand. To correct this situation,
you may need to remove any backup kernels.
Also, check for kernels in the /stand/build/ directory
(like vmunix_test).
TUI Does Not Accept User Input
The text fields
in the TUI do not accept keyboard input during client installations.
The text fields within the TUI do not recognize
keyboard input, causing dialogs to reopen or loop. This occurs when
the Insert key is active so you must ensure that
the Insert key is deactivated by pressing it to enter
data in the TUI.