Kernel patch 118833-36 fails to install on Ultra-80 (06/2006 version)

Kernel patch 118833-36 fails to install on an Ultra-80. This patch has been applied to a Sun Blade 100.

The release for the Ultra-80 is Solaris 10 (06/2006). This host is patched very often. The patch was previously downloaded and extracted. The patch was applied by downing it to level 0 and then booting it to single-user. The patch would not install under that mode.Let me know if anyone wants the log "/var/sadm/patch/118833-36/log".

The existing kernel patch level for the Ultra-80 is 118833-24.

[519 byte] By [j.k.harrisona] at [2007-11-26 16:51:13]
# 1
If you could provide the log, the command issued and the error message that was output to screen, that would be helpful indeed.
ForumModeratora at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 2

The log is:

Package not patched:

PKG=SUNWcakr.us

Original package not installed.

Package not patched:

PKG=SUNWcakr.v

Original package not installed.

Package not patched:

PKG=SUNWcart200.v

Original package not installed.

Package not patched:

PKG=SUNWdrr.us

Original package not installed.

Package not patched:

PKG=SUNWefc.us

Original package not installed.

Package not patched:

PKG=SUNWkvm.us

Original package not installed.

Package not patched:

PKG=SUNWkvm.v

Original package not installed.

Package not patched:

PKG=SUNWkvmt200.v

Original package not installed.

Package not patched:

PKG=SUNWust1.v

Original package not installed.

pkgadd: ERROR: The -G option (install packages in the global zone only)

may not be used with package <SUNWcsr> because the package must be

installed in all zones.

pkgadd: ERROR: package <SUNWcsr> cannot be installed on this system/zone

This appears to be an attempt to install the same architecture and

version of a package which is already installed. This installation

will attempt to overwrite this package.

Dryrun complete.

No changes were made to the system.

... (It repeats the attempt tries many times)

j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 3

For single-user support, I cannot snap the results.

I did run "patchadd 118833-36" in true single-user mode.

I quickly get complaints about these three packages not being present

SUNWcart200

SUNWvmt200

SUNWustl

It still goes on to say that it will run and it initiates the "prepatch" step. I see the message "Disabling kernel module unloading".

It still aborts with the message "Patch 118833-36 failed to install due to a failure produced by pkgadd". In the log file, there might be about 100+ entries saying it did dry runs on already existant code. I am paraphrasing here. See the original log listing. It is the same.

j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 4
HiWould you please provide us with the output of the following two commands :# cat /etc/release# showrev -p | grep 118833Thank you.Mod.
ForumModeratora at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 5

As far as patches for 118833, I see patches:

118833-17

118833-24

as being applied. I didn't list the other places where patches wanted 118833-xx versions.

As far as the release, I see:

Solaris 10 6/06 s10s_u2wos_09a SPARC

. . .

Assembled 09 June 2006

j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 6
HiWe have found that omitting the "-G" option should allow this patch to be installed successfully.If you would let us know you experience thank you.Mod.
ForumModeratora at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 7
I did omit the "-G" syntax. I never specify options. I will also add that we will never run zones on this host.In single-user mode, I always ran "pkgadd 118833-36". Please advise what to do next. We do have a software support contract so an incident could be opened for this.
j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 8
I want to correct my last statement. I ran "patchadd" instead of "pkgadd".
j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 9
Hi again,Could you make sure the latest patch tools patch is installed:119254-34and if patchadd continues to fail, I think raising a case on this issue may be prudent.Mod.
ForumModeratora at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 10
I had that patch. I will open up a separate Sun incident. Thank you.
j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 11

I've been experiencing similar problems with this patch (and the related x86 patch). I've been testing it on non-production systems and it seems pretty hit and miss (mostly miss) if I can get the systems patched.For example, this is the log from a SunBlade 2500 (silver) that I just tried to install the patch on:

Package not patched:

PKG=FJSVhea

Original package not installed.

Package not patched:

PKG=FJSVmdb

Original package not installed.

Package not patched:

PKG=FJSVmdbr

Original package not installed.

Package not patched:

PKG=FJSVpiclu

Original package not installed.

Package not patched:

PKG=SUNWcakr.us

Original package not installed.

Package not patched:

PKG=SUNWcakr.v

Original package not installed.

Package not patched:

PKG=SUNWcart200.v

Original package not installed.

Package not patched:

PKG=SUNWcti2.u

Original package not installed.

Package not patched:

PKG=SUNWcvcr.u

Original package not installed.

Package not patched:

PKG=SUNWdcsr

Original package not installed.

Package not patched:

PKG=SUNWdcsu

Original package not installed.

Package not patched:

PKG=SUNWdrcr.u

Original package not installed.

Package not patched:

PKG=SUNWdrr.u

Original package not installed.

Package not patched:

