<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dennis,<br>
<br>
Let me attempt to address some of the questions you raise below.<br>
<br>
<br>
Dennis Clarke wrote:
<blockquote
cite="mid:56955.10.0.66.17.1326079590.squirrel@interact.purplecow.org"
type="cite">
<pre wrap="">I guess really the question is, can MOS and Oracle be trusted to provide a
kernel patch that won't make things far worse?
</pre>
</blockquote>
I agree that there have been issues with some of the Solaris 10 KUs
that have been released in the past couple of months.<br>
<br>
Some of the more serious of these issues are a result of bad
interactions between Solaris and third party software, while in other
cases the issues lie squarely on Oracle's shoulders.<br>
<br>
The biggest single issue that we have hit in the past couple of months
is that the Solaris 10 Update 10 "Feature" Kernel patch (145900-19)
changed <b>private</b> Solaris interfaces. These changes led to third
party software that used these <b>private</b> Solaris interfaces to
break. <br>
The most common issue that customers reported as a result of this issue
was that systems running EMC PowerPath and Solaris 10 experienced a
system panic if 144500-19 was installed. This is detailed in SunAlert <a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1358671.1">1358671.1</a><br>
EMC have since released a patch for PowerPath to fix this specific
problem. Similar issues have been reported with other third party
multipathing solutions like Hitachi HDS, Falconstor and Dynapath.<br>
<br>
I am not saying that Oracle are blameless in the Kernel patching
issues. For example, there was a change made in patch 147440-04, that
broke systems using a Veritas (VxVM) swap or dump device
volume. As a result patch 147440-04 was withdrawn from MOS and SunAlert
<a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1374089.1">1374089.1</a>
was issued.<br>
<br>
There have been other issues with KU 147440-xx that only affect systems
running very old firmware versions, or other edge cases. Examples of
this are SunAlerts <a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1365975.1">1365975.1</a>,
<a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1359916.1">1359916.1</a>
& <a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1380247.1">1380247.1</a>.<br>
<br>
I agree that there have certainly been more some issues with the KU
patch in the past couple of months than usual, the release of 147440-08
fixed the last major outstanding issue (the VxVM issue detailed in <a
href="https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1374089.1">1374089.1</a>).<br>
<br>
In any case where Oracle know (or are made aware) of a patch issue the
following happens:<br>
- We add a note to the "Special Install Instructions" section of the
patch to warn customers of the issue ASAP.<br>
- If appropriate we will also release a SunAlert to detail "Data Loss"
or "System Availability" issues.<br>
- If the issue is severe we will withdraw a patch.<br>
<br>
If you are looking to assess the likelihood of running into an issue as
a result of installing a patch (particularly the KU) there are a number
of things you can/should do:<br>
<ul>
<li>Read the latest version of README, specifically the "Special
Install Instructions" - eg.
<a class="moz-txt-link-freetext" href="https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08">https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08</a></li>
<li>Look up the patch on the flash version of MOS (if possible)<br>
Personally I'm not a fan of the flash-based MOS, but there are a couple
of really useful features:</li>
<ul>
<li>The "Related Knowledge to this patch" will list any SunAlerts
that contain that patchid. (This means that issues that are either
caused by or fixed in this patch will be detailed here.)</li>
<li>There is a "Community Discussion" on the right of the patch
description. This gives customers the opportunity to provide feedback
on any issues they have experienced with that specific patch. This
feedback flows into the moderated Oracle "<span id="communities-list"
class="communities-list" xmlns="http://www.w3.org/1999/xhtml"
xmlns:pt="http://www.plumtree.com/xmlschemas/ptui/"><a
href="https://communities.oracle.com/portal/server.pt/community/patch_reviews_-_sun/473"
onclick="setCurrentCommunity(this.id)" style="color: red;" id="473"
title="Patch Reviews - SUN">Patch Reviews - SUN<img
src="cid:part1.07090508.08000808@oracle.com"
style="position: absolute; right: -2px; top: 0pt; vertical-align: middle;"
alt=""></a></span>" Community and is also displayed on a per patch
basis in this "Community Discussion" frame.<strong></strong></li>
</ul>
</ul>
<b><font face="helvetica"></font></b>
<blockquote
cite="mid:56955.10.0.66.17.1326079590.squirrel@interact.purplecow.org"
type="cite">
<pre wrap="">
The reason I ask, and would love to hear from others that patch multiple tiers
of servers ( you know, production, testing, development etc etc ), is that I
actually read the kernel patch README's. In the past that seemed to be a good
policy. I could actually see the bugids affected and then determine if it was
reasonable to apply the patch on the test level servers or rush to get it into
the prod level. Patch 147440-09 is less than thrilling.
Here is the bugid list in the README :
6878961 problem with NFS
6927023 need support for AMD family 15h processor
6932919 need support for AMD's family 15h ISA enhancements
7030516 hpet_acpi_init() should be called only if hpet is really required
7047435 'genunix: WARNING: preconfig failed: disk' when configure hard disk driv
e for removal
7105132 deadman panic on a T3-1
Well gee, "problem with NFS" means what exactly? Does it mean that unless you
apply this patch you have a security issue or a pending kernel panic and core
dump? The other bugids apply support for the bulldozer AMD chip and that's a
good thing since HP has been shipping those for a while.
Would be cool to see what this "problem with NFS" is all about. However when I
login to MOS that bugid is not even listed. See image attached. I can see this
bugid :
<a class="moz-txt-link-freetext" href="https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=7047435">https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=7047435</a>
Which is in the README but NOT on the MOS page for this kernel patch.
If I try to see
<a class="moz-txt-link-freetext" href="https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=6878961">https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=6878961</a> I
get a warm and fuzzy "The Bug ID is invalid or you do not have permission to
view the bug". The same goes for bugid 6382683 which is listed on the MOS page
but NOT in the README.
Seriously, can Oracle be trusted or is this a case of "trust us, we know, you
don't, and you don't need to know." Because that really does not fly well
with me.
</pre>
</blockquote>
Ok, so the above discussion is all related to the patch content (i.e.
what's being fixed).<br>
<br>
While I understand your frustration here (and admire your attention to
detail), what you are experiencing is not new under Oracle. This issue
is related to security fixes (though there may be rare cases where
other non-security bugs that are not publicly visible either).<br>
<br>
Before the Oracle acquisition, Sun <b>never</b> published bug reports
for any security issues. <br>
(Back in the old SunSolve days we would release a "HTML" version of a
patch README very similar to
<a class="moz-txt-link-freetext" href="https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08">https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08</a>
that would contain links to bug reports for non-security bugs only.)<br>
<br>
In addition, the Bug description in the README for a patch was (and
still is) reviewed by the security team to ensure that it is not
providing enough information on any security-related issues to hackers
looking to reverse-Engineer security vulnerabilities into potential
attacks. The idea is that you get enough information to decide if you
use the particular technology and if you feel it is appropriate for you
to install the patch. It's far from perfect, but with security issues
we must err on the side of caution.<br>
<br>
For this reason we do not (and never had) made bug reports for security
issues publicly available.<br>
<br>
HTH,<br>
-Don<br>
<br>
<blockquote
cite="mid:56955.10.0.66.17.1326079590.squirrel@interact.purplecow.org"
type="cite">
<pre wrap="">
Dennis
</pre>
<br>
<hr size="4" width="90%"><br>
<center><img src="cid:part2.08010007.03050109@oracle.com"></center>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://www.oracle.com/"> <img
src="cid:part3.02090203.06060207@oracle.com" name="graphics1"
align="bottom" border="0"></a> <br>
<font face="Verdana, sans-serif" size="2"><b>Don O'Malley</b></font><br>
<font color="#666666" face="Verdana, sans-serif" size="2"> Manager,
Patch/Package System Test<br>
Revenue Product Engineering | Solaris | Hardware <br>
East Point Business Park, Dublin 3, Ireland<br>
Phone: +353 1 8199764 <br>
Team Alias: <a href="mailto:rpe_patch_system_test_ww@oracle.com">rpe_patch_system_test_ww@oracle.com</a><br>
</font> </div>
</body>
</html>