Q: – When igniting from an archive, why do I get 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 workaround is as follows:
Place this configuration stanza in "/var/opt/ignite/config.local" or directly in the configuration file with the core
post_load_cmd += "
swconfig -xautoselect_dependencies=false /
-xenforce_dependencies=false SystemAdmin.SAM "
Q: – Can an Ignite-UX server install clients on multiple subnets ?
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.
Q: – Can I run make_net_recovery from a PA-RISC server to create an archive for an Itanium-based client or vice versa ?
Q: – Why do the iux_postconfig scripts associated with EMS KRM sometimes fail?
On some HP-UX 11.x clients you might see the following errors when recovering a client from a make_net_recovery or make_tape_recoverytape, or a make_net_recovery image:
ERROR: Cannot install a dlkm driver.
ERROR: Cannot configure a dlkm driver.
ERROR: The script:
"/var/adm/sw/products/EMS-KRMonitor/KRMON-RUN/iux_postconfig" failed, exit code was 1.
The reason for this is when the recovery archive was created, the kernel the client was running was not created correctly (the DLKM information was out of sync). You should always use kmupdate to move a new kernel into place after creating it with mk_kernel, this will move the DLKM information into place when the new vmunix is moved into place at the next shutdown.
To solve this problem, create a kernel in the way described above then recreate the recovery tape or network recovery archive. You should not see this message the next time you use the new tape or network recovery archive (the old tape or network recovery archive will always show this problem).
Submitted By:-Jack Email-ID: – firstname.lastname@example.org