News, tips, partners, and perspectives for the Oracle Solaris operating system

Solaris 10 Kernel PatchID Sequence

Gerry Haskins
Director Security and Release Management

Entry updated June 6, 2013, with new Solaris 10 Kernel PatchIDs, 150400-xx (SPARC) and 150401-xx (x86):

Patch Rejuvenation

When a patch becomes complex and unwieldy, it is "Rejuvenated".   That is, no more revisions of the patch are created.  Instead, further code changes to objects contained in the patch are delivered in a series of smaller, simpler, new child PatchIDs, each of which declares a dependency upon (i.e. requires) the parent Patch.

This process is known as Patch Rejuvenation and is typically performed on the Kernel patches associated with Solaris Update releases.

Customers still need to install the large parent patch once, but subsequent bug fixes are delivered in smaller, simpler patches.

The parent patches effectively provide "stepping-stones" to reach certain key functionality levels, with rejuvenation enabling smaller incremental change in between Update releases.

If a child patch itself becomes complex and unwieldy over time, it too may be Rejuvenated, so we end up with a "family tree" of PatchIDs providing a lineage of bug fixes for particular code areas such as the Kernel.

See https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1006717.1 for further information.

Effect of Solaris Update "SplitGate" process on PatchIDs

Starting in February 2007, a new, improved, source code "Gate" management process was introduced for core Solaris.  This is known as the "SplitGate" process.  This replaced the old "Feature Foldback" Gate management model. "SplitGate" provides much better separation during the development process between feature code destined for release as part of a Solaris Update release and sustaining (bug fix) patches.  This addresses the problem with earlier Solaris 10 Update releases where issues with features destined for an Update release was adversely impacting the releasability of sustaining (bug fix) patches for customers in production on earlier Solaris 10 releases.

Note, as described in earlier blog postings, any change to pre-existing packages, whether as the result of new feature code or bug fixes, is always delivered in a patch.  Therefore, the Kernel patches released at the end of each Update do contain a mixture of feature and bug fix code.  What "SplitGate" provides is better separation of the feature code from bug fix patches until the Update is ready for release.

The improvement in Solaris 10 Kernel patch releasability has been dramatic:

Releasable Solaris 10 Kernel Patches using “Feature Foldback” model:

    SPARC:      21 out of 66 = 32%    (from March 2005 to February 2007)
    x86:            12 out of 66 = 18%    (from March 2005 to February 2007)

Releasable Solaris 10 Kernel Patches using “SplitGate” model:

    SPARC:      105 out of 121 =  87%    (from February 2007 to current [Sept 10th, 2013])
    x86:            108 out of 120 =  90%    (from February 2007 to current [Sept 10th, 2013])

A side effect of the "SplitGate" process, is that each Solaris 10 Update release, starting with Solaris 10 8/07 (Update 4) introduces a new set of PatchIDs which accumulate and obsolete the preceding set of PatchIDs. 

So, for example, a single new Kernel PatchID revision will appear at the end of each Solaris 10 Update release. For instance, 120011-14 (SPARC) and 120012-14 (x86) is the Kernel PatchID associated with Solaris 10 8/07 (Update 4).  Revisions -01 to -13 of this patch are not released to customers as these are purely for the interim internal builds of the Update.  Therefore, 120011-14 (SPARC) and 120012-14 (x86) are the only revisions of these PatchIDs to be released to customers.  This Kernel patch associated with the Update release is then Rejuvenated, so subsequent bug fixes will appear in a new set of PatchIDs, each of which will depend upon (i.e. require) the parent PatchID from which they were rejuvenated.

Solaris 10 Kernel Patch Lineage 

The impact of Patch Rejuvenation and the "SplitGate" process results in the following sequence of Solaris 10 Kernel PatchIDs, starting with the youngest (newest) child PatchID.  The install order of Kernel patches is starting from the bottom of the table upwards:

Solaris 10 SPARC Kernel PatchIDs Description Solaris 10 x86 Kernel PatchIDs

150400-01 to 150400-xx

Kernel Bug Fixes
from July 2013

 150401-01 to 150401-xx

  148888-01 to 148888-05

