Ignite-UX Frequently Asked Questions

===============================================================================
1.2
Q: Can the Ignite-UX GUI for make_tape_recovery span multiple tapes?
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 interactively client to be able to span
multiple tapes.
===============================================================================
1.3
Q: Why do I get Warnings from pax concerning files that are not on the
client when I run either make_tape_recovery or make_net_recovery?
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).
===============================================================================
1.4
Q: When igniting from an archive, why do I get numerous samreg errors?
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 "
}
===============================================================================
1.5
Q: Can an Ignite-UX server install clients on multiple subnets?
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," particularly the section on complex network
solutions.
===============================================================================
1.6
Q: Why do some applications and shells hang over NFS after igniting?
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