Ignite-UX (IUX) Document for Frequently Asked Questions (FAQ) (762793-001, March 2014) (Edition: 3)

11 Loading patches
Frequently asked questions
Following are the frequently asked questions in loading patches, which is a compilation of all the
available feedback from the users.
How do I prevent backup copies of patched files from being saved?
When installing HP-UX patches from SD depots, the normal process 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 might 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"
Why are patches left in an installed state when I install the Support Plus patch bundle
along with HP-UX 11.x from CD?
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 must 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 indicates an issue and you must configure the patch with the swconfig command. If the
patch_state is superseded or committed, then ignore the status. However, if you delete any
patches and a previously superseded patch changes to have a patch_state as applied, you
must run swconfig manually to configure the patch if the state attribute is installed.
NOTE: Do not manually modify the state attribute of an installed or committed patch, it must
be configured with the swmodify command.
Frequently asked questions 41