Skip to Main Content

Infrastructure Software


For appeals, questions and feedback, please email

Overview of Image Packaging System in Oracle Solaris

Joost PronkvH-OracleApr 11 2016 — edited Jul 25 2018

by Gerry Haskins

This article describes the Oracle Solaris Image Packaging System (IPS)—a modern, open, repository-based packaging system—and how to use it to apply support repository updates (SRUs) and Interim Diagnostics or Relief  (IDR) updates. It also discusses troubleshooting and querying metadata.

Note: For more information on SRUs and IDRs, see "Overview of Oracle Solaris Release Cadence."

IPS is used in products such as Oracle Solaris 11 and Oracle Solaris Cluster 4.

IPS is a single-tier packaging system, where the same commands are used for both installation and applying maintenance updates. For more information, see man pkg on an Oracle Solaris 11 system.

In IPS, software can be organized into installation groups for different use cases, for example, a desktop deployment or a server deployment.  The installation group defines the packages that get installed on the target system.  The following example shows an Oracle Solaris 11 desktop installation (denoted by i):

user@system:/usr/bin$ pkg list solaris-desktopgroup/system/solaris-desktop                        0.5.11-      i--

In IPS, software versions can be organized into incorporations, which define a set of software versions (a "surface") that are designed to work together.  Incorporations can include other incorporations.  The incorporations define the versions of packages that get installed on the target system.  For example, the Oracle Solaris entire incorporation defines the Oracle Solaris version:

user@system:~$ pkg list entireNAME (PUBLISHER)                      VERSION                  IFOentire                                0.5.11-   i--

The Fault Management Resource Identifier (FMRI) version string above shows this system has Oracle Solaris 11.3 SRU1.5 installed.

Note that with the introduction of Oracle Solaris 11.4 the output has been updated to make it simpler to deduce the version:

user@system:~$ pkg list entireNAME (PUBLISHER)                      VERSION                  IFOentire                                11.4-      i--

The FMRI version string above shows the system has Oracle Solaris 11.4 SRU2.5 installed.

For more information see "IPS Design Goals, Concepts and Terminology."

For Oracle Solaris IPS specifics, see:

How Does IPS Differ from Sun's SVR4-Based Packaging System?

IPS replaces Sun's System V Release 4 (SVR4) packaging system used in products such as Oracle Solaris 10 and earlier releases and in Oracle Solaris Cluster 3.2 and earlier releases.

IPS is designed to be much simpler and much more powerful than the two-tier SVR4-based packaging system, which had separate but related commands for installation and patching such as pkgadd and patchadd, the latter calling the former under the hood.

IPS is designed for simplicity, with repository-based updates eliminating the need to download myriad separate patches or patch sets. This eliminates a lot of the maintenance work customers needed to perform for Oracle Solaris 10 and earlier releases to determine which patches need to be installed.

Instead, in IPS, software is updated as a unit. A system will typically be updated to a later SRU.

Oracle Solaris 11 Installation Groups

The use case for the target system determines which installation group is appropriate.

Installation groups include the following:

user@system:~$ pkg list -n 'group*'NAME (PUBLISHER)                                              VERSION                   IFO group/feature/amp                                             0.5.11-   --- group/feature/developer-gnu                                   0.5.11-   --- group/feature/developer-studio-utilities                      0.5.11-    --- group/feature/multi-user-desktop                              0.5.11-   --- group/feature/storage-avs                                     0.5.11-   --- group/feature/storage-nas                                     0.5.11-   --- group/feature/storage-server                                  0.5.11-   --- group/feature/trusted-desktop                                 0.5.11-   --- group/prerequisite/oracle/oracle-ebs-server-R12-preinstall    0.5.11-    --- group/prerequisite/oracle/oracle-rdbms-server-12-1-preinstall 0.5.11-    --- group/system/management/rad/rad-client-interfaces             0.5.11-   --- group/system/management/rad/rad-server-interfaces             0.5.11-   i-- group/system/solaris-auto-install                             0.5.11-    --- group/system/solaris-core-platform                            0.5.11-   i-- group/system/solaris-desktop                                  0.5.11-    i-- group/system/solaris-large-server                             0.5.11-    --- group/system/solaris-minimal-server                           0.5.11-    --- group/system/solaris-small-server                             0.5.11-    ---

