Frequently asked questions

To better understand BigFix Patch for Solaris, read the following questions and answers.

The Manage Download Plug-ins dashboard is not reflecting any data. What do I do?
Here are some steps you can do to troubleshoot the issue:
  • Gather the latest Patching Support site.
  • Activate the Download Plug-in Versions analysis, available from the Patching Support site.
  • Clear the BigFix console cache.
Why does a patch fail, but complete successfully?

Sometimes under specific circumstances, a patch is successfully applied but the relevance conditions indicate that it is still needed. Check to see if there are any special circumstances that are associated with the patch, or contact HCL Software Support.

If a patch fails to install, what should I do?

If a patch fails to install, check to see if you applied the patch to the correct computers, or run the patch manually by downloading it from the Oracle website.

Why is there no default action?

You must always test on a testbed before applying the Fixlet® or patch. There can also be multiple actions that are associated with the Fixlet®. Be sure to read the text in the Description tab of the Fixlet® before starting the action.

What are superseded patches?

Superseded patches are older versions of patches that no longer need to be applied.

What shell should I use?
BigFix Patch for Solaris uses Bourne shell scripts to install packages on the endpoints. Ensure that an sh-compatible shell is installed on the endpoints to successfully patch using Fixlets.
How do I handle missing patches?

BigFix provides all patches except those patches that are unbundled. Missing patches might be superseded. For recently superseded content, run the Enable Superseded Solaris Patch Evaluation task (ID #13) to allow supersedence evaluation. This task is available from the Patches for Solaris site. For information about older content, contact HCL Software Support.

I already have an Oracle support account, but the plug-in to download patches still failed. Why is that?

Your Oracle support account must have a valid support identifier to successfully download patches.

How much space do I need to download and install patches of Recommended Patch Clusters or Critical Patch Updates (CPU)?

You might need at least 12 GB of disk space for the download and installation of patches. For Recommended Patch Clusters, you can use the Solaris 10: Insufficient Disk Space - /var task (ID #3) to check whether the file system containing /var has sufficient space to extract and install patch cluster patches.

What log can I use to debug the patch cluster installation?
For Fixlets from the Patches for Solaris site
To debug the commands used to install patch cluster, check the log located in /var/opt/BESClient/__BESData/__Global/Logs/<YYMMDD>.installcluster.log. The log follows the BigFix log format, which starts with a timestamp for each run. If the Fixlet® is deployed to an endpoint multiple times on the same day, each run is appended to the log file. The log file does not get overwritten.
For Fixlets from the Patches for Solaris Live Upgrade site
To debug the commands used to install patch cluster, check the log located in /var/opt/BESClient/__BESData/__Global/LUdata/<BE_name>_cluster_install.log. If the Fixlet® is deployed to an endpoint multiple times on the same day, the log gets overwritten and will contain details about the latest deployment.
The sha1 value and the size of the Patch Cluster Fixlets are outdated. Why is that?

The sha1 value and the size of the Patch Cluster Fixlet® might be outdated due to the frequent Oracle Recommended Patch Clusters updates. Updated Fixlets are provided based on the service-level agreement with the patch vendor.

How do I verify if the download plug-in was registered correctly?

Run a Fixlet® with an action task to verify if the download plug-in is registered correctly. Verify that the patch download is successful. Otherwise, you might need to unregister the download plug-in and register it again.

How do I register a download plug-in? Do I use the register download plug-in task or the Manage Download Plug-in dashboard?
To register a download plug-in, you must use the Manage Download Plug-in dashboard in the Patching Support site. Existing register download plug-in tasks are being deprecated. To learn more about plug-in registration, see Registering the Solaris download plug-in.
Note: You must also use the Manage Download Plug-in dashboard to unregister, configure, and upgrade download plug-ins. The existing unregister and edit download plug-in tasks are being deprecated. For more information about the dashboard, see the topic on Manage Download Plug-ins dashboard in the BigFix Knowledge Center.
I was expecting the password to be obfuscated, but it is still in clear text. Why is that?

Check that your download plug-in version is earlier than 2.0. If so, you are still using an old version of the download plug-in that stores credentials in clear text. To encrypt credentials, upgrade your download plug-in to version 2.0 or later from the Manage Download plug-ins dashboard in the Patching Support site.

I'm having problems with the Solaris download plug-in. What should I do?
Locate the plugin.ini file from the C:\Program Files (x86)\BigFix Enterprise\BES Server\DownloadPlugins\SolarisProtocol directory. Check and confirm that the configurations are properly set in the plugin.ini file.
What happens when I do not select an inactive boot environment for Activation before I reboot a computer?

The computer reboots back to the current active boot environment.

I already have the client in some of the boot environments. What happens to them when I install the client from the Manage Solaris Boot Environment dashboard?

To find out what happens to those boot environments, see BigFix client installation behavior.

How do I patch boot environments with a baseline?

Use baselines to patch boot environments in the same way that you use baselines to patch computers.

Can I select multiple boot environments for Live Upgrade on a single machine?

Even if you have more than one inactive boot environment on a Solaris machine, you can select only one boot environment for Live Upgrade.

I cannot activate multiple boot environments that are on the same machine. Why is that?

Activating a boot environment makes it bootable on the next reboot of the system. Also, Solaris machines can have only one running boot environment at a time.

I selected multiple boot environments for Live Upgrade. Why are some of the boot environments excluded from the action?
The boot environments that are excluded from an action might not have passed the requirements for that action. Each action has its own set of criteria:
Selecting boot environments for Live Upgrade:
A client must be installed in the boot environment.
Only one boot environment for each computer can be selected for Live Upgrade.
Activating boot environments:
A client must be installed in the boot environment.
The boot environment must first be selected for Live Upgrade before activation.
Only one boot environment for each computer can be activated.
What can I do if an inactive boot environment is selected for Live Upgrade even if it does not have a client installed? Is this scenario even possible?

Yes, this scenario might occur when the Enable Solaris Live Upgrade task is deployed on a system with only one inactive boot environment. The task, by default, selects the inactive boot environment for Live Upgrade without checking the existence of a client. If you encounter this scenario, you must install the client from the Manage Solaris Boot Environment dashboard.

Why do I see duplicate computers in the Manage Solaris Boot Environment dashboard?
Computers have different client IDs. When a computer abruptly goes offline and comes back on, a new client ID is assigned to the computer. The console does not recognize the old computer because of its new client ID. It is suggested that you delete the computer with the oldest report time. Complete the following steps:
  1. Click All Content > Computers.
  2. Right-click the computer that you want to delete.
  3. Click Remove from Database.
What does the Enable Solaris Live Upgrade task do?

When Live Upgrade is enabled, a back-end utility script fetches information from all the boot environments. The information is saved in a plain text format, which can be found in /var/opt/BESClient/__BESData/__Global/LUdata.

Where can I find the log files for Live upgrade?
The Live Upgrade log files are in /var/opt/BESClient/__BESData/__Global/LUdata. The following log files can be used for troubleshooting:
SLU.log
To verify that the boot environment was successfully enabled for Live Upgrade.
restart.log
To verify that the boot environment was successfully activated.
<BE_name>_package.txt
To verify that the client is already installed in a boot environment. This text file contains the package and version list of the particular boot environment. If the client version is not listed in the file, the client is not installed.
<BE_name>_patch.txt
To verify the list of installed patches.
<BE_name>_cluster_pre_install.log
To verify whether prerequisite patches for a Recommended Patch Cluster are applied.
<BE_name>_cluster_install.log
To verify whether a Recommended Patch Cluster installation is successful.
<BE_name>_CPU_Pre_install.log
To verify whether prerequisite patches for a CPU are applied.
<BE_name>_CPU_install.log
To verify whether a CPU installation is successful.
What do I do if the active boot environment displays a Null value in the dashboard?

Run the Enable Solaris Live Upgrade task or Update Boot Environment Information task, whichever is relevant.

I just switched boot environments, however the new running boot environment is not reporting to the server. What do I do?
  1. Check that the client is installed. Run pkginfo |grep BES from the command-line interface to check whether the client exists in the boot environment.
  2. Check that the client is running. Run ps -ef | grep -i bes from the command-line interface to check whether the client is currently running.
  3. Check that the actionsite.afxm file is in /etc/opt/BESClient/.
  4. Check that you can ping the server host name. If you cannot ping the server host name, edit /etc/hosts and add the IP address and host name in the file.
Why is it taking so long for the Manage Solaris Boot Environment dashboard to refresh after an action was taken?
The time delay might be caused by the multiple processes that are running at the back end. When an action is taken, the utility script gets the changes from the boot environments and stores the information in a text format. The client then sends the data to the server. The server gathers the data by using the analysis, which is read by the dashboard. It usually takes a few minutes for the targeted computers to report back their Action status to the dashboard.
How do I create a local Image Packaging System (IPS) package repository?
For information about how to create an Image Packaging System (IPS) package repository, see the Oracle documentation website at http://docs.oracle.com.
Where can I get the key and certificate files?
You can obtain both files from the My Oracle Support site. For more information, see http://pkg-register.oracle.com.
Are the key and certificate files always in .pem format?
Yes, both files are in .pem format when you download them from the Oracle Support site. Note: The Solaris Image Packaging System Repository Management dashboard accepts key and certificate files in .pem format only.
Should patching Solaris 11 endpoints be done in single-user mode?
Since Live Upgrade is handled by Image Packaging System (IPS), it is not necessary to go to single-user mode. For more information, see http://www.oracle.com/technetwork/server-storage/solaris11/overview/solaris-matrix-1549264.html.
How much space do I need to download and install patches of SRUs?
The space that is needed depends on exactly what is installed on the system. With the SRU patching, the system finds out the missing packages on the system and downloads only the relevant files. Important: Expand the overall cache size for server and relays to downloaded large SRUs to avoid the Disk Limited error. SRUs can be huge, about 2.7 GB per image file. If you do not expand the cache, the gigantic download might flush out the existing files in the cache.
Does the existing Live Upgrade offer also work for Solaris 11?
No, unfortunately not. The existing Live Upgrade solution works only for Solaris 10.
I am trying to patch my machine, but I have very limited temp space, should I be concerned?
With Image Packaging System (IPS) in Solaris 11, SRUs are not downloaded entirely. The system finds out the missing packages on the system and downloads only the relevant files.
I have a local repository, how do I set it to be used for patching Solaris 11 endpoints?
Use the Solaris Image Packaging System Repository Management dashboard to set a local repository to be used for patching.
I want to patch a Solaris 11 system with the latest SRU, however, I do not have any internet connection. What do I do?
You need to have a local repository where you can bring in the latest SRU image. The endpoint can use that repository instead of connecting internet.
Do I need to run all the tasks to ensure that my local repo is up to date? Or can I run the task with the latest Support Repository Update (SRU)?
You do not need to install all the SRUs. If you want to keep the endpoints up-to-date, install the latest SRU. But if a specific SRU is required on an endpoint, then the repository must host the base repository content and the SRU that you want the endpoint to upgrade to. For example, if you have both Solaris 11/11 and 11.1 endpoints, and you want to keep them up-to-date, then your repository must host the following content:
  • Solaris 11 11/11 repo base image + SRU 13.4 (latest SRU)
  • Solaris 11 11.1 repo base image + SRU 21.4.1 (latest SRU)
What is the suggested method to patch SRUs? Is it through a local repo or through the support site?
Having a local repository helps with the download speed and network load.
Where can I find the logs for Solaris 11?
The Solaris 11 logs are in /var/opt/BESClient/IPSData/. You can use the following log files for troubleshooting patches in Solaris 11.
Note: The logs show the latest result of an action from a Fixlet® or task.
pkg_set_publisher.log
To verify that the new repository was assigned to an endpoint in the Solaris Image Packaging System Repository Management dashboard.
This log file contains the output from the following command:
pkg set-publisher -G '*' -M '*' -g 'THE_NEW_REPOSITORY_URI' solaris
Example of a successful message in the pkg_set_publisher.log file:
Startup: Refreshing catalog 'solaris' ... Done
Startup: Caching catalogs ... Done
Example of a failed message in the pkg_set_publisher.log file due to invalid repo URI:
pkg set-publisher: The origin URIs for 'solaris' do not appear 
to point to a valid pkg repository.
Please verify the repository's location and the 
client's network configuration.
Additional details:
 
Unable to contact valid package repository
Encountered the following error(s):
Unable to contact any configured publishers.
This is likely a network configuration problem.
Framework error: code: 6 reason: Couldn't resolve host
'10.1.240.299'
URL: 'http://10.1.240.299' (happened 4 times)
update_repo_sru.log
To verify that the repository update task was successful. The log file contains information about the various actions: extracting compressed files, mounting images, copying content to the repository, and rebuilding repository indexes.
Note: The log does not contain any information if the repository verification fails. The error displays only in the console. You can check Show action information... on the failed computer.
Example of a successful message in the update_repo_sru.log file:
Archive:  __Download/p17865983_1100_Solaris86-64.zip
 inflating: /var/p17865983_1100_Solaris86-64/
   readme_11_1_14_5_0.html  
 inflating: /var/p17865983_1100_Solaris86-64/
   readme_11_1_14_5_0.txt 
 inflating: /var/p17865983_1100_Solaris86-64/
   sol-11_1_14_5_0-incr-repo.iso  
sending incremental file list

<STATUS DURING COPYING REPOSITORY CONTENT>

sent 3004537729 bytes  received 1989315 bytes  3418450.31 bytes/sec
total size is 2994859457  speedup is 1.00
Initiating repository rebuild.
pkg_update_entire.log
To verify that the endpoint was updated with the specified SRU. This log file contains the output from the following command:
pkg update entire@PACKAGE_VERSION_FOR_THAT_SRU
Example of a successful message in the pkg_update_entire.log file:
 Startup: Refreshing catalog 'solaris' ... Done
 Startup: Caching catalogs ... Done
Planning: Solver setup ... Done
Planning: Running solver ... Done
Planning: Finding local manifests ... Done
Planning: Fetching manifests:   0/178  0% complete
Planning: Fetching manifests: 100/178  56% complete
Planning: Fetching manifests: 178/178  100% complete
Planning: Package planning ... Done
Planning: Merging actions ... Done
Planning: Checking for conflicting actions ... Done
Planning: Consolidating action changes ... Done
Planning: Evaluating mediators ... Done
Planning: Planning completed in 41.85 seconds
            Packages to remove:   1
           Packages to install:   3
            Packages to update: 175
           Mediators to change:   1
       Create boot environment: Yes
Create backup boot environment:  No
 
Download:     0/10018 items    0.0/328.8MB  0% complete 
Download:   253/10018 items   15.3/328.8MB  4% complete (3.4M/s)
Download:   650/10018 items   31.4/328.8MB  9% complete (3.2M/s)
Download:  1302/10018 items   48.3/328.8MB  14% complete (3.2M/s)
Download:  1661/10018 items  117.2/328.8MB  35% complete (8.6M/s)
Download:  2426/10018 items  162.2/328.8MB  49% complete (11.4M/s)
Download:  3796/10018 items  178.1/328.8MB  54% complete (6.1M/s)
Download:  4630/10018 items  216.7/328.8MB  65% complete (5.4M/s)
Download:  6154/10018 items  243.6/328.8MB  74% complete (6.5M/s)
Download:  7938/10018 items  257.2/328.8MB  78% complete (4.1M/s)
Download:  9311/10018 items  310.0/328.8MB  94% complete (6.6M/s)
Download: Completed 328.80 MB in 54.30 seconds (6.0M/s)
Example of a failed message in the pkg_update_entire.log file that is due to unavailable SRU content in the repository:
Startup: Refreshing catalog 'solaris' ... Done
pkg update: 'entire@0.5.11-0.175.1.1.0.4.0' matches 
  no installed packages
pkg_deployment_results.log
To verify that a package was installed successfully by using the Install packages by using pkg task. This log file contains the output from either of the following commands:
pkg install <package_name1> <package_name2>

pkg update
Example of a successful message in the pkg_deployment_results.log file:
oot@solaris11-1-ips-repo:/var/opt/BESClient/IPSData# 
     cat pkg_deployment_results.log
2 Test Install Success: pkg install -n
2 ____ php-52
2 Test Install Success: pkg install -n -q --no-refresh
2 ____ php-52
2 Install Success: pkg install
2 ____ php-52
2 Install Success: pkg install -q --no-refresh
2 ____ ipython-26
Example of a failed message in the pkg_deployment_results.log file:
2 Test Install Failure: pkg install -n - Error:
2 ____ pkg install: Illegal FMRI 'fmri://web/curl': 
     Invalid Package Name: fmri://web/curl
2 ____ Failed to install the following packages:
2 ____ fmri://web/curl
What is the difference between the Fixlet® content found on the Patches for Solaris and Patches for Solaris Live Upgrade sites?
The Patches for Solaris site includes legacy Solaris 10 and earlier core OS patch content. It uses the older traditional single-user mode for applying patches for CPU and Recommended Patch Clusters. The Patches for Solaris Live Upgrade site includes patch content that uses the Solaris Live Upgrade utility to install patches to an inactive boot environment rather than the currently running OS. The content of the site includes Security Patches, Recommended Patches, Recommended Patch Clusters, and Critical Patch Updates.
I have deployed a CPU patch to an inactive BE using the Fixlet® in the Patches for Solaris Live Upgrade site. Without rebooting, it looks like that the same CPU patch found in the Patches for Solaris site still displays as relevant. Why is that?
The relevance for a particular patch in those two sites are different. The Fixlets in the Patches for Solaris Live Upgrade site patch the inactive boot environment, while the Fixlets in the Patches for Solaris site patch the running boot environment. Without rebooting the inactive boot environment, the current status of the active boot environment remains. One possible reason why the patch still shows as relevant is because the active boot environment might have not been patched with the same CPU.
How do I configure zones?
For information about configuring a non-global zone, see the Oracle System Administration Guide at http://docs.oracle.com/cd/E19044-01/sol.containers/817-1592/z.conf.start-29/index.html.
What makes it possible for a Fixlet® to be patched on a specified zone?
The Fixlet® uses the patchadd -G option to apply the patch to the current zone. For more information about the patchadd option, see http://docs.oracle.com/cd/E19253-01/816-5166/patchadd-1m/index.html
What do I need to do before removing a patch from a zone?
Ensure that the patch is not required by other installed patches and that a backup of the original patch files exist. Failure to do so might cause the rollback action to fail and consequently the patch remains installed in the zone.
Where is the rollback log located?

Use the rollback.log file found in /var/opt/BESClient/__BESData/Patches for Solaris/__PatchRollback/.

How can I tell if a Solaris patch or Fixlet® content supports zone patching?
Check the information file of the Solaris patch to see what the SUNW_PKG_ALLZONES variable is. If the patch package is set to true, this means that Oracle forces the installation to all zones (global and non-global zones). The Fixlet® content for such a patch has only one installation action. If the patch package is set to false, the installation can occur in either the global or non-global zone. The Fixlet® for such a patch contains two installation actions.
How can I install custom packages that are on the local repository?
You can use the Install packages by using pkg task from the Patches for Solaris 11 site:
For more information, see Deploying Solaris packages.
Can I install several custom packages by using the installation tasks?
Yes, you can install several custom packages with the available tasks. Use a space to separate the package names.
Can use the Install packages by using pkg task to install a package from a single file?
Single files are installed by using the pkgadd command. The Install packages by using pkg task supports the pkg command only.
What are the possible causes for the Install packages by using pkg task to fail?
The possible causes of failure are:
  • No repository was configured.
  • No repository was registered to the endpoints
  • No internet connection is available on the endpoints.
I used the Install packages by using pkg to install packages. How do I verify if they were installed successfully?
You can use the Image Packaging System Results analysis to verify whether the packages that were installed by using the Install packages by using pkg task were successfully installed on endpoints.
The Image Packaging System Results analysis did not return anything. Why is that?
You must deploy the Install packages by using pkg task at least once to create the pkg_list.log file on the endpoint. This file stores all the installed packages on the endpoint and is used by the Image Packaging System Results analysis.
Where can I find the log files for breaking and re-mirroring disk mirrors?
Both the break_mirrors.log and re_mirrors.log files are located in the folder /var/opt/BESClient/EDRDeployData.
After splitting the root disk mirrors, how can I re-mirror them?
You can use the Re-mirror Solaris disks task from the Patches for Solaris site to put the submirrors or disks back online. For more information about the commands used in the task, see http://docs.oracle.com/cd/E23824_01/html/821-1462/metattach-1m.html.
What types of mirror are supported in the Break Solaris mirrors task?
The Break Solaris mirrors task can break the following UFS mirrors: root (/), /var, /opt and /usr. ZFS file system or VxVM based mirrors are not supported.
How many submirrors can a mirror contain?
You can create a mirror of up to three submirrors or disks. For more information, see the Solaris Volume Manager Administration Guide at http://docs.oracle.com/cd/E19253-01/816-4520/.
I tried to patch my inactive ZFS boot environments, but none of the Fixlets in the Patches for Solaris Live Upgrade are relevant. What do I do?
When using Solaris Live Upgrade, you can mount a maximum of two ZFS boot environments at the same time. If more than two ZFS boot environments are mounted, the Fixlet® relevance evaluation fails. If you encounter this issue, complete the following steps:
  1. Check if the Enable Solaris Live Upgrade task (ID #2) is relevant to the endpoint.
  2. Check and delete the /.alt.<BE_Name> folder on the endpoint.
  3. Check the mount and zfs list result, and restart the computer to reset the mount points for the zone file system.
  4. Run the Enable Solaris Live Upgrade task (ID #2) on the endpoint.
Why do I need to run the Check Available Package Updates - Solaris 11 task before activating the Endpoint Upgrade List - Solaris 11 analysis?
The task generates an output file named pkg_upgrade_output.txt that is stored in the folder /var/opt/BESClient/IPSData/, which is used by the analysis to display the list of endpoints that need to be upgraded. If you do not run the task at least once, the analysis will indicate that the file does not exist. To ensure that the analysis is displaying the latest content, run the task.
Do I need to run the Check Available Package Updates - Solaris 11 task before viewing the Endpoint Upgrade List - Solaris 11 analysis?
Yes, run the task before viewing the results from the analysis. Running the task periodically ensures that you gather the latest content.
The Endpoint Upgrade List - Solaris 11 analysis displays that one of the endpoint's Output Files cannot be parsed. What happened?
The pkg_upgrade_output.txt file that is stored in the folder /var/opt/BESClient/IPSData/ might be corrupted. Complete the following steps:
  1. Check and follow the instructions in the pkg_upgrade_output.txt file.
  2. Run the Check Available Package Updates - Solaris 11 task again to execute the pkg update -n command and overwrite the existing pkg_upgrade_output.txt file.
  3. Check the analysis again.