Kernel Bug Fixes
post Solaris 10 1/13 (Update 11)
to June 2013

 148889-01 to 148889-05

  147147-26 only

Solaris 10 1/13 (Update 11) Kernel PatchID

 147148-26 only

  147440-01 to 147440-27

Kernel Bug Fixes
post Solaris 10 8/11 (Update 10)

 147441-01 to 147441-27

  144500-19 only

Solaris 10 8/11 (Update 10) Kernel PatchID  144501-19 only
 144488-01 to 144488-17

Kernel Bug Fixes
post Solaris 10 9/10 (Update 9)

 144489-01 to 144489-17

  142909-17 only

Solaris 10 9/10 (Update 9) Kernel PatchID  142910-17 only
 142900-01 to 142900-15

Kernel Bug Fixes
post Solaris 10 10/09 (Update 8)

 142901-01 to 142901-15
 141444-09 only Solaris 10 10/09 (Update 8) Kernel PatchID   141445-09 only
 141414-01 to 141414-10

Kernel Bug Fixes
post Solaris 10 5/09 (Update 7)

 141415-01 to 141415-10
139555-08 only Solaris 10 5/09 (Update 7) Kernel PatchID 139556-08 only
138888-01 to 138888-08

Kernel Bug Fixes
post Solaris 10 10/08 (Update 6)

138889-01 to 138889-08
 137137-09 only

Solaris 10 10/08 (Update 6) Kernel PatchID

 137138-09 only
137111-01 to 137111-08

Kernel Bug Fixes
post Solaris 10 5/08 (Update 5)

137112-01 to 137112-08
 127127-11 only Solaris 10 5/08 (Update 5) Kernel PatchID  127128-11 only
 127111-01 to 127111-11

Kernel Bug Fixes
post Solaris 10 8/07 (Update 4)

 127112-01 to 127112-11
 120011-14 only Solaris 10 8/07 (Update 4) Kernel PatchID  120012-14 only
 125100-04 to 125100-10

Kernel Bug Fixes
post Solaris 10 11/06 (Update 3)

125101-01 to 125101-10
118833-02 to 118833-36

118833-33 (SPARC) / 118855-33 (x86) is the Kernel patch included in Solaris 10 11/06 (Update 3) but these patches were not releasable as "standalone" patches to SunSolve.

118833-17 (SPARC) / 118855-14 (x86) is the Kernel patch included in Solaris 10 6/06 (Update 2). 118855-14 was not releasable as a "standalone" patch to SunSolve.

118855-01 to 118855-36
118822-01 to 118822-30 118822-25 (SPARC) / 118844-26 (x86) is the Kernel patch included in Solaris 10 1/06 (Update 1). 118844-26 was not releasable as a "standalone" patch to SunSolve.

118844-01 to 118844-30

Join the discussion