The common installation groups highlighted above are described in the following four sections.


solaris-minimal-server is designed to be used as the basis for a secure install.  This installation group installs the bare-minimum packages required to have a functioning system that is capable of administrator login and zone creation, and provides a basic editor for editing configuration files.

The idea is that you then install only the additional packages required for the applications you wish to install in this environment.  Consider the packages required for the entire lifecycle of the environment, including monitoring, updating, backups, debugging, and so on.

For example, if the applications to be installed in the environment need the gunzip utility, the corresponding package that needs to be installed on top of solaris-minimal-server can be found as follows:

user@system:~$ pkg search -p gunzipPACKAGE                                   PUBLISHER pkg:/compress/gzip@1.5-   solaris

To install the package, run the following command as a privileged user:

root@system:~$ pkg install gzip

The advantage of this approach is that it minimizes the attack surface of the installed environment.  This reduces the need to patch the environment because if the vulnerable software isn't installed, it doesn't need to be patched.

FOSS software—such as OpenSSL, BIND, NTP, and so on—is particularly prone to security vulnerabilities.  If these packages are not needed, then not installing them avoids the need to patch them, for example, to address zero-day vulnerabilities.  This increases security compliance and reduces total cost of ownership (TCO) because it reduces the maintenance burden.

solaris-small-server and solaris-large-server

The difference between the solaris-small-server and solaris-large-server installation groups has nothing to do with the size of the server being installed.  Rather it refers to the number of packages that will be installed on the target system.  solaris-large-server provides a number of additional utilities that system administrators might find useful.  solaris-small-server provides a slightly smaller attack surface, but nowhere near as minimized as solaris-minimal-server.


Use the solaris-desktop installation group for desktop/workstation installations where the user needs the full palette of desktop utilities. solaris-desktop is not appropriate for most server installations because the additional desktop packages are unlikely to be needed and increase the attack surface for hackers and malware.

oracle-rdbms-server-12-1-preinstall and oracle-ebs-server-R12-preinstall

Other installation groups include groups designed to simplify the installation of common applications such as an Oracle Database 12_c_ single-instance database or Oracle E-Business Suite 12.

These install groups install the prerequisite packages required by these applications.

Oracle Solaris 11 Incorporations

Incorporations define a "surface," that is, the versions of packages that can be installed and have been tested to work together.

The entire incorporation defines the Oracle Solaris 11 version.  It defines which versions of individual packages comprise an Oracle Solaris release.

Removing the entire incorporation package from an installed system is unsupported, because it would leave the system vulnerable to updates of inconsistent and untested package combinations.

IPS and Applying SRUs

SRUs provide package deltas based on the preceding update release, so the update release itself must also be added to your repository, if the system doesn't already have that update release, in order to apply subsequent SRUs.

IPS dynamically resolves dependencies, for example, when executing a pkg update command.  To avoid IPS dependency resolution issues, it is recommended that if you set up a local package repository, it includes all update releases and SRUs from the oldest version installed on any system in your environment through to the latest SRU.

See "How to Update Oracle Solaris 11 Systems From Oracle Support Repositories. "

If the default internet-facing support repository has been configured, it will be shown as follows:

user@system:~# pkg publisherPUBLISHER    TYPE    STATUS  P   LOCATION solaris      origin  online  F

Many customers will wish to set up a local repository behind their firewall to mirror the support repository content; see the relevant "how to" document referenced above and also see Creating Package Repositories in Oracle Solaris 11.4 and "Best Practices for Creating and Using Local IPS Package Repositories." As noted earlier, the Oracle Solaris entire incorporation currently installed on the system is Oracle Solaris 11.3 SRU1.5:

user@system:~$ pkg list entireNAME (PUBLISHER)           VERSION                       IFOentire                     0.5.11-        i--

To get more verbose information, type the following:

