Problems occur when installing clients on multiple subnets.
Executing a LAN boot of clients on multiple subnets to a single,
•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
◦Configure a boot helper system on each subnet that the client can boot from before contacting your central
•The server keyword that specifies the IP address for your
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.
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
How do I monitor Software Distributor operations during
Installing systems with