Patching Solaris 10

Originally (ca. 8+ years ago), no new features were allowed in Solaris Update releases.

But there was a pressing need to add driver support for new hardware.

So a decision was made to allow new driver support to ship in Solaris Update Releases.

But for Solaris to compete successfully against other Operating Systems, a gap of ca. 2 years between each Solaris Marketing Release was simply too long to wait for cool new software features, especially in fast developing areas such as the Desktop, Identity Management, etc.

So a decision was made to allow new features with a relatively low footprint in pre-existing code (i.e. with a low risk of introducing regressions in pre-existing functionality) to ship in Solaris Update Releases.  This is how Solaris 7, Solaris 8, and Solaris 9 Update Releases worked.

But pressure to release more significant cool feature enhancements such as ZFS, Containers (Zones), NewBoot (GRUB), LDoms (Hardware Vitualization for SPARC), etc., means that the scope of change in Solaris 10 Update releases is far higher than in preceding releases.

This has proved somewhat problematic from a patching perspective given that, as mentioned in my preceding posting, any change to pre-existing code, including feature changes, must be delivered as a patch, and that feature code and bug fix code to the same code area will be delivered in the same patch.

The inter-connectedness of cool new features such as Containers (Zones) and ZFS, and the pervasiveness of features such as NewBoot (GRUB), Trusted Extensions, and Secure By Default, have resulted in some complex Solaris 10 patch relationships and some large Kernel patches.

In particularly, patching a Zones environment on an early release of Solaris 10 can be problematic due to some deficiencies in the original Zones code and in the Solaris patch utilities.

For a customer on an early version of Solaris 10, such as Solaris 10 03/05, Solaris 10 1/06 (Update 1), or Solaris 10 6/06 (Update 2), there is a very significant amount of code change delivered, for example, in the current Kernel patch compared with the original Kernels delivered in these releases.

Patch dependencies, as explained in my earlier posting "Understanding Patches", ensure that the target system is in a consistent state once the patches have been successfully applied to the target system.

But on a Solaris 10 system where the scope of change from the current code level to the latest patch level is very large, the patch utilities struggled to keep the system in a consistent state during patching of a live boot environment.

A number of process and tool improvements, such as Solaris Live Upgrade and Deferred Activation Patching, have been implemented to address these issues which I'll cover in my next postings.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

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

Search

Categories
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today