user@system:~$ pkg info entire          Name:    entire        Summary:    Incorporation to lock all system packages to the same build    Description:    This package constrains system package versions to the same                    build.  WARNING: Proper system update and correct package                    selection depend on the presence of this incorporation.                    Removing this package will result in an unsupported system.       Category:    Meta Packages/Incorporations          State:    Installed      Publisher:    solaris        Version:    0.5.11 (Oracle Solaris  Build Release:    5.11        Branch: Packaging Date:    October  6, 2015 02:00:51 PM            Size:    5.46 kB           FMRI:    pkg://solaris/entire@0.5.11,5.11-

To check whether a later version is available from the repository, which was set up as a publisher, type the following:

user@system:~$ pkg search solaris/entireINDEX          ACTION   VALUE            PACKAGE pkg.fmri       set      solaris/entire   pkg:/entire@0.5.11- pkg.fmri       set      solaris/entire   pkg:/entire@0.5.11- pkg.fmri       set      solaris/entire   pkg:/entire@0.5.11- pkg.fmri       set      solaris/entire   pkg:/entire@0.5.11-

From the above, you can see that the latest available SRU in the repository is Oracle Solaris 11.3 SRU4.5.  Only the SRUs from the version installed on the system from which you run the command are returned:  currently, Oracle Solaris 11.3 SRU1.5.

If we run an unconstrained pkg update command as a privileged user, IPS will update the system to the latest software version contained in the repository for which dependencies can be resolved.  This might or might not be the latest available version.

Always check that pkg update has updated to the version expected, because if there is a constraint that prevents updating to the latest version, it might update to an intermediate version.

You can explicitly specify the version to update to in order to avoid IPS updating past the intended version if a later version is available in the repository.

Let's do a dry run first using the pkg command with the -nv option to see what will be updated:

root@system:~# pkg update -nv entire@0.5.11-             Packages to update:                 140      Estimated space available:           889.16 GB  Estimated space to be consumed:             1.61 GB         Create boot environment:                 Yes      Activate boot environment:                 Yes Create backup boot environment:                  No            Rebuild boot archive:                 Yes  Changed packages: solaris   consolidation/SunVTS/SunVTS-incorporation     7.19.2,5.11- -> 8.0.0,5.11-   consolidation/X/X-incorporation     0.5.11,5.11- -> 0.5.11,5.11-   consolidation/desktop/desktop-incorporation     0.5.11,5.11- -> 0.5.11,5.11-   :   x11/session/sessreg     1.0.8,5.11- -> 1.1.0,5.11-  Editable files to change: Install:     etc/ssm/hmp/host_profile.xml Update:     etc/motd     var/log/ssm/fwupdate.log     var/log/ssm/raidconfig.log

The above command specifies a dry run of  updating the entire Oracle Solaris incorporation to the latest released build of Oracle Solaris 11.3 SRU4.  We can see 140 packages will be updated between Oracle Solaris 11.3 SRU1 and Oracle Solaris 11.3 SRU4, and that a new boot environment (BE) will be created and activated so it will become active upon the next reboot.  Until the next reboot, the system will continue to run the existing version, Oracle Solaris 11.3 SRU1, because we're updating an alternate boot environment rather than the live BE.

We simply specified updating to entire@0.5.11-  By including the remainder of the FMRI string, we could further restrict the update to a unique build, but typically we want the latest build for a particular SRU, because more than one build will typically be released only if a critical issue is addressed in the later build, such as a build to fix a late-breaking FOSS security vulnerability.

Let's do the actual update now, specifying the name 11.3.4 for the new BE:

root@system:~# pkg update --be-name 11.3.4 entire@0.5.11-              Packages to update:      140        Create boot environment:      Yes Create backup boot environment:       No  DOWNLOAD                          PKGS        FILES     XFER (MB)    SPEED Completed                      140/140    5150/5150   289.3/289.3   574k/s  PHASE                                ITEMS Removing old actions                 841/841 Installing new actions               1017/1017 Updating modified actions            5591/5591 Updating package state database      Done  Updating package cache               140/140  Updating image state                 Done  Creating fast lookup database        Done  Reading search index                 Done  Building new search index            948/948  Updating package cache               1/1   A clone of solaris exists and has been updated and activated. On the next boot the Boot Environment 11.3.4 will be mounted on '/'.  Reboot when ready to switch to this updated BE.  Updating package cache               1/1 

We can see the new BE we've just created, as follows:

user@system:~$ beadm listBE            Flags    Mountpoint     Space      Policy   Created           ---           -------  -------------- -------    -------  ----------           solaris       N        /              8.79M      static   2016-01-05 12:37  11.3.4        R        -              9.32G      static   2016-01-22 15:51 

man beadm states: "The Flags field indicates whether the boot environment is active now, represented by N; active on reboot, represented by R; or both, represented by NR." So our new BE (11.3.4) will be activated on the next reboot.

Let's reboot into the alternate BE. Use shutdown -i6 -g0 -y to allow applications to shut down gracefully:

root@system:~$ shutdown -i6 -g0 -y

And once we log in, after it reboots, we can see that the new BE is now active:

user@system:~$ beadm listBE            Flags     Mountpoint      Space      Policy  Created     ----          -------  --------------   -------    ------- -----------     solaris       -         -              70.79M      static  2016-01-05 12:37  11.3.4        NR        /               9.46G      static  2016-01-22 15:51 

Notice how little space is used to preserve the old BE.  This is a key advantage of the mandatory ZFS root file system in Oracle Solaris 11.

Note: Not only is this document, which I was authoring while creating this new BE, available in the new BE, even the changes I saved to it since creating the new BE have been propagated to it.  Indeed, upon opening Firefox, it offers to restore all the browser windows I had open in the old BE. That might seem like magic, but it actually has to do with which directories are and are not shared between BEs.

We can check that we are indeed now running Oracle Solaris 11.3 SRU4:

user@system:~$ pkg list entireNAME (PUBLISHER)                      VERSION                    IFO entire                                0.5.11-     i--

As a privileged user, let's rename the original BE to something more descriptive.  We can rename only nonactivated alternate BEs, so in this case, we can rename solaris but not 11.3.4:

root@system:~# beadm rename solaris 11.3.1root@system:~# beadm listBE      Flags   Mountpoint  Space   Policy    Created           ----    ------- ----------  ------  --------  -------           11.3.1  -       -           70.79M  static    2016-01-05 12:37  11.3.4  NR      /           9.46G   static    2016-01-22 15:51 

If for any reason, we don't like the 11.3.4 boot environment, we can simply and quickly boot back into the old 11.3.1 boot environment by activating it for the next reboot (see man beadm):

root@system:~# beadm activate 11.3.1root@system:~# beadm listBE      Flags   Mountpoint    Space   Policy   Created           ----    -----   ------------- ------- -------- ----------           11.3.1   R      -             7.86G   static   2016-01-05 12:37  11.3.4   N      /             1.45G   static   2016-01-22 15:51 

A reboot will now bring the system back to running the old 11.3.1 boot environment.

For further information, see the Oracle Solaris 11 how-to articles, in particular:

Also see:

IPS and Applying IDRs

See "Installing IDRs."

As mentioned in the "Interim Diagnostics or Relief (IDR) Updates" section of "Overview of Oracle Solaris Release Cadence," IDRs provide a diagnostic code or code that provides interim relief for issues encountered by customers, until a final fix becomes available.

To prevent such relief from being accidentally overwritten, a pkg update command performed to a later SRU will fail unless the bug IDs referenced in the IDR metadata are fixed in that SRU.

If you have an IDR installed, see the "Querying Bug Metadata" section below for information about how to check whether the bug IDs are fixed in the SRU to which you plan to update.

You can manually remove the IDR to enable the update to a later SRU, but presuming the relief provided by the IDR is still needed, you need to file a new service request (SR) requesting that a new IDR containing relief for the specified bug IDs be created for the later SRU.

Several weeks of advance notice need to be given to allow time for the creation of the new IDRs for the later SRU.  The metadata in the new IDRs should enable an upgrade from the old SRU and IDRs to the later SRU and IDRs without the need to manually remove the old IDRs first.

For example, assume you have been given idr2293.1 for Oracle Solaris 11.3 SRU1 to provide relief for a ZFS issue:

user@system:~/Downloads$ pkgrepo list -s idr2293.1.p5pPUBLISHER      NAME    O      VERSION solaris        idr2293        1,5.11:20160209T200853Z solaris        system/trusted 0.5.11,5.11-

You can add IDRs to a local repository and ensure that repository is listed as a publisher (see pkg publisher). You might wish to keep IDRs local to the environment in which they are required rather than in your main repository to avoid propagating the IDRs unnecessarily to other environments.

Alternatively, as a privileged user, you can use the .p5p file directly, adding it to your list of publishers:

root@system:# pkg set-publisher -g idr2293.1.p5p solarisroot@system:# pkg publisherPUBLISHER      TYPE    STATUS   P    LOCATION solaris        origin  online   F    file:///user/Downloads/idr2293.1.p5p/ solaris        origin  online   F

As usual, let's do a -nv dry run of the installation first to see what it will do. Note that we specify only the base ID of the IDR, namely idr2293, rather than idr2293.1 or idr2293.1.p5p:

root@system:/user/Downloads# pkg install -nvr idr2293              Packages to install:                   1         Estimated space available:           870.45 GB    Estimated space to be consumed:            13.87 MB           Create boot environment:                  No    Create backup boot environment:                  No             Rebuild boot archive:                  No  Changed packages: solaris   idr2293     None -> 1,5.11:20160209T200853Z  Release Notes:   # Release Notes for IDR : idr2293   # --------------------------------     Release          : Solaris 11.3 SRU # 1.5.0   Platform         : i386    Bug(s) addressed     :       22304187 : labeld can't keep up with the number of setflabel(3TSOL) requests   Package(s) included      :       pkg:/system/trusted    Removal instruction      :   # /usr/bin/pkg uninstall -r idr2293  Generic Instructions :   1) If system is configured with 'Zones', ensure that   IDR is available in a configured repository.    Special Instructions for : idr2293   None.

The Release Notes metadata displayed above indicates what bug(s) the IDR addresses and how to remove the IDR.  It also shows that, by default, no backup BE will be created.

But we can explicitly ask for a backup BE to be created so that we have a BE to revert to in case we're not happy with the IDR and we want to be super cautious in case it doesn't back out cleanly:

root@system:/user/Downloads# pkg install --backup-be-name 11.3.1-vanilla idr2293           Packages to install:               1        Create boot environment:              No Create backup boot environment:             YesRelease Notes:   # Release Notes for IDR : idr2293   # --------------------------------    Release             : Solaris 11.3 SRU # 1.5.0   Platform            : i386      Bug(s) addressed    :      22304187 : labeld can't keep up with the number of setflabel(3TSOL) requests    Package(s) included :      pkg:/system/trusted    Removal instruction  :   # /usr/bin/pkg uninstall -r idr2293    Generic Instructions :   1) If system is configured with 'Zones', ensure that   IDR is available in a configured repository.    Special Instructions for : idr2293   None.  DOWNLOAD                        PKGS   FILES    XFER (MB)  SPEED Completed                       1/1    5/5      0.0/0.0    1.2M/s  PHASE                            ITEMS Installing new actions           13/13 Updating package state database   Done Updating package cache            0/0  Updating image state              Done  Creating fast lookup database     Done  Reading search index              Done  Updating search index              1/1  Updating package cache             1/1 

We can see it has been installed as follows:

user@system:~/Downloads$ pkg list idr2293NAME (PUBLISHER)     VERSION    IFO idr2293              1          i--

And we can see that the specified backup BE was created (and takes up minimal space):

user@system:~/Downloads$ beadm listBE             Flags   Mountpoint   Space    Policy    Created           ---            -----   ----------   -----    ------    ------- 11.3.1         NR      /            8.88G    static    2016-01-05 12:37  11.3.1-vanilla -       -           57.48M    static    2016-02-23 14:33  11.3.4         -       -            1.46G    static    2016-01-22 15:51 

To remove the IDR for any reason, as a privileged user, we simply do the following:

root@system:/user/Downloads# pkg uninstall -r idr2293            Packages to remove:  1         Create boot environment: No  Create backup boot environment: No    PHASE                                          ITEMS Removing old actions                           12/12  Updating package state database                 Done   Updating package cache                           1/1   Updating image state                            Done   Creating fast lookup database                   Done   Reading search index                            Done   Updating search index                            1/1   Updating package cache                           1/1  

When removing IDRs, the update and SRU to which the IDR applies must be available from a configured publisher. For example, if the IDR is for Oracle Solaris 11.3 SRU4, both Oracle Solaris 11.3 SRU1 (which is the update release) and Oracle Solaris 11.3 SRU4 need to be available from a configured publisher to enable IPS to uninstall the IDR. This is because IPS is effectively rolling back the package versions to the update level (if the package wasn't modified in any SRU) or to the SRU level (if it was modified in any SRU and, hence, needs those package versions to be available to it). SRUs are cumulative but don't contain packages that haven't been modified since the last update was released.

We can confirm the IDR is no longer installed, as follows:

user@system:~/Downloads$ pkg list idr2293pkg list: No packages matching 'idr2293' installed

Enhancements to IPS IDR functionality in successive Oracle Solaris 11 updates have made it easier to manage IDRs, including IDRs in Oracle Solaris Zones.

For example, when manually removing an IDR, in the initial Oracle Solaris 11 release, you needed to run pkg reject for the IDR, cutting and pasting the list of packages affected from the IDR's metadata.  Furthermore, if some of those packages weren't installed on the system, the package list needed to be edited to reflect the set of packages that were actually installed.

In a subsequent Oracle Solaris 11 update, the addition of the -ignore-missing flag removed the need to edit the package list.

In Oracle Solaris 11.3, a simple pkg uninstall -r <idr> suffices.  The -r recursively removes the IDR from non-global zones.

See "Removing IDRs."

Troubleshooting Package Installation and Update Issues

See "Troubleshooting Package Installation and Update."

A common cause of issues is an incomplete local repository, which is missing interim updates or SRUs required by IPS to dynamically resolve dependencies.

Another common issue is missing or incorrect publishers or publishers specified in the wrong order if more than one publisher contains a particular package.

Querying CVE Metadata

Even without installing the optional solaris-11-cpu package on a system, you can determine whether a particular CVE that is fixed in an Oracle Solaris SRU might be later than the SRU currently installed on the system, for example:

user@system:~$ pkg search :CVE-2015-8000:INDEX         ACTION VALUE                                                                   PACKAGECVE-2015-8000 set    pkg://solaris/network/dns/bind@,5.11-          pkg:/support/critical-patch-update/solaris-11-cpu@2015.12-1CVE-2015-8000 set    pkg://solaris/network/dns/bind@,5.11-          pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 CVE-2015-8000 set    pkg://solaris/network/dns/bind@,5.11-          pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1CVE-2015-8000 set    pkg://solaris/service/network/dns/bind@,5.11-  pkg:/support/critical-patch-update/solaris-11-cpu@2015.12-1CVE-2015-8000 set    pkg://solaris/service/network/dns/bind@,5.11-  pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 CVE-2015-8000 set    pkg://solaris/service/network/dns/bind@,5.11-  pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1

The output above tells us that the DNS BIND security vulnerability, CVE-2015-8000, is fixed in Oracle Solaris 11.3 SRU3.6 and later.  So we can install this fix by either updating the system directly to Oracle Solaris 11.3 SRU3.6 (pkg update entire@**0.5.11-**) or indirectly via the optional solaris-11-cpu package if it has been installed (pkg update **solaris-11-cpu@2015.12-1**), which will also update entire to at least Oracle Solaris 11.3 SRU3.6 via its dependencies.  Indeed, updating the solaris-11-cpu package will update the system to the latest SRU that contains new security fixes which it references.

Furthermore, as SRUs are added to the support repository, you can check to see which CVEs are fixed in them, for example:

user@system:~$ pkg search -r info.cve:|grep 2016.1info.cve   set    CVE-1999-0103 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2002-2443 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2003-0001 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2004-0230 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1  : info.cve   set    CVE-2016-0419 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0426 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0428 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0431 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0440 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0458 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0493 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0535 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0618 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0777 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1 info.cve   set    CVE-2016-0778 pkg:/support/critical-patch-update/solaris-11-cpu@2016.1-1

Installing solaris-11-cpu from your repository is easy.  As always, it is a good idea to use the pkg command option -nv to specify a dry run first so you can see what the command will do:

root@system:~# pkg install -nv solaris-11-cpu            Packages to install:                  1       Estimated space available:          889.40 GB  Estimated space to be consumed:          147.59 MB         Create boot environment:                No Create backup boot environment:                 No            Rebuild boot archive:                 No  Changed packages: solaris   support/critical-patch-update/solaris-11-cpu     None -> 2015.10,5.11-2:20151009T231515Z

Note also that no new BE will be created, because we're just installing an additional metadata package rather than changing the underlying operating system.

As in previous examples, the system currently has Oracle Solaris 11.3 SRU1.5 installed.  The command above shows that the corresponding version of the solaris-11-cpu package will be installed, namely that from 2015.10:

user@system:~$ pkg contents -m solaris-11-cpu@2015.10 | grep entiredepend fmri=pkg://solaris/entire@0.5.11,5.11- type=require

Installing solaris-11-cpu will not update the SRU installed on the system unless and until we subsequently update the solaris-11-cpu package to the latest available version, for example, to 2016.1.

Rerunning the command above without the -nv option will install the package:

root@system:~# pkg install solaris-11-cpu           Packages to install:             1        Create boot environment:            No Create backup boot environment:            No  DOWNLOAD                                      PKGS        FILES    XFER (MB)   SPEED Completed                                      1/1          3/3      0.0/0.0  7.1k/s  PHASE                                            ITEMS Installing new actions                       6063/6063 Updating package state database                   Done  Updating package cache                             0/0  Updating image state                              Done  Creating fast lookup database                     Done  Reading search index                              Done  Updating search index                              1/1  Updating package cache                             1/1 

The version installed can be confirmed as follows:

root@system:~# pkg list solaris-11-cpuNAME (PUBLISHER)                                   VERSION                IFO support/critical-patch-update/solaris-11-cpu       2015.10-2              i--

See the SRU documentation on My Oracle Support, document 1559480.2, for further information on SRU releases, release dates, links to different install images, READMEs, and so on.  The READMEs referenced include a summary of why you should consider installing the particular SRU as well as details about the bugs fixed, packages updated, IDRs that are automatically superseded by the SRU, and so on.

Querying Bug Metadata

By convention, Oracle products use the "base" bug ID of a bug tree to provide a common bug fix reference across releases.

For example, bug 22611845, "Backport 21241934 to 11.3-SRU - ZFSSA driver should return free (versus available) space," is the Oracle Solaris 11.3 sub-bug for the backport of the "base" bug ID, 21241934, "ZFSSA driver should return free (versus available) space."

It is the "base" bug ID, not the sub-bug, which will be referenced in the IPS metadata for the Oracle Solaris 11.3 SRU that fixes the issue:

user@system:~$ pkg search -f 21241934INDEX                        ACTION  VALUE          PACKAGE     set     21241934       pkg:/cloud/openstack/cinder@0.2014.2.2-

The output above tells us the bug is fixed in Oracle Solaris 11.3 SRU5.

Note that the -f option in pkg search is important in order to see whether the bug is fixed in all circumstances:

-f     Show all results, regardless of package version. By default,         search prunes results from packages older than the currently         installed version and from package versions excluded by current         incorporations.

If the same command is run without -f, we get the following:

user@system:~$ pkg search 21241934user@system:~$ 

This is because, although the bug is fixed in a later SRU than the one applied to the system, the incorporation containing the fix is not installed and, hence, the fix is not applicable to this system:

user@system:~$ pkg list cloud/openstack/cinderpkg list: No packages matching 'cloud/openstack/cinder' installed

Using pkg search -f <BugID> followed by pkg search <BugID> is useful to determine that a bug fix is available but is not applicable to the system.  That is, no action is required because the system is not impacted by the bug.

There is one caveat: bug ID metadata is not included in Oracle Solaris 11 updates, so pkg search -f <BugID> will return information only on bugs fixed in SRUs, not in releases or updates.  Oracle plans to look into including bug ID metadata in Oracle Solaris 12 updates. (This is subject to change.)

Details about security vulnerabilities and many other bugs are not visible to customers.  For security vulnerabilities, see the section "Querying CVE Metadata" and reference the critical patch update documentation.

See Also

And here are some additional Oracle Solaris resources:

About the Author

As the Software Lifecycle Engineering Director for Oracle's Systems group, Gerry Haskins is responsible for Oracle Solaris patching and best practices and well as Oracle SuperCluster installation and configuration utilities and quarterly full-stack download patches (QFSDPs).

| Revision 1.1, 07/25/2018 |
| Revision 1.0, 04/18/2016 |

Follow us:
Blog | Facebook | Twitter | YouTube

Post Details
Added on Apr 11 2016