Solaris 10 Kernel PatchID Sequence

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 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
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


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

Posted by Timothy Kennedy on April 17, 2008 at 07:55 PM IST #

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

Posted by steve norton on April 18, 2008 at 01:00 PM IST #

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.


Posted by Martin Paul on April 22, 2008 at 05:01 AM IST #

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).

Posted by Gerry Haskins on April 23, 2008 at 04:02 AM IST #

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?

Posted by Anthony on April 28, 2008 at 03:37 AM IST #

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.

Posted by Gerry Haskins on April 28, 2008 at 04:04 AM IST #

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.


Posted by T_S_Kimball on May 22, 2008 at 03:48 AM IST #


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.

Posted by Gerry Haskins on May 23, 2008 at 05:52 AM IST #

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.

Posted by Anthony on May 23, 2008 at 10:29 AM IST #

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,


Posted by Gerry Haskins on May 23, 2008 at 11:39 AM IST #

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.

Posted by T_S_Kimball on May 24, 2008 at 05:08 AM IST #

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 :(

Posted by Anthony on May 25, 2008 at 11:38 AM IST #

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).

Posted by C F Patrick on May 30, 2008 at 04:44 PM IST #


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.

Posted by Gerry Haskins on June 06, 2008 at 06:50 AM IST #

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

Posted by Jean-Marc Gillet on June 14, 2008 at 04:19 AM IST #

Thanks Jean-Marc!

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

Posted by Gerry Haskins on June 17, 2008 at 07:41 AM IST #

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.

Posted by Jean-Marc Gillet on November 14, 2008 at 01:43 AM GMT #

Hi Jean-Marc!

The Kernel patch included in Solaris 10 10/08 (Update 6) is 137137-09 (SPARC) / 137138-09 (x86/x64). This fixes the mutex alignment issue (CR 6729759, Sun Alert ) for applications which don't conform to programing best practice of aligning on the largest element of an array / structure.

Posted by Gerry Haskins on November 17, 2008 at 10:27 PM GMT #

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?

Posted by Mike Gerdts on December 08, 2008 at 09:16 AM GMT #

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,


Posted by Gerry Haskins on December 08, 2008 at 10:39 AM GMT #

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

Posted by Harish Maliwal on September 23, 2009 at 10:48 PM IST #

Hi Harish!

Please read the Recommended Patch Cluster README, available from which will guide you through the process.

We've recently done a lot of work on the Solaris 10 Recommended and Sun Alert clusters to improve the install experience. See for further information.

We do recommend using Live Upgrade if possible to install patches. See and for further information.

If you have any issues or questions, please use the Customer Patch Forum and we'll respond. See

Best Wishes,


Posted by Gerry Haskins on September 24, 2009 at 03:42 AM IST #

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?


Posted by Jeff Draht on October 14, 2009 at 12:31 PM IST #

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

Posted by Bilal Baig on October 15, 2009 at 12:53 PM IST #

hi Jeff,

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

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


Posted by Ed on October 15, 2009 at 01:15 PM IST #

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

Posted by Jean-Marc Gillet on February 16, 2010 at 02:35 AM GMT #

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,


Posted by Gerry Haskins on February 24, 2010 at 05:59 AM GMT #

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

Posted by Woo on July 12, 2010 at 01:46 AM IST #

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,


Posted by Gerry Haskins on July 22, 2010 at 11:19 AM IST #

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

Posted by Shaik on September 03, 2010 at 05:03 AM IST #

Hi Shaik,

Apologies for my delay in responding.

Please see the various Sys Admin documentation available on BigAdmin (, and SunSolve (, e.g.

Best Wishes,


Posted by Gerry Haskins on October 12, 2010 at 11:42 AM IST #

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?


Posted by David Delano on October 19, 2010 at 02:36 PM IST #


Kindly provide solution for this below issue ...

The following requested patches will not be installed because
at least one required patch is not installed on this system.

0 For patch 142909-17, required patch 142911-01 does not exist.

Posted by pradeep on November 12, 2010 at 07:19 AM GMT #

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,


Posted by Gerry Haskins on November 18, 2010 at 10:13 AM GMT #

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,


Posted by Gerry Haskins on November 22, 2010 at 10:41 AM GMT #

Will the blog still be available here after Oracle integration completed?
Or there will be another place to provide such information?

Posted by Susan on February 15, 2011 at 01:48 AM GMT #

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,


Posted by Gerry Haskins on February 15, 2011 at 10:44 AM GMT #

144500-xx only - Solaris 10 Update 10 Kernel PatchID
Interesting, I wonder when this patch will be available. I did search and I see no info about it. I was wondering if you know when U10 will be released maybe?

Posted by Chris on April 19, 2011 at 09:35 AM IST #

Hi Chris,

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

Best Wishes,


Posted by Gerry Haskins on April 26, 2011 at 05:01 AM IST #

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

Posted by Jean-Marc Gillet on August 05, 2011 at 02:00 AM IST #

Is this page still being updated?



Posted by Nathan on August 18, 2011 at 10:56 PM IST #

Has Solaris 10 Update 10 been released? Just curious.



Posted by Kenny on August 24, 2011 at 01:10 PM IST #

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?

Posted by guest on August 25, 2011 at 01:41 PM IST #

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,


Posted by Gerry Haskins on September 01, 2011 at 10:06 AM IST #

Great, so 147440-01 was released 10 days ago, and Sol 10 U10 08/11 is available for download on 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

Posted by Chris on September 15, 2011 at 03:33 PM IST #

Hi Chris,

As outlined in (and the links therein), you can patch pre-existing package up to the same software level as an update release. We'll be releasing a Solaris Update Patch Bundle for Solaris 10 8/11 shortly to enable you to do that easily.

However, this is not the same as a full upgrade to Solaris 10 8/11 as it won't provide any additional packages added (or with version up'rev's for Userland stuff) in Solaris 10 8/11.

Please see for an list of such new and up'rev'd packages in Solaris 10 Updates.

Best Wishes,


Posted by Gerry Haskins on September 21, 2011 at 01:08 PM IST #

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

Posted by Marcel Hofstetter on February 20, 2013 at 05:59 PM GMT #

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

Posted by Jean-Marc Gillet on March 04, 2013 at 11:15 AM GMT #

Release 148888-05 at Jun/28.
Please revise a description of "148888-01 to 148888-04"

Posted by guest on July 12, 2013 at 02:31 AM IST #

patch 1488888/148889 is currently up to -05


Posted by guest on July 12, 2013 at 07:30 PM IST #

Thanks Glen,

I've updated the table to reflect this.

Apologies for any inconvenience caused.


Posted by Gerry Haskins on September 10, 2013 at 12:42 PM IST #

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.


Posted by guest on September 24, 2013 at 01:22 PM IST #

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 for details.

Best Wishes,


Posted by guest on November 25, 2013 at 11:18 AM GMT #

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.


Posted by Louis R. on May 02, 2014 at 03:35 AM IST #

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,


Posted by Gerry on July 04, 2014 at 03:43 PM IST #

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
NAME: Solaris Naming Enabler
CATEGORY: system
ARCH: sparc
VERSION: 10,REV=2010.
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.

Posted by guest on January 16, 2015 at 11:05 AM GMT #


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,


Posted by Gerry Haskins on March 25, 2015 at 04:49 PM GMT #

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 ?

Posted by guest on July 01, 2015 at 11:35 AM IST #


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 ( and I can investigate further.

Best Wishes,


Posted by guest on August 24, 2015 at 01:06 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer


« February 2017