PKG=SUNWdrr.us

Original package not installed.

Package not patched:

PKG=SUNWefc.u

Original package not installed.

Package not patched:

PKG=SUNWefc.us

Original package not installed.

Package not patched:

PKG=SUNWefcl

Original package not installed.

Package not patched:

PKG=SUNWidn.u

Original package not installed.

Package not patched:

PKG=SUNWkvm.us

Original package not installed.

Package not patched:

PKG=SUNWkvm.v

Original package not installed.

Package not patched:

PKG=SUNWkvmt200.v

Original package not installed.

Package not patched:

PKG=SUNWluxl

Original package not installed.

Package not patched:

PKG=SUNWpcmci

Original package not installed.

Package not patched:

PKG=SUNWpcmem

Original package not installed.

Package not patched:

PKG=SUNWsckmr

Original package not installed.

Package not patched:

PKG=SUNWsckmu.u

Original package not installed.

Package not patched:

PKG=SUNWust1.v

Original package not installed.

Package not patched:

PKG=SUNWwrsd.u

Original package not installed.

Package not patched:

PKG=SUNWwrsm.u

Original package not installed.

This appears to be an attempt to install the same architecture and

version of a package which is already installed. This installation

will attempt to overwrite this package.

Dryrun complete.

No changes were made to the system.

<### Lots of these messages ###>

Installation of <SUNWcsl> was successful.

This appears to be an attempt to install the same architecture and

version of a package which is already installed. This installation

will attempt to overwrite this package.

Killed

Killed

.

.

Installation of <SUNWcslr> was successful.

This appears to be an attempt to install the same architecture and

version of a package which is already installed. This installation

will attempt to overwrite this package.

Merge new /etc/security/audit_class.118833-36 into /etc/security/audit_class as needed.

Merge new /etc/security/audit_event.118833-36 into /etc/security/audit_event as needed.

Installation of <SUNWcsr> was successful.

This appears to be an attempt to install the same architecture and

version of a package which is already installed. This installation

will attempt to overwrite this package.

/var/sadm/pkg/SUNWcsu/install/i.none: /usr/bin/cp: cannot execute

/var/sadm/pkg/SUNWcsu/install/i.none: /usr/bin/cp: cannot execute

/var/sadm/pkg/SUNWcsu/install/i.none: /usr/bin/cp: cannot execute

/var/sadm/pkg/SUNWcsu/install/i.none: /usr/bin/cp: cannot execute

<###And then many more of these. Not appearing in the log are many errors related to not finding the appropriate copy of ld.so.1 ####>

ERROR: attribute verification of </usr/bin/fsstat> failed

pathname does not exist

ERROR: attribute verification of </usr/lib/help/auths/locale/C/SmfValueHeader.html> failed

pathname does not exist

ERROR: attribute verification of </usr/sadm/install/miniroot.db> failed

pathname does not exist

ERROR: attribute verification of </usr/sbin/netservices> failed

pathname does not exist

/var/sadm/pkg/SUNWcsu/save/118833-36/undo: No such file or directory

compress(1) returned error code 1

The SUNWcsu backout package will not be compressed.

Continuing to process backout package.

/var/sadm/pkg/SUNWcsu/save/SUNWcsu: No such file or directory

Installation of <SUNWcsu> partially failed.

Ron_Dawsona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 12

As a follow-up, I've discovered that part of my problem seems to be the version of the patch that smpatch downloaded. That version of 118833-36 almost always causes problems. However, if I manually download 118833-36 from sunsolve I get a version of the patch that tends to work. Is there something wrong with what smpatch is doing to download the patch?

Ron_Dawsona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 13

Which version of the patch did you download from Sunsolve, was it the signed (*.jar), or unsigned (*.zip) that you downloaded?

For you reference I have included a listing of size and output from sum below, does this differ from what you have?

$ ls -l 118833-36*

-rw-r--r--1 rootroot54412803 Feb 2 17:40 118833-36.jar

-rw-r--r--1 rootroot54460754 Feb 9 11:15 118833-36.zip

$ sum 118833-36*

3628 106276 118833-36.jar

4259 106369 118833-36.zip

How were you applying the version from sunsolve?

Mod.

ForumModeratora at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 14

Sun case 65334634 was opened to determine why "patchadd 118833-36" failed.

They said to refer to Bug ID 6522362. For our workaround, I had to remove the Chinese Sun Management Center package "SUNWcsrm" to get the kernel patch to apply. I don't think that many people will have this problem since Sun Management Center is not loaded by the majority. That is only conjecture. I find this application addon nice for its performance history accounting.

When the Sun Management Center software was loaded graphically, there was no option to unselect the foreign language support features. I usually do not fret if extra language support is added.

j.k.harrisona at 2007-7-8 23:18:52 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 15

