Solaris 10 Kernel PatchID Sequence
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 http://sunsolve.sun.com/search/document.do?assetkey=1-9-86481-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: 36 out of 41 = 88% (from February 2007 to current [May 8th, 2009])
x86: 39 out of 41 = 95% (from February 2007 to current [May 8th, 2009])
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 |
| 142909-xx only |
Solaris 10 Update 9 Kernel PatchID |
142910-xx only |
| 142900-01 to 142900-xx |
Sustaining Bug Fixes |
142901-01 to 142901-xx |
| 141444-09 only |
Solaris 10 10/09 (Update 8) Kernel PatchID | 141445-09 only |
| 141414-01 to 141414-10 |
Sustaining Bug Fixes |
141415-01 to 141415-10 |
| 139555-08 only |
Solaris 10 5/09 (Update 7) Kernel PatchID | 139556-08 only |
| 138888-01 to 138888-08 |
Sustaining Bug Fixes |
138889-01 to 138889-08 |
| 137137-09 only |
Solaris 10 10/08 (Update 6) Kernel PatchID |
137138-09 only |
| 137111-01 to 137111-08 |
Sustaining Bug Fixes |
137112-01 to 137112-08 |
| 127127-11 only |
Solaris 10 5/08 (Update 5) Kernel PatchID |
127128-11 only |
| 127111-01 to 127111-11 |
Sustaining Bug Fixes |
127112-01 to 127112-11 |
| 120011-14 only |
Solaris 10 8/07 (Update 4) Kernel PatchID |
120012-14 only |
| 125100-04 to 125100-10 |
Sustaining Bug Fixes |
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 18, 2008 at 02:55 AM 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 08: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
PatchIDs.
.. 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.
mp.
Posted by Martin Paul on April 22, 2008 at 12:01 PM 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 11: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 10: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 11: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.
--TSK
Posted by T_S_Kimball on May 22, 2008 at 10:48 AM IST #
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.
Posted by Gerry Haskins on May 23, 2008 at 12:52 PM 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 05:29 PM 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,
Gerry.
Posted by Gerry Haskins on May 23, 2008 at 06:39 PM 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.
--Tim
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 12:08 PM 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 06:38 PM 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 11:44 PM IST #
Hi!
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 01:50 PM 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 11: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 02:41 PM 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 09: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 http://sunsolve.sun.com/search/document.do?assetkey=1-66-244606-1 ) 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 18, 2008 at 06:27 AM 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 05:16 PM 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,
Gerry.
Posted by Gerry Haskins on December 08, 2008 at 06:39 PM 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.
Regards
Harish Maliwal
harish.maliwal@yahoo.com
Posted by Harish Maliwal on September 24, 2009 at 05:48 AM IST #
Hi Harish!
Please read the Recommended Patch Cluster README, available from http://sunsolve.sun.com/show.do?target=patches/patch-access 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 http://blogs.sun.com/patch/entry/improvements_to_solaris_10_recommended for further information.
We do recommend using Live Upgrade if possible to install patches. See http://blogs.sun.com/patch/entry/solaris_10_live_upgrade_patch and http://blogs.sun.com/patch/entry/turbo_packaging_patches_now_available for further information.
If you have any issues or questions, please use the Customer Patch Forum and we'll respond. See http://blogs.sun.com/patch/entry/patch_forums_now_available_for
Best Wishes,
Gerry.
Posted by Gerry Haskins on September 24, 2009 at 10: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?
Jeff
Posted by Jeff Draht on October 14, 2009 at 07: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 07:53 PM IST #
hi Jeff,
to install a patch cluster from a jumpstart finish script, use
<path-to-cluster>/installcluster --s10cluster -R /a
best,
Ed
Posted by Ed on October 15, 2009 at 08:15 PM IST #