PatchPro screwed up again?
Hmmm, wondering whether PatchPro or the Service at all is broken again. Using S10 06/06 - last succesfull applied patches last week, which included AFAIK the 1.0.8 patches:
elkner.hathor ~ > setenv LC_ALL C
elkner.hathor ~ > + smpatch download
Update 123252-01 will not be downloaded since it already exists in the download directory.
The following patches were not downloaded:
119252-13: Unknown HTTP status code returned.
123494-02: Unknown HTTP status code returned.
118833-24: Unknown HTTP status code returned.
122027-08: Unknown HTTP status code returned.
122761-01: Unknown HTTP status code returned.
123003-02: Unknown HTTP status code returned.
122212-10: Unknown HTTP status code returned.
119280-07: Unknown HTTP status code returned.
119059-18: Unknown HTTP status code returned.
41.31u 5.20s 1:37.94 47.4%
elkner.hathor ~ > + smpatch analyze
119252-13 SunOS 5.10: System Administration Applications Patch
123494-02 X11 6.6.2: fontconfig patch
118833-24 SunOS 5.10: kernel patch
123252-01 SunOS 5.10: platform/SUNW,Netra-T2000 patch
122027-08 SunOS 5.10: bge Driver Patch
122761-01 SunOS 5.10: Sun Update Connection Bootstrapper
123003-02 SunOS 5.10: dependency issue with SUNWopenssl-include
122212-10 GNOME 2.6.0: GNOME Desktop Patch
119280-07 CDE 1.6: Runtime library patch for Solaris 10
119059-18 X11 6.6.2: Xsun patch
44.11u 3.45s 0:35.74 133.0%
[1535 byte] By [
elkner] at [2007-11-26 10:31:04]
# 1
I am having all sorts of issues as well. I'm fairly new to Sun Update Connection, so do you know if these problems are common?
# 2
All,
Do you happen to use a SunUC proxy server? Can you post the output of the following commands -
# smpatch get
# patchsvr setup -l
SPARC:
# showrev -p | egrep -e '121453|121118|120335|121081|121563|122231|119788'
X86:
# showrev -p | egrep -e '121454|121119|120336|121082|121564|122232|119789'
# 3
elkner.hathor ~ > smpatch get
patchpro.backout.directory-""
patchpro.baseline.directory-/var/sadm/spool
patchpro.download.directory-/var/sadm/spool
patchpro.install.types -rebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://patches:3816/solarishttps://getupdates1.sun.com/
patchpro.patchset-current
patchpro.proxy.host -""
patchpro.proxy.passwd********
patchpro.proxy.port -8080
patchpro.proxy.user -""
elkner.hathor ~ > + patchsvr setup -l
Patch source URL: https://getupdates1.sun.com/
Cache Location: /pool1/patchsvr
Web proxy host name:
Web proxy port number: 8080
Web proxy user:
elkner.hathor ~ > showrev -p | egrep -e '121453|121118|120335|121081|121563|122231|119788'
Patch: 121453-02 Obsoletes: 120776-03, 121086-02, 119107-07 Requires: 119574-02, 119254-06 Incompatibles: Packages: SUNWcsu, SUNWcsr, SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcctpx, SUNWccinv, SUNWcsmauth, SUNWppror, SUNWpprou, SUNWswupcl, SUNWppro-plugin-sunos-base
Patch: 121081-05 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWccccrr, SUNWccccr, SUNWccfw, SUNWccsign, SUNWcctpx, SUNWccinv
Patch: 122231-01 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWcctpx
Patch: 121118-06 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWppro-plugin-sunos-base
Patch: 121118-08 Obsoletes: Requires: 121453-02 Incompatibles: Packages: SUNWppror, SUNWpprou, SUNWppro-plugin-sunos-base
Patch: 119788-02 Obsoletes: Requires: 119107-02 Incompatibles: Packages: SUNWppror, SUNWpprou
Patch: 120335-04 Obsoletes: Requires: 121453-01 Incompatibles: Packages: SUNWpprou
# 4
Has the patch server itself been updated? I assume the output below is from the client machine and not the SunUC proxy istelf since it's configured to go to http://patches:3816/solaris to retrieve updates? If so can you post the same output from the SunUIC proxy server?
# 5
Yes: hathor is the patchsrv. patches is just a CNAME for hathor, so that we do not need to update NNN clients, when we update the server or move it to another machine...
# 6
Hi again.Could you run smpatch downoad in debug mode, and post the output:# smpatch download -C patchpro.log.level=3 -C patchpro.debug=true
# 7
elkner.hathor ~ > + smpatch download -C patchpro.log.level=3 -C patchpro.debug=true
Effective proxy host : ""
Effective proxy port : "8080"
Effective proxy user : ""
Effective proxy host : ""
Effective proxy port : "8080"
Effective proxy user : ""
... Submitting download request against a Non-GUUS server
Key 1 : Content-Type = application/octet-stream
Key 2 : Date = Wed, 04 Oct 2006 16:27:05 GMT
Key 3 : Server = Apache Tomcat/4.0.5 (HTTP/1.1 Connector)
Key 4 : Transfer-Encoding = chunked
Key 5 : PatchProServletCompletionCode = 0
Effective proxy host : ""
Effective proxy port : "8080"
Effective proxy user : ""
Effective proxy host : ""
Effective proxy port : "8080"
Effective proxy user : ""
... Submitting download request against a Non-GUUS server
Key 1 : Content-Type = application/octet-stream
Key 2 : Date = Wed, 04 Oct 2006 16:27:37 GMT
Key 3 : Server = Apache Tomcat/4.0.5 (HTTP/1.1 Connector)
Key 4 : Transfer-Encoding = chunked
Key 5 : PatchProServletCompletionCode = 0
Effective proxy host : ""
Effective proxy port : "8080"
Effective proxy user : ""
Update 123252-01 will not be downloaded since it already exists in the download directory.
... Submitting download request against a Non-GUUS server
The following patches were not downloaded:
119252-13: Unknown HTTP status code returned.
123494-02: Unknown HTTP status code returned.
118833-24: Unknown HTTP status code returned.
122027-08: Unknown HTTP status code returned.
122761-01: Unknown HTTP status code returned.
123003-02: Unknown HTTP status code returned.
122212-10: Unknown HTTP status code returned.
119280-07: Unknown HTTP status code returned.
119059-18: Unknown HTTP status code returned.
83.02u 8.46s 1:40.12 91.3%
# 8
Not sure, whether these log entries come from the server or client, however it might be a hint for something:
Oct 4 18:28:38 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=java.net.SocketTimeoutException: Read timed out
Oct 4 18:28:38 hathor at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Oct 4 18:28:38 hathor at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)
Oct 4 18:28:38 hathor at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)
Oct 4 18:28:38 hathor at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
Oct 4 18:28:38 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1205)
Oct 4 18:28:38 hathor at java.security.AccessController.doPrivileged(Native Method)
Oct 4 18:28:38 hathor at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnecti on.java:1199)
Oct 4 18:28:38 hathor at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.ja va:888)
Oct 4 18:28:38 hathor at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at java.net.HttpURLConnection.getResponseMessage(HttpURLConnection.java:433)
Oct 4 18:28:39 hathor at com.sun.patchpro.util.Downloader.connectToURL(Downloader.java:472)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.sendPatchDownloadPostRequest (ServerPatchServiceProvider.java:3452)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.requestDownload(ServerPatchS erviceProvider.java:2108)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.performDownloadPatches(Serve rPatchServiceProvider.java:1731)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at com.sun.patchpro.server.ServerPatchServiceProvider.downloadPatches(ServerPatchS erviceProvider.java:1459)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.PatchServerProxy.downloadPatches(PatchServerProxy.java: 279)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.GroupPatchDownloader.downloadPatches(GroupPatchDownload er.java:124)
Oct 4 18:28:39 hathor at com.sun.patchpro.model.PatchProModel.performPatchDownload(PatchProModel.java:19 36)
Oct 4 18:28:39 hathor at com.sun.patchpro.model.PatchProStateMachine$10.run(PatchProStateMachine.java:52 6)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at com.sun.patchpro.util.State.run(State.java:266)
Oct 4 18:28:39 hathor at java.lang.Thread.run(Thread.java:595)
Oct 4 18:28:39 hathor Caused by: java.net.SocketTimeoutException: Read timed out
Oct 4 18:28:39 hathor at java.net.SocketInputStream.socketRead0(Native Method)Oct 4 18:28:39 hathor at java.net.SocketInputStream.read(SocketInputStream.java:129)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
Oct 4 18:28:39 hathor at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
Oct 4 18:28:39 hathor at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
Oct 4 18:28:39 hathor at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:606)
Oct 4 18:28:39 hathor at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:554)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=nullat sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.ja va:939)
Oct 4 18:28:39 hathor at com.sun.patchpro.util.Downloader.connectToURL(Downloader.java:468)
Oct 4 18:28:39 hathor ... 10 more
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=Caused by:
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=java.net.SocketTimeoutException: Read timed out
Oct 4 18:28:39 hathor at java.net.SocketInputStream.socketRead0(Native Method)Oct 4 18:28:39 hathor at java.net.SocketInputStream.read(SocketInputStream.java:129)
Oct 4 18:28:39 hathor at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
Oct 4 18:28:39 hathor at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
Oct 4 18:28:39 hathor at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:606)
Oct 4 18:28:39 hathor at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:554)
Oct 4 18:28:39 hathor at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.ja va:939)
Oct 4 18:28:39 hathor at com.sun.patchpro.util.Downloader.connectToURL(Downloader.java:468)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at com.sun.patchpro.server.ServerPatchServiceProvider.sendPatchDownloadPostRequest (ServerPatchServiceProvider.java:3452)Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.requestDownload(ServerPatchS erviceProvider.java:2108)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.performDownloadPatches(Serve rPatchServiceProvider.java:1731)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.ServerPatchServiceProvider.downloadPatches(ServerPatchS erviceProvider.java:1459)
Oct 4 18:28:39 hathor at com.sun.patchpro.server.PatchServerProxy.downloadPatches(PatchServerProxy.java: 279)
Oct 4 18:28:39 hathor root: [ID 702911 user.crit] => com.sun.patchpro.server.ServerPatchServiceProvider@136bdda <=at com.sun.patchpro.server.GroupPatchDownloader.downloadPatches(GroupPatchDownload er.java:124)
Oct 4 18:28:39 hathor at com.sun.patchpro.model.PatchProModel.performPatchDownload(PatchProModel.java:19 36)
Oct 4 18:28:39 hathor at com.sun.patchpro.model.PatchProStateMachine$10.run(PatchProStateMachine.java:52 6)
Oct 4 18:28:39 hathor at com.sun.patchpro.util.State.run(State.java:266)
Oct 4 18:28:39 hathor at java.lang.Thread.run(Thread.java:595)
Oct 4 18:28:39 hathor root: [ID 702911 user.error] => com.sun.patchpro.util.Downloader@268cc6 <=Downloader.getResponseCode() : IOExceptionRead timed out
# 9
Hi.
the messages are from host 'hathor' (which looks like the client). It seems that the connection to the patch server is timing out.
Could you try telnet'ing to 'patches':
# telnet patches 3816
and see if you are able to connect?
Also, could you post the output from:
# ps -ef | egrep 'patch|svr|swup'
from the patch server?
# 10
elkner.hathor ~ > telnet patches 3816
Trying 141.44.24.1...
Connected to hathor.iws.cs.uni-magdeburg.de.
Escape character is '^]'.
bla
^]
telnet> close
Connection to hathor.... closed.
elkner.hathor ~ > ps -ef | egrep 'patch|svr|swup'
root 1636 15800 02:14:55 pts/20:00 tail -f /var/patchsvr/logs/catalina.out
elkner 1742 16850 02:17:16 pts/30:00 egrep patch|svr|swup
elkner.hathor ~ > + tail -f /var/patchsvr/logs/catalina.out
Stopping service Tomcat-Standalone
Starting service Tomcat-Standalone
Apache Tomcat/4.0.5
119252-13 cannot be validated.
123494-02 cannot be validated.
118833-24 cannot be validated.
122027-08 cannot be validated.
122761-01 cannot be validated.
123003-02 cannot be validated.
122212-10 cannot be validated.
119280-07 cannot be validated.
119059-18 cannot be validated.
119252-13 cannot be validated.
123494-02 cannot be validated.
118833-24 cannot be validated.
122027-08 cannot be validated.
122761-01 cannot be validated.
123003-02 cannot be validated.
122212-10 cannot be validated.
119280-07 cannot be validated.
119059-18 cannot be validated.
# 11
The problem is that Sun has switched over to use a new signing certificate, but LPS is still looking at the old certificate. We are currently working on a formally released fix for this problem.
In the meantime, there is a simple workaround which you can implement on the LPS server:
1. Make sure that you have installed the SWUP 1.0.8 Client update on the LPS. That would be update 121118-08 (SPARC) or 121119-08 (x86).
2. Edit /var/patchsvr/solaris/WEB-INF/web.xml using your favorite text editor by changing the "patchsvr.security.patch.signingcert" parameter value from "patchsigning" to "patchsigning:patchsigning2". That should end up looking like:
<init-param>
<param-name>patchsvr.security.patch.signingcert</param-name>
<param-value>patchsigning:patchsigning2</param-value>
</init-param>
3. Restart the LPS by running:
# patchsvr stop
# patchsvr start
as root.
Following those steps should remedy your problems. Clients not using LPS will not encounter this problem as it was resolved as part of the 1.0.8 update.
# 12
Yes, that seems to work. However, the patch utilities or patches itself still seemed to be none-functional:
elkner.hathor ~ > + smpatch analyze
119252-14 SunOS 5.10: System Administration Applications Patch
124327-01 SunOS 5.10: libpcp patch
123252-01 SunOS 5.10: platform/SUNW,Netra-T2000 patch
120185-08 StarOffice 8 (Solaris): Update 4
119280-08 CDE 1.6: Runtime library patch for Solaris 10
119278-12 CDE 1.6: dtlogin patch
40.99u 3.27s 0:33.56 131.8%
elkner.hathor ~ > + smpatch update
Update 119252-14 will not be downloaded since it already exists in the download directory.
Update 124327-01 will not be downloaded since it already exists in the download directory.
Update 123252-01 will not be downloaded since it already exists in the download directory.
Update 120185-08 will not be downloaded since it already exists in the download directory.
Update 119280-08 will not be downloaded since it already exists in the download directory.
Update 119278-12 will not be downloaded since it already exists in the download directory.
Installing patches from /var/sadm/spool...
CRITICAL: The patch 119252-14 makes the kernel unstable, is obsolete or is forbidden by policy.
Failed to install patch 124327-01.
Utility used to install the update failed with exit code 8.
Checking installed patches...Patchadd is terminating.
Transition old-style patching.
Failed to install patch 124327-01.
ALERT: Failed to install patch 124327-01.
Failed to install patch 123252-01.
Utility used to install the update failed with exit code 8.
Checking installed patches...Patchadd is terminating.
Transition old-style patching.
Failed to install patch 123252-01.
ALERT: Failed to install patch 123252-01.
CRITICAL: The patch 120185-08 makes the kernel unstable, is obsolete or is forbidden by policy.
CRITICAL: The patch 119280-08 makes the kernel unstable, is obsolete or is forbidden by policy.
/var/sadm/spool/patchpro_dnld_2006.10.16@21:54:40:MEST.txt has been moved to /var/sadm/spool/patchproSequester/patchpro_dnld_2006.10.16@21:54:40:MEST.txt
ID's of the updates that are disallowed by installation policy have been
written to file
/var/sadm/spool/disallowed_patch_list
One or more updates that you installed requires a system shutdown to activate it. To initiate the system shutdown, you must use one of the following commands:
o Drop to the firmware prompt - init 0 or shutdown -i 0
o Power down the system - init 5 or shutdown -i 5
o Restart the system - init 6 or shutdown -i 6
43.93u 6.41s 0:43.83 114.8%
elkner.hathor ~ >
So it tells me, patches need to be installed, however later it says, they can't be installed. What a crap is this? Also why should one reboot, even if no patch was installed at all?
# 13
It installs a lot of the patches during the shutdown process.So thats why it wants a reboot, so it can do the installs.
# 15
Well, people can tell you the answer the answer forever.
But if you won't believe them, you'll never learn anything.
I can only repeat what I said.
update connection divides patches into 2 classes.
Patches its safe to install now.
And "single user" patches that need to be installed during the shutdown process.
Prior to SUC 1.0.8 this process was handled by the shutdown script /etc/rc0.d/K51installupdates
But in 1.0.8 this was converted to a smf facility.
Now when you do a "smpatch update" it installs the safe patches immediately.
But defers the "single user" patches.
After the smpatch update you can see what patches it will install during the shutdown by
cat /var/sadm/spool/disallowed_patch_list
Which is pretty much what the output from smpatch told you.
Now, it may be that in this particular case, that there was a bug in smpatch and the disallowed_patch_list was empty.
In which case, a reboot wouldnt have been necessary.
And the message was incorrect.
However you'll notice in the smpatch output, it didnt say it had tried to install patch 119278-12.
So it might have been delaying it for the restart.
But normally in that case, it gives a message about can't install the patch at this time.
Which I don't see in that output.
So its not entirely clear whats going on here.
But in any case, in general thats why "smpatch update" produces the message about needing to reboot.
Not to activate the patches it has installed, but to give it the opportunity to install the "unsafe" patches.
Now perhaps you'll be kind enough to explain why what I said previously was nonsense.
So I can learn from your obviously superior wisdom.
# 16
Because you did not read the posting! Nowhere is mentioned a phrase like "Patch XXXX cannot be installed until the next system shutdown" ...
Just in case you still did not catch it: e.g. Patch 120185-08 StarOffice 8 update4 - it is pretty obvious, that smpatch or the patch itself emits bogus information/are bogus. Why should a StarOffice patch make the kernel unstable or should be obsolete (patch analyze actually suggested this patch to be installed) or should be forbidden by policy (reboot or anything else is not required by this patch) .... ?
And BTW, yes, if one manually extracts the patch and adds it with the usual patchadd command, it gets applied without any stupid messages/rejections ...
So hell, at the moment it seems, that any linux system has a better patch management than Solaris. Next time, when any Sun representive will start to talk about TCOs with me, I've to tell him a completely different story ...
I've the feeling, that Solaris is now at the point, where SGI was about 1995... So if its quality/desktop support stays this way, I guess, in 10 years the only field, where Solaris plays a role is theory.
# 17
> So hell, at the moment it seems, that any linux
> system has a better patch management than Solaris.
Just like under Linux, you can always look at
alternatives under Solaris, too. And there is an
alternative patch tool for Solaris - take a look
at PCA: http://www.par.univie.ac.at/solaris/pca/
> I've the feeling, that Solaris is now at the point,
> where SGI was about 1995...
While I agree that the Sun provided patch tools
are (and were) lacking, this definitely doesn't
apply to Solaris itself. It's way ahead of other
OS in many regards; just think ZFS, Zones, dtrace,
SunRay, and the fact that it runs on everything from
desktops to big iron.
mp.
# 18
Solaris patching has been driving me to distraction for weeks. The update manager frequently hangs for no reason part way through, the smpatch update does the same. For some reason not bothering for a couple of days and trying again and everything suddenly works fine for the odd time! The smpatch utilitity is now giving me constant errors about being unable to verify the digital signatures.
When using the updatemanager after it updated itself it now claims it can't load the default update list so that is now useless.
com.sun.swup.client.engine.solaris.CollectionFileException: Error: Unable to download document : "collection/default"
collection/default: not found at https://getupdates.sun.com/solaris/
at com.sun.swup.client.engine.solaris.PatchCollection.processCollections(PatchCollection.java:91)
at com.sun.swup.client.engine.solaris.PatchCollection.<init>(PatchCollection.java:53)
at com.sun.swup.client.engine.solaris.PatchCollection.getInstance(PatchCollection.java:70)
at com.sun.swup.client.engine.solaris.SolarisDataCollector.getCollectionsObject(SolarisDataCollector.java:392)
at com.sun.swup.client.engine.solaris.SolarisDataCollector.getAvailableCollectionNames(SolarisDataCollector.java:279)
at com.sun.swup.client.engine.solaris.SolarisDataCollector.getAvailableUpdateCollections(SolarisDataCollector.java:158)
at com.sun.swup.client.ui.UpdateFrame$LoadDataWorker.construct(UpdateFrame.java:234)
at com.sun.swup.client.ui.foundation.swing.SwingWorker$2.run(SwingWorker.java:109)
at java.lang.Thread.run(Thread.java:595)
Exception in thread "Thread-8" java.lang.NullPointerException
at com.sun.cns.basicreg.advertisement.SystemAdvertisement.collectSISerialNumber(SystemAdvertisement.java:2253)
at com.sun.cns.basicreg.advertisement.SystemAdvertisement.initNodeCollectionData(SystemAdvertisement.java:3151)
at com.sun.cns.basicreg.advertisement.SystemAdvertisement.<init>(SystemAdvertisement.java:285)
at com.sun.cns.basicreg.advertisement.SystemAdvertisement.getInstance(SystemAdvertisement.java:291)
at com.sun.cns.basicreg.BasicReg$LoadTask.<init>(BasicReg.java:626)
at com.sun.cns.basicreg.BasicReg$1.construct(BasicReg.java:482)
at com.sun.cns.basicreg.wizard.swing.SwingWorker$2.run(SwingWorker.java:126)
at java.lang.Thread.run(Thread.java:595)
I tried downloading the new update software - I got a cgi error. The email to the webmaster which it said to use then bounced!
smpatch update isn't working with the digital signatures errors that others seem to have so that's out.
Yum update on linux just works, I'd like the same usability and reliability from sun update. Yum only occasionally gets itself in a knot when mirrors aren't available but consider the abuse I give it ( usually go from one fedora release to another by cheating) it does a good job and it is a painless way to do things.
# 19
> Just like under Linux, you can always look at
> alternatives under Solaris, too. And there is an
> alternative patch tool for Solaris - take a look
> at PCA: http://www.par.univie.ac.at/solaris/pca/
Yes, heard about it, but the problem is: Call the support and than they tell you: Ooooh, its not supported by SUN so you need to reinstall the machine and than we can continue to handle the problem. Yes, sometimes I think, 2nd level support is kidding SUN customers. The only phrase I'm still missing when talking with those "engineers" is "welcome at MIcrosoft" ...
> I've the feeling, that Solaris is now at the point,
> where SGI was about 1995...
>
> While I agree that the Sun provided patch tools
> are (and were) lacking, this definitely doesn't
> apply to Solaris itself. It's way ahead of other
> OS in many regards; just think ZFS, Zones, dtrace,
> SunRay, and the fact that it runs on everything from
> desktops to big iron.
Yes, there is some innovative stuff underway, and at least for simple scenarios it works. But don't mention desktop at all - even with 06/06 you get pretty ancient and bogus software (e.g. GNOME/Java desktop). So no wonder, why about 99% of all CS students (some people call them the decision maker from tomorrow) choose to work with linux or windooze rather than solaris. And BTW: If you have a problem, you even need to explain the 2nd level support enginner, e.g. what gnome-panel is and what it does - Hello, if he has no clue (since still working with its CDE from anno dunnemal), how should he be able to tackle a problem [efficiently|at all]?
# 20
> Yes, heard about it, but the problem is: Call the
> support and than they tell you: Ooooh, its not
> supported by SUN so you need to reinstall the machine
> and than we can continue to handle the problem.
Usually you get better support from those engineers
hanging out in Usenet and Solaris Forums. You're
right, communicating a problem to Sun Support is
often cumbersome.
Back to patches, though, the only question you might
be asked by support is whether you have a certain or
all current patches installed. No matter whether you
installed them manually, with PCA or Update Manager
you can answer this with yes. At the end, all of them
use the *one* method to install patches -patchadd.
There's no chance to distinguish from Sun Explorer
output (which is often requested by Sun Support) how
a patch is installed, only *if* it is installed. And that's
correct, because at the end there is no difference.
mp.
# 21
elkner,
Regarding the 'CRITICAL: The patch <patch-id> makes the kernel unstable, is obsolete or is forbidden by policy.' errors, there is a bug open to have the metadata of these patches looked at, so this issue should go away once this bug is closed. Bug ID 6482941
Moderator
P.S. I'm not sure who you were speaking to when you called Sun Update support, but all of the Tier 2 team are running Java desktop on Solaris 9 and 10 SunRays, and so are all quite familiar with gnome-panel
# 22
> Regarding the 'CRITICAL: The patch <patch-id> makes
> the kernel unstable, is obsolete or is forbidden by
> policy.' errors, there is a bug open to have the
> metadata of these patches looked at, so this issue
> should go away once this bug is closed. Bug ID
> 6482941
Ahh ok, hopefully soon.
> P.S. I'm not sure who you were speaking to when you
> called Sun Update support,
Just in case you have access to EMEA service requests: have a look at 37686783
> but all of the Tier 2 team
> are running Java desktop on Solaris 9 and 10 SunRays,
> and so are all quite familiar with gnome-panel
May be its a little bit different in US. But the "engineer" of the mentioned case above really asked me, what gnome-panel is, what it does and that he really likes his CDE (yes, the first time, when I was close to a heart attack). And well, just checked the link for case and found out, that this guy closed the case without any notice (heart attack 2)! This is unbelievable! Well, it's to late to stall my last order ( ~ 50K US$) from the last week, but I think, the creeping started phase-out of our SUN-Pools just got accellerated tremendously. OK, probably need to make some calls tomorrow - I'm really p...
# 23
Kim here, sticking in my oar.
Having the same problem here. We have one server with internet access and with the latest set of updates, we have got to the point where only a direct connection from smpatch works.
After 2 years of trying to get the update manager et. al. to work consistently, we are now at the point of having it broken because no attention was paid to the entire update cycle.
Is there one definitive statement of what the settings should be for patchsvr and smpatch, along with the patch to the web.xml file? If so, could you point me to it, as I am getting consistent "This patch could not be found", along with other spurious errors such as "unstable ..." etc.
I am also worried by the fact that smpatch always tries to install some T2000 Netra patches onto a Sun Blade 100 - Sun4v arch instead of Sun4u.
(123252-01 SunOS 5.10: platform/SUNW,Netra-T2000 patch)
# 24
>Is there one definitive statement of what the settings should be for patchsvr and smpatch,
>along with the patch to the web.xml file? If so, could you point me to it, as I am getting
>consistent "This patch could not be found", along with other spurious errors such as
>"unstable ..." etc.
This issue is related to Bug ID 6482941 as mentioned above. If you or any other customer are concerned by this we would advise you to raise a support case so that we can investigate the issues fully.
>I am also worried by the fact that smpatch always tries to install some T2000 Netra
>patches onto a Sun Blade 100 - Sun4v arch instead of Sun4u.
>(123252-01 SunOS 5.10: platform/SUNW,Netra-T2000 patch)
This issue is caused by bad meta data in the patch files, for which there is a bug already open for. In the near future there will be a feature that will allow you to ignore individual updates to prevent them from being listed as available should a meta data issue such as this arise again.
Even with incorrect meta data, the patch will not be installed on incorrect platforms, however until the new release we will have to put up with the inconvenience of having the 'rogue' patches displayed in the list of available updates.
# 25
"This issue is related to Bug ID 6482941 "
I get a " Your search - 6482941 - did not match any documents on the Support - Knowledgebase tab. " when searching for this on SunSolve.
So:- I have no idea where to point the patchsvr to get updates - by default the patchsvr points to https://getupdates.sun.com/solaris, and according to some documentation we should point to https://getupdates1.sun.com/solaris, or is it supposed to be https://getupdates1.sun.com/ ?
Any thoughts as to which I should use, i.e. which would have the best chance of success?
As for the annoyance of having the sun4v patches in the list, this has been happening for at least a couple of months now - I have learned to ignore it, and hope the situation was going to get better, not worse.
# 26
> "This issue is related to Bug ID 6482941 "
> I get a " Your search - 6482941 - did not match any documents on the Support -
> Knowledgebase tab. " when searching for this on SunSolve.
This bug is listed as internal only, but is currently being worked on.
> So:- I have no idea where to point the patchsvr to get updates - by default the patchsvr
> points to https://getupdates.sun.com/solaris, and according to some documentation we
> should point to https://getupdates1.sun.com/solaris, or is it supposed to be
> https://getupdates1.sun.com/ ?
>
> Any thoughts as to which I should use, i.e. which would have the best chance of
> success?
Please use https://getupdates1.sun.com/solaris/ as it holds the most recent certificates
