User's Guide

Ther
e are four solutions to this problem:
 Edit the apps_1203_cfg file and change the name of the sw_sel clauses so that they are
unique and descriptive of the clause's content. This allows you to address the two software
selection clauses uniquely. It also ensures that the intended software is selected from the core
operating system (OE) depot, and that software from the applications media is not selected
inadvertently. This is time consuming and if you want to update the configuration file using
make_config you must reapply the changes.
 Remove all of the software bundles that exist in the core operating system (OE) depot and the
applications depot. You would run make_depots on the applications DVD then use swremove
on the applications depot. HP does not recommend this solution.
 Place the application media into the core operating system (OE) depot rather than putting it into
a separate depot. This means that you must manage the depots as one. Note that you cannot
update an OE in a depot. If you wish to use a new OE in an existing depot, you must remove the
entire contents of the depot before using make_depots to copy in new software from OE and
applications media. This also assumes that a different version of VxVM/VxFS is not available on
the application media - you can’t cold install a different version of VxVM/VxFS to the version
available from the core OE media.
 Ensure that the Core OS (OE) media and applications media are always synchronized.
Follow on consequences
This can also lead to more serious problems when you have an application that depends on
something that would normally be installed from the core OE depot, but because of the issues
described above in “An example problem” it may be installed from somewhere else (the
applic
ations depot).
We will use the following cfg clause as the basis for our example:
cfg "HP-UX B.11.11" {
description "HP-UX 11.11 MCOE with vPars"
"/opt/ignite/data/Rel_B.11.11/config"
"/opt/ignite/data/Rel_B.11.11/hw_patches_cfg"
"/var/opt/ignite/data/Rel_B.11.11/core_OE.cfg"
"/var/opt/ignite/data/Rel_B.11.11/vPars_cfg"
"/var/opt/ignite/data/Rel_B.11.11/apps.cfg"
"/var/opt/ignite/config.local"
}
Some vPars filesets in version A.03.03.06 have an SD dependency on the fileset
PartitionManager.PARMGR,r>=B.11.11.01.05. That means that the fileset
PartitionManager.PARMGR of that revision or higher must be installed on the system otherwise
parts of the vPars software won’t install
83
.
If the bundle that defines the Partition Manager commands is present in the core OE and the
applications depot, it will be installed from the applications depot not from the OE depot. That
means if the vPars software is installed after the OE depot but before the applications depot, the
vPars software will only partially install because some dependencies cannot be met.
83
If available from the same depot as the vPars software, it would be automatically selected but may only end up partially installed (since only
the dependencies would be selected). If you didn’t keep the Partition Manager commands in sync with the application and core OE depots,
you might end up with mixed revision filesets in the Partition Manager commands bundle.
178