Ignite-UX Frequently Asked Questions

10.1
Q: How do I prevent backup copies of patched files from being saved?
A: When installing HP-UX patches from SD depots, the normal behavior is
that the patched files are saved in case you want to remove the patch
at a later date. However, this takes up additional space in the /var
directory so you may want to turn that feature off.
This feature is controlled by an option to the swinstall command as
follows:
-x patch_save_files=false|true
You can use the "sd_command_line" keyword either at the global level,
or within individual sw_source clauses depending on whether you want
it to be specified for all installations or just certain ones.
Be aware that for patches in the core depot, this option is specified
by the /opt/ignite/date/Rel.B.11.**/hw_patches_cfg file. It is
controlled by the configuration file variable, _hp_patch_save_files,
and made visible to the user in the "Additional" tab of the Ignite-UX
GUI.
To specify this option at the global level (for example in the
/var/opt/ignite/config.local file), you can add the following line:
sd_command_line += "-xpatch_save_files=false"
To set the default variable that controls the core patches to "NO",
add the following line to config.local (which must be listed after
hw_patches_cfg in the INDEX file):
init _hp_patch_save_files = "NO"
===============================================================================
10.2
Q: Why are patches left in an installed state when I install the Support Plus
patch bundle along with HP-UX 11.x from CD?
A: When Ignite-UX installs the core operating system and patch bundle
from the Installation CD, it installs the software with the SD-UX
option "defer_configure" set to true, and then the Support Plus patch
bundle is installed. Ignite-UX can install patches that supersede
patches installed as part of the core operating system patch bundle.
Superseded patches cannot be moved into a configured state by
swconfig when it is eventually performed. This is because the
superseded patches now on the client are no longer applicable to that
patch, it is only applicable to the patch that superseded it. To
correctly determine if a patch is really in an installed state you
should look at the setting of both "patch_state" and state in the
swlist output.
For example:
# swlist -l patch -a state -a patch_state | grep PH
If the "patch_state" is applied (the patch has not been superseded)
and the state is installed, this may indicate an issue and you should
configure the patch with the swconfig command. If the "patch_state"
is superseded or committed, you do not have to worry about the state.
However, if you remove any patches and a previously superseded patch
changes to have a "patch_state" of applied, you must run swconfig
manually to configure the patch if its state attribute is installed.
Note: Do "NOT" manually modify the state attribute of an installed or
committed patch to be configured with the swmodify command.
===============================================================================
----------------------------------------
11. Network Recovery
----------------------------------------
11.1
Q: How can I learn more about network recovery?
A: In addition to the information in this FAQ, there are several other
sources of information on network recovery:
- The "System Recovery" chapter in the "Ignite-UX Administration