uname & showrev shows different patch levels - Why?

The uname(1M) command queries the running kernel to find the patch revision. The showrev(1M) command reads through the patch logs. What happens is that the patch logs are updated with the new patch, but the in-memory image of the kernel is not updated.


When the system is booted, the revision string that uname uses is loaded with the unix module, which can be found in the various platform directories depending on the architecture.

For Example:

32 bit SPARC - /platform/sun4u/kernel/unix
64 bit SPARC - /platform/sun4u/kernel/sparcv9/unix
intel - /platform/i86pc/kernel/unix
The following identifies the architecture for your machine:

$ uname -m
VERIFY THE FOLLOWING
1. Was the system rebooted after installing the patch, or patches?

When you reboot the machine after applying the patch, or patches, be sure to run the init 6 command. Do not simply exit single-user mode and proceed up to multi-user mode. When the run level is changed from single-user to multi-user in that manner, the kernel module is not reloaded; only the run state is changed. The init 6 command performs a complete reboot and reload the kernel.

2. Does this machine use Volume Manager or Solstice Disksuite[TM]?

If so, your issue could be caused from a failing/out-of sync-mirror (stale mirror).

Physically disconnect one side of the mirror. The volume management system looks after the failure, but it will stop alternating reads with a possible bad mirror.

3. Review what the output from the following command produces:

$ strings /platform/`uname -m`/kernel/sparcv9/unix | grep Generic
The command should show a result that is similar to the following:

Generic_117350-05
4. Check what the kernel binary shows:

$ /usr/ccs/bin/what /platform/`uname -m`/kernel/sparcv9/unix
The kernel binary should show a result similar to the following:

SunOS 5.8 Generic 117350-05 Jun 2004
5. Review what the output from the following command produces:

Note: For the Solaris[TM] 8 Operating System (Solaris 8 OS) and above, use mdb. For earlier OS versions, use adb. Be sure to run this command as root:

# echo "$ utsname:
utsname: sys SunOS
utsname+0x101: node maniac
utsname+0x202: release 5.8
utsname+0x303: version Generic_117350-05
utsname+0x404: machine sun4u
6. Was the patch or patch cluster installed in single user mode?

If not, then the system could be corrupted and it might have to be restored from backup or reinstalled.

As a last resort, before having to re-install the OS, try backing out the patch and re-applying it while in single user mode.

If for some reason the patch does not backout, try re-adding the patch with the -u option.

# patchadd -u
Re-adding the patch with the -u option forces the patch to be re-applied even though the system believes that it has already been applied and might also solve the problem. This will force it to overwrite the patch that was just installed and might solve the problem.

This problem will also be seen with Solaris[TM] 2.6 patched with KJP 105181-38 running on an E10000 domain. The E10000 kenel binary in the patch contains the wrong version string :
# strings ./SUNWcar.u1/reloc/platform/SUNW,Ultra-Enterprise-10000/kernel/unix | grep 105181
Generic_105181-37