Comments ( 54 )
  • Timothy Kennedy Thursday, April 17, 2008

    \^ That is an awesome post! Thanks for that. It's really great info, and explains a lot.

  • steve norton Friday, April 18, 2008

    Thanks, this explains a lot of the hassle we've seen getting solaris 10 u 4 rolled successfully.

  • Martin Paul Tuesday, April 22, 2008

    Thanks Gerry; great information as always!

    While you're mainly talking about kernel patches, I guess that this:

    A side effect of the "SplitGate" process, is that each

    Solaris 10 Update release, starting with Solaris 10

    8/07 (Update 4) introduces a new set of PatchIDs

    which accumulate and obsolete the preceding set of


    .. explains the effect I'm seeing currently with non-kernel patches? Many of them are obsolete by new patches, like 127877-01 obsoleted by 127879-01, and the README stating:

    This patch revision accumulates generic Sustaining

    patch 127877-01 into Solaris S10U5 Update.

    So we see a lot of "new" patches coming for Solaris 10 < 8/05 now without any real changes, making it hard to find out about those which contain new fixes.


  • Gerry Haskins Wednesday, April 23, 2008

    Yep, good point Martin.

    It's not just the Kernel PatchIDs which change in the "SplitGate" model at the end of each Update. All patches changes during the Update release development will be superseded by a new set of PatchIDs at the end of the Update. I'll add a blog entry explaining the "SplitGate" process in a little more detail to make it clearer.

    Usually, it is only the Kernel patch associated with the Update release which is rejuvenated after the Update, so only it will change PatchID twice in rapid succession. For example, 12510[01]-10 was obsoleted by the Solaris 10 8/07 (Update 4) Kernel patch, 12001[12]-14, which was then rejuvenated, with 12711[12] becoming the new Kernel PatchID. Other patches modified during the Update build process will typically only change PatchID once. Patches not modified during the Update build process remain unchanged (but remain subject to normal patch accumulations and obsoletions going forward).

  • Anthony Monday, April 28, 2008

    What's the operational impact? Ie., my group typically applies patches via periodic installation of the Recommended cluster. Wil the cluster contain both 127127-11 only

    Solaris 10 5/08 (Update 5) and 120011-14, with 127127-11 earlier in the patch_order file?

  • Gerry Haskins Monday, April 28, 2008

    Hi Anthony!

    The Recommended Cluster will contain both 127127-11 and 120011-14.

    Since 120011-14 is the the Kernel patch associated with Solaris 10 8/07 (Update 4) it will be ordered \*before\* 127127-11, which is the Kernel patch associated with Solaris 10 5/08 (Update 5).

    So the Kernel patch install order sequence in the Recommended Patch Cluster will be:

    118833-36 (the Kernel patch released after S10U3), which was rejuvenated so subsequent Kernel patches depend upon it, then 120011-14 (the Kernel patch included in S10U4), which was rejuvenated so subsequent Kernel patches depend upon it, then 127127-11 (the Kernel patch included in S10U5), which will be rejuvenated so subsequent Kernel patches will depend upon it.

    As I say, you should think of the Kernel patches associated with each Solaris Update as being "stepping stones" to levels of functionality, with smaller Kernel patches being released between Updates to provide bug fixes for escalated issues.

    BTW: 118833-36 accumulated and obsoleted 118822, so 118822 does not appear in the Cluster.

    Perhaps my exchange with Martin confused you. Martin was pointing out that in the "SplitGate" process a number of patches are issued at the end of each Update which accumulate and obsolete earlier Sustaining patches, but which don't provide additional bug fixes over what was contained in those Sustaining patches. This is a side effect of the SplitGate process. But in the case of the Kernel patches, the Kernel patches associated with each Update do contain a large number of additional bug fixes as well as support for features included in the Update.

    Critical customer escalated bug fixes and support for new hardware will be released in the smaller sustaining patches between Updates, including Kernel patches.

    Almost all other bug fixes will be released in the patches associated with the Update release, including the Kernel patch.

  • T_S_Kimball Thursday, May 22, 2008

    Though I'm sure most don't worry about this, the fact that Solaris 10 Recommended clusters will include patch groups for every version of Solaris 10 is going to make this cluster \*really\* big after a while.

    Looking through your downloads page and our jumpstart archives (for 2.6 and below), I admit this has been trending to be larger over time anyway - with the exception being 2.5.1. But as of Solaris 8 we've gone nowhere but up - and usually double for each subsequent release. For Sol-10 hosts built upon variants of 'Core,' this can mean the patch cluster is much larger than the actual installation (some of us are still trying to work with 9 and 18 Gig disks ya know ;).

    Will there be an eventual limit upon this? I've already sent up a notice that any x64 host running less than 6/06 (pre-GRUB) is getting a re-jump to at least 8/07 - it's nearly 3x faster than dealing with the patch instructions.


  • Gerry Haskins Friday, May 23, 2008

    Hi TSK!

    Yes, the point you make is valid. The clusters will continue to grow over time. We could potentially look to split the clusters into "old" and "new", so that customers who have already installed the "old" patches don't have to keep downloading them.

    Can you please clarify what you mean by " I've already sent up a notice that any x64 host running less than 6/06 (pre-GRUB) is getting a re-jump to at least 8/07 - it's nearly 3x faster than dealing with the patch instructions." ?

    Are you saying that you are upgrading pre-GRUB systems to 8/07 (Update 4) rather than patching them ? If so, that's consistent with what I recommend.

  • Anthony Friday, May 23, 2008

    The "old" and "new" idea is sort of what I've been envisioning, but developed more. There could be monthly or quarterly mini-releases like we were supposed to get with our Subscriptions back in the late 90's. Patch bundles could be relative to a mini-release, or could be eliminated altogether in favor of a model of more-frequent incremental OS upgrades. This could obviate some of the problems we've seen in the last year with broken recommended bundles, eg. as fallout from a withdrawn patch rev wreaking havoc along the dependency tree.

    Along these lines, one could today have a Sol 10 11/06 bundle, an 8/07 bundle, etc.

  • Gerry Haskins Friday, May 23, 2008

    Hi Anthony!

    Funny you should mention a Solaris 10 8/07 patch bundle, etc.

    We plan to release the Solaris 10 5/08 [Update 5] Patch Bundle in the next couple of weeks as a direct result of customer feedback received after Solaris 10 8/07 (Update 4). The feedback from some customers was that they wanted to bring all their systems to the same patch level as their new hardware which required Update 4 to be installed.

    The Solaris 10 5/08 Patch Bundle will patch any Solaris 10 system up to the same patch level as a system with Solaris 10 5/08 (Update 5) installed.

    Note, the patched system will not contain new packages introduced in the Solaris 10 5/08 release image.

    We plan to release a similar patch bundle (probably just an incremental patch bundle) for Update 6 and any subsequent Updates when they release.

    We don't plan to release retrospective patch bundles for earlier releases.

    I'll be blogging more about this soon, and further information will be published on SunSolve shortly.

    Best Wishes,


  • T_S_Kimball Saturday, May 24, 2008

    Yes, I meant installing the 8/07 image - either through an 'upgrade' profile via jumpstart or building a new boot disk from scratch (using a spare chassis) and swapping it. I had spent an entire night reading the various documents involved with pre-GRUB upgrades and discovered that it could take well over the 2-2.5 hours our various upgrade methods.

    We just added the Solaris 10 5/08 image on the install server this past week (but not enabled as our default image yet) so I'll keep an eye out regarding the new patch formats.


    PS - We got caught off guard when the SPARC servers started to need multiple patch/reboot runs; We had figured it was specific to the x64 stuff. I suggest (if not there already) that either the install script or the readme for the cluster makes this very clear when you run it.

  • Anthony Sunday, May 25, 2008

    Actually what I meant was a patch bundle meant to install on, say, 8/07, so that it assumed a baseline and didn't need to include anything bundled in a given release.

    Of course, it'd also be nice to be able to use wget to retrieve patch bundles again -- this broke within the last few months :(

  • C F Patrick Friday, May 30, 2008

    How would this 'Solaris 10 5/08 [Update 5] Patch Bundle' differ from using the Solaris 10 5/08 release and doing an Upgrade install?

    Isn't that currently available today with any release?

    Would using this get two boxes - say one built with U2 and one built with U3 to the exact same patch/package level? (I'm thinking zone move here, which we have had problems with in the past due to patch levels differing even after installing the same recommended cluster).

  • Gerry Haskins Friday, June 6, 2008


    CF Patrick wrote: "How would this 'Solaris 10 5/08 [Update 5] Patch Bundle' differ from using the Solaris 10 5/08 release and doing an Upgrade install?"

    The Solaris 10 5/08 (Update 5) release image contains new packages as well as patches. The new packages are required by some of the new features included in the release.

    The Solaris 10 5/08 Patch Bundle, which is now available on SunSolve [I'll add a blog entry about it later], provides the equivalent set of patches to the Solaris 10 5/08 release image, but does \*not\* include new packages.

    Experienced Solaris users may remember the old "Maintenance Updates" (MU) which we shipped for Solaris 8 and older releases. The Solaris 10 5/08 Patch Bundle is effectively the same as the old Maintenance Updates - it provides the equivalent set of patches to the corresponding Solaris Update (SU) release image.

    The Solaris 10 5/08 Patch Bundle is designed to enable customers to bring older systems up to the same patch level as new hardware running the Solaris 10 5/08 release image. Of course, customers are very welcome to upgrade to the entire Solaris 10 5/08 release image, and this is the way to ensure all the new features in Update 5 will be available, but some customers have change control restrictions which allow them to patch but not upgrade. The Solaris 10 5/08 patch bundle may help such customers.

    Regarding your 2nd question around moving Zones, that's a rather complex subject which I'll attempt to address separately in future.

  • Jean-Marc Gillet Saturday, June 14, 2008

    137111-01 is released with many bug fixes. Most of them concern mutex operations.

  • Gerry Haskins Tuesday, June 17, 2008

    Thanks Jean-Marc!

    I've updated the Kernel PatchID table to show that 137111 (SPARC) / 137112 (x86) have been released.

  • Jean-Marc Gillet Friday, November 14, 2008

    Solaris 10 Update 6 Kernel PatchID is 137137-06 (SPARC) / 137138-06 (x86) I think. I didn't install u6 yet so I cannot be 100 % sure.

    Seeing the bug list and the mutex alignment crash of 32-bit apps, don't hesitate a second to install 137137-09 / 137138-09 afterwards.

  • Mike Gerdts Monday, December 8, 2008

    This post has been extremely helpful over the past several months - I have referred (myself and others) to it several times.

    Can I bother you for an update? What will the u6 sustaining and u7 patch numbers be?

  • Gerry Haskins Monday, December 8, 2008

    Hi Mike!

    The post-U6 Sustaining Kernel PatchID is 138888 (SPARC) / 138889 (x86). The Kernel PatchID which will go into U7 will be 139555 (SPARC) / 139556 (x86). I'll add these to the table above. None of these PatchIDs have been released yet, although the first of the post-U6 sustaining Kernel patches is due to be released December 16.

    Best Wishes,


  • Harish Maliwal Wednesday, September 23, 2009

    Hi Gerry Haskins,

    Thanks you so much for above information.

    I am planning to upgrade solaris patch cluster on 3 v490 servers(Oracle 10g nodes, current patch revision is 118833-18. Pls give me a detial procedure and if my server goes down after upgrading the same then how i would recover my system. Pls reply on mail.

    Thanks in advance.


    Harish Maliwal


  • Jeff Draht Wednesday, October 14, 2009

    There seems to be an issue with the installcluster --s10cluster running during Jumpstart Installation?

    Firstly, the global variable for ROOTDIR is set to nothing.

    It had to be set to /a

    However, even after resolving that, the new patch script procedure just doesn't seem to work properly at that level?

    Does anyone have any similar information or experience and/or suggestions?


  • Bilal Baig Thursday, October 15, 2009

    This is an awesome site. It helped me allot in trying to decipher patch numbers with respect to updates. Thanks

  • Ed Thursday, October 15, 2009

    hi Jeff,

    to install a patch cluster from a jumpstart finish script, use

    <path-to-cluster>/installcluster --s10cluster -R /a



  • Jean-Marc Gillet Tuesday, February 16, 2010

    Hi again Jerry.

    Do you know the reason behind patch 143055-01 "KU Place Holder patch" (dummy patch for Solaris 10 Update 9) ?

  • Gerry Haskins Wednesday, February 24, 2010

    Hi Jean-Marc!

    Due to the amount of change in each Solaris 10 Update, Kernel patches tends to grow large and suck in non-kernel code.

    To break these large Kernel patches up into manageable pieces going forward, we "rejuvenate" the Kernel patch after each Solaris 10 Update. In this process we freeze the existing Kernel patch and subsequent changes are released in a series of smaller patches each of which depends upon the frozen Kernel patch.

    After rejuvenation, the frozen Kernel patch patch cannot be modified.

    Despite intensive testing, it's still possible for issues in the frozen Kernel patch to slip through and be found post-release by customers. To enable us to resolve such issues, we use a level of indirection to enable us to fix the behavior of the frozen Kernel patch without needing to up'rev the frozen Kernel patch itself.

    One such potential issue is a missing hard dependency on another patch. Normally, we would up'rev the problem patch and add missing dependency. But we cannot do that for the frozen Kernel patch.

    To get around this issue, we introduce the "Place Holder patch" and have the Kernel patch require it. If we need to force installation of any patch prior to the frozen Kernel patch installed, we up'rev the "Place Holder patch" and make it require the needed patch. Older revisions of the "Place Holder patch" are withdrawn which effectively makes the frozen Kernel patch depend upon the needed patch, hence fixing the issue.

    The Place Holder patches have been introduced around same time as "Patch behavior" patches (125555, 125556) which enable us to fix pre- and post- installation issues with the frozen Kernel patches.

    Together, these levels of indirection enable us to resolve a broad range of potential customer patch installation issues.

    Patches 143055-01 and 143056-01 were added to the Solaris 10 Update 9 Sustaining Kernel patch requirement chain because there was a potential need to rejuvenate the Kernel patch in the middle of Update 9, which has since been resolved by other means.

    Best Wishes,


  • Woo Monday, July 12, 2010

    Could you also add the Kernel ID that the FCS release contained?

  • Gerry Haskins Thursday, July 22, 2010

    Hi Woo,

    There are no patches pre-applied to the FCS release.

    The first Kernel patch released after FCS was 118822-xx (SPARC) and 118844-xx (x86) as listed above.

    Best Wishes,


  • Shaik Friday, September 3, 2010

    Can any one let me know the best procedure to upgrade Solaris 10 (update 4 ) to

    Solaris 10 (Update 6 )

  • David Delano Tuesday, October 19, 2010

    We are having a problem applying the 9/28 Baseline (Recommended) to Solaris 10 servers, using xVM Ops Center. All the patches get installed except the 142909-17 JKP, it complains about the prerequisite 142911-01 placeholder patch not being installed. Trouble is, Ops Center is pulling the 142911-01 patch out of the install list saying there are no packages which 142911-01 fixes installed on the machine. Any thoughts?


  • Gerry Haskins Thursday, November 18, 2010

    Hi David & Pradeep,

    Please install 142911-01 manually to the target system before applying 142909-17.

    David, 142911-01 patches SUNWcsr, which is Core Solaris (Root), so hard to see how you wouldn't have that package installed on the target system.

    Best Wishes,


  • Gerry Haskins Monday, November 22, 2010

    Hi David,

    I've followed up on this with a colleague in the Ops Center team and he tells me the issue you experienced is due to a known bug in the Ops Center Agent:

    "There is a bug in the Ops Center Agent, that it is in certain cases unable to determine the correct update release of an installed package.

    This patch will only patch the package SUNWcsr, so for unknown reason this package is seen as what we call NCO (non-certified object).

    It could be that some patches which are freshbitted into the package have been re-installed, this would fool the 2.5 algorithm.

    In the soon to be released new version, we have re-written this code to make it much more bullet proof."

    "This "filtering out" of applicable patches can happen again in the future, or even today, further patches could be missing, but if there are no further dependencies, they will just silently get missed to install."

    The short term solution to the specific issue you encountered is to manually install the patch as I previously recommended. The longer term solution will be to upgrade to the next version of Ops Center which I believe is in the process of being released, as I understand that that fixes the underlying bug.

    Best Wishes,


  • Susan Tuesday, February 15, 2011

    Will the blog still be available here after Oracle integration completed?

    Or there will be another place to provide such information?

  • Gerry Haskins Tuesday, February 15, 2011

    Hi Susan,

    Current plan is for the blogs to continue. If that changes, I'll find a good home (probably on OTN) for all the information here, but I don't expect it to change.

    Best Wishes,


  • Chris Tuesday, April 19, 2011

    144500-xx only - Solaris 10 Update 10 Kernel PatchID

    Interesting, I wonder when this patch will be available. I did search oracle.com and I see no info about it. I was wondering if you know when U10 will be released maybe?

  • Gerry Haskins Tuesday, April 26, 2011

    Hi Chris,

    144500-xx will only be released when Solaris 10 Update 10 is released, which should be later this year.

    Best Wishes,


  • Jean-Marc Gillet Friday, August 5, 2011

    ... i.e. now. 144500-19 / 144501-19 was just released.

  • Nathan Thursday, August 18, 2011

    Is this page still being updated?



  • Kenny Wednesday, August 24, 2011

    Has Solaris 10 Update 10 been released? Just curious.



  • guest Thursday, August 25, 2011

    Can you assist in determining Common Criteria information for Solaris 10 SPARC TE patched at 142909-17. Is update 9 covered under certification of Rel 11/06?

  • Gerry Haskins Thursday, September 1, 2011

    Hi Nathan, Kenny, "guest",

    Nathan, yes this page is still being updated.

    Kenny, Solaris 10 Update 10 has not yet being released, although it did escape onto MOS for a couple of hours by mistake. However, the patches from Update 10 have already being released, including the feature Kernel patch, 144500-19 (SPARC) / 144501-19 (x86).

    "Guest", I talked to my colleagues in "Trusted", and here's what they tell me:

    "The last Assurance Continuity we did for Solaris 10 11/06 was for Solaris 10 5/09 (Update 7). Update 9 is not covered."

    "We don't achieve a Common Criteria certificate for every version of the OS. We've known many customers that just want the base Common Criteria evaluated version of Solaris, and they add whatever patches they need."

    Best Wishes,


  • Chris Thursday, September 15, 2011

    Great, so 147440-01 was released 10 days ago, and Sol 10 U10 08/11 is available for download on Oracle.com website... :)

    My question is, if I have U6 or u8 and wanted to go to U10, do I need to upgrade my server? or can I apply patches to get all its features? Whats the easiest and simplest ways to go to U10?

    Many thanks :)

    This page is so useful

  • Marcel Hofstetter Wednesday, February 20, 2013

    Are the Kernel ID's for Update 11 and post 11 already known?


  • Jean-Marc Gillet Monday, March 4, 2013

    Update 11 at last ! Thanks again for keeping the list up-to-date.

  • guest Friday, July 12, 2013

    Release 148888-05 at Jun/28.

    Please revise a description of "148888-01 to 148888-04"

  • guest Friday, July 12, 2013

    patch 1488888/148889 is currently up to -05


  • Gerry Haskins Tuesday, September 10, 2013

    Thanks Glen,

    I've updated the table to reflect this.

    Apologies for any inconvenience caused.


  • guest Tuesday, September 24, 2013

    Hi there,

    I am new to Solaris so please help me understand how versioning is one.

    I want to know, how old is this OS ?

    Solaris Version :10 3/05 s10_74L2a

    Kernel Patch :142900-13

    Sun System Firmware :7.2.9.a

    Model :SPARC Enterprise T5220

    Looking 10 3/05 (its Mar, 2005) , looks very old temporary release) but the Patch is indicating it's 10/09 as per the table below.

    Can you help.



  • guest Monday, November 25, 2013

    Hi Adam,

    Apologies for my delay in responding to you.

    The Solaris version "10 3/05 s10_74L2a" shows that the system was installed with the original Solaris 10 release from March 2005 (3/05).

    It has since been patched up to Kernel patch 142900-13 which, as the table above shows, is the Kernel patch level after Solaris 10 10/09 (Update 8) and before Solaris 10 9/10 (Update 9).

    Since it's over 3 years behind the current Kernel patch level, you should consider patching up to the current Kernel patch level by applying the Solaris 10 OS Recommended patchset. This will also apply other patches addressing security, system availability, data corruption, and other critical fixes.

    As mentioned elsewhere in this blog, patching a system will bring pre-existing packages up to the same software level as the corresponding Update release (in your case currently Update 8). However, it will not apply new packages introduced in Update releases, which may be needed for newer hardware support, and some software features.

    For an existing system like yours, patching should be sufficient. Most people prefer to patch existing systems rather than upgrading to a later Update release.

    If you get new hardware, you'll need to install it with a later release, preferrably Solaris 11.1 + latest SRU. See blogs.oracle.com/Solaris11Life for details.

    Best Wishes,


  • Louis R. Friday, May 2, 2014

    Hi Gerry,

    I hope you don't consider this off-topic, but how to remove a kernel patch when booted into failsafe mode?

    I upgraded to U11 from U9 without checking for PowerPatch compatibility. Now my SPARC T3 won't boot as described in Doc ID 1358671.1 The resolution there is to remove the offending kernel patches. But patchrm "Cannot check name /var/sadm/pkg" because of the actual OS now being under /a.

    Any suggestions would be appreciated.



  • Gerry Friday, July 4, 2014

    Hi Louis,

    Apologies for my delay in responding.

    I assume you got your question answered through the normal support channels, but for reference:

    The first question is what kind of volume manager is in play, I'm guessing perhaps zfs root here if so and root is mounted on /a then

    'patchrm -R /a <patchid>' should do the trick

    If other patches are installed that depend on the Kernel patch, then they must be backed out first.

    I note you state you upgraded. If you upgraded to U11 (rather than applying the patch bundle), and if you do not have an earlier Live Upgrade Boot Environment to boot back to, then you are stuck, as patches are pre-applied in the Update image and can't be backed out.

    This is one of the key reasons to use Live Upgrade - an easy roll-back mechanism if issues arise.

    Best Wishes,


  • guest Friday, January 16, 2015

    I have a machine /etc/release shows the following:

    Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC

    Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. Assembled 11 August 2010


    pkginfo -l SUNWsolnm

    PKGINST: SUNWsolnm

    NAME: Solaris Naming Enabler

    CATEGORY: system

    ARCH: sparc

    VERSION: 10,REV=2010.

    BASEDIR: /

    VENDOR: Oracle Corporation

    DESC: Enable Solaris Name in /etc/release file

    PSTAMP: re29796

    INSTDATE: Jun 28 2011 22:13

    Is this machine and others like it should have kernel updated. BTW, these machines are connected to filer and running UFS filesystem.

  • Gerry Haskins Wednesday, March 25, 2015


    Apologies for my delay in responding.

    You should use 'uname -a' to see the current Kernel patch installed.

    The recommendation would be to install the current Solaris 10 Recommended patchset from MOS. This should be done every 6 to 9 months if possible.

    Best Wishes,


  • guest Wednesday, July 1, 2015

    I have loaded solaris 10 patchset update 11 ( soalris 10 1/13 s10s_u11wos_24a) and all seems to have completed ok.

    My kernal version is latest available now :

    5.10 Generic_150400-24 sun4v sparc SUNW,SPARC-Enterprise-T2000

    but when i look at pkginfo and /etc/release it does not give me information I expect, why is this ?

    pkginfo -l SUNWsolnm | grep VERSION

    VERSION: 10,REV=2008.

    cat /etc/release

    Solaris 10 10/08 s10s_u6wos_07b SPARC

    Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.

    Use is subject to license terms.

    Assembled 27 October 2008

    Should this reflect the soalris 10 1/13 s10s_u11 info ?


  • guest Monday, August 24, 2015


    We don't modify the first line of /etc/release when we patch, as we want to maintain info on which version of Solaris the system was originally installed with.

    However, in later Solaris Update patch bundles, such as Solaris 10 1/13 (Update 11)

    Patchset, we do append a line to the end of /etc/release stating that it had been patched up to the Solaris Update patch level (for all pre-existing packages).

    If you applied the patchset to the live boot environment (as opposed to an offline Alternate Boot Environment (ABE)), you'll need to reboot for many of the changes to take effect.

    And obviously, if you applied it to an ABE, you'll need to boot into that ABE.

    The Kernel patch you mention, 150400-24, is post Solaris 10 update 11, so presumably you applied the Solaris 10 Update 11 patchset to bring the rest of the system up to the Solaris 10 Update 11 level.

    But I'm puzzled as to exactly what you've applied. The Solaris 10 Update 11 patch bundle is called "Solaris 10 1/13 (Update 11) Patchset" in its README.

    I'm not sure what the "solaris 10 1/13 s10s_u11wos_24a" is that you refer to. It sounds more like the Update image itself rather than the equivalent patch bundle.

    Feel free to send me the install logs offlline (gerry.haskins@oracle.com) and I can investigate further.

    Best Wishes,


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.