The working version that I downloaded from sunsolve was the unsigned "zip" version. The version that did not work for me was the signed "jar" file that smpatch downloaded to /var/sadm/spool/

For the sunsolve version (i.e., *.zip), all I did was patchadd 118833-36 and it seems to be working like a charm for all of the Sunblade 2500's I've tried it on so far. I was just about to try to apply this particular version of the patch to a Sun Fire V250.

For the smpatch version (the *.jar file) I just used patchadd with no arguments.There were some file permission problems in the jar file as well that I didn't mention in my previous posting.

Ron_Dawsona at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 16
With regard to file sizes:The file size for both my 118833-36.jar and 118833-36.zip file was identical to the sizes in your message.
Ron_Dawsona at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 17

The contents of the JAR and ZIP files are the same aside fromt the patch signing data for the JAE file. However if you extract the JAR file as a normal user, then the permissions of directories will be restricted to that of your umask. So when patchadd runs commands as an unprivileged user it will not be able to read the directories.

Could you try extracting as root and rechecking?

ForumModeratora at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 18

I'm pretty sure I've always extracted the files from the jar file as root.

I just tried again as root - this time on an old Ultra 10 running Solaris 10 update 3. Once again I get the same permissions problem (a number of files that should be executable are not). Even if I go ahead and fix the permission issues myself, I'm sure I'll end up with the patch install errors again. I get none of these problems with the *.zip version I downloaded from sunsolve.

FYI, the patchadd error message is:

ERROR: The /var/sadm/spool/118833-36/prepatch script contains invalid permissions. Please make the script executable and reinstall 118833-36.

Ron_Dawsona at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 19
Hello,Please can you run the following commands:ls -laR /var/sadm/spool/118833-36/cat /var/sadm/patch/118833-36/logRegards,Message was edited by: ForumModerator
ForumModeratora at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 20

I have run into this problem before as well. Just yesterday, when trying to install patches on a 1500, we ran into exactly this issue. Thanks to Ron Dawson's comments, I was able to work out enough of what was going on to fix things. Namely, for some reason when the Update Manager downloads 118833-36 I think it loses execute permissions on various files during the unpacking of the .jar file. As a result, the installation does not succeed. Unpacking the .zip file does not have this problem.

My first attempt to manually apply the patch was, in single user mode as root:

cd /var/sadm/spool

mkdir tmp

cd tmp

jar xf ../118833-36.jar

patchadd 118833-36

(I note that the man pages say that an absolute path needs to be specified for patchadd, but the above usage seems to work. Regardless, the problem is not with the patchadd command, as will become clear.)

The above attempt failed, complaining about the permissions on the prepatch script. Checking them, they were all mode 644, and so not executable. The next attempt then went:

cd 118833-36

chmod 755 p*

cd ..

patchadd 118833-36

The installation appeared to proceed satisfactorily for a while, then produced a large amount of errors of the form "... /usr/bin/cp: cannot execute". This was logged as a partial failure while trying to install the SUNWcsu package, and the patch was then backed out.

Checking the extracted .jar file revealed much badness: all of the files in 118833-36/SUNWcsu/reloc/usr/bin ('cp' among them) had permissions 644. Consequently, when they were installed in /usr/bin they were no longer executable and the rest of the installation failed.

The root umask was 0022, and I cannot see why these permissions were being lost, assuming that they were correct in the .jar file. There was also another patch which had bad permissions, but I cannot recall which one (I think it ended in 578-08); in that case it was enough to correct the permissions on the {pre|post}patch scripts. Or so it seemed -- maybe there's a time bomb waiting to trigger now if something has been installed with the wrong permissions.

I've also had similar issues with other patches on Opteron-based machines. For example, on one of them now when I unpack 124187-03.jar the files contained within do not have the execute permission where they should. Changing the umask to 0000 does not alter this. Strangely, however, the corresponding .jar.dir directory does appear to have the correct permissions.

Anyway, maybe I'm barking up the wrong tree here, but it seems like jar is behaving a little strangely. Or is this behaviour explained somewhere?

(I should add that the machines in question are essentially factory installs, with patches added. Nothing dodgy has been done to them as far as I know.)

Geoff Bailey.

Magma2a at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...
# 21

Not sure if this will help anyone in the future but we just experienced problems applying 118833-36 on a V480. It would die with an error 5 (pkgadd failed.)

The problem turned out to be too many mounted filesystems! The machine in question is a fileserver running ZFS. I was able to run "umountall" and then successfully install the patch.

Actually I then hit the known error described in http://sunsolve.sun.com/search/document.do?assetkey=1-26-102849-1 but that was easily resolved.

Hope this helps someone.

Allen

abellettia at 2007-7-21 16:52:08 > top of Java-index,Administration Tools,Sun Update Connection-System...