Ignite-UX Administration Guide for HP-UX 11i (B3921-90080, November 2013)

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” (page 56).
• 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” (page 119).
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?
226 Troubleshooting