Installing Systems with Ignite-UX

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.