News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Technologies / Oracle Solaris 11
January 31, 2018
What's in a uname ?
One of the more subtle changes with Oracle Solaris 11.4 is the identity of the Operating System - namely the output of uname(1). Obviously we are not changing the release - this is still SunOS 5.11 which brings along the interface stability levels that Oracle Solaris has delivered for decades. However, in part based upon customer feedback, and in part internal requirements, the version level now displays finer grained information:
$ uname -v 11.4.0.12.0
If we compare this to the output from an Oracle Solaris 11.3 machine running Support Repository Update 28:
$ uname -v 11.3
So we now have 3 extra digits to convey more information, whose meaning is:
11.<update>.<sru>.<build>.<reserved>
Update : the Oracle Solaris update. From the above we see this is Oracle Solaris 11 Update 4
SRU : the SRU number. Again, from the above, as this is a beta release, it is not an SRU so the value is 0.
build: the build of the Update, or if the SRU is non-zero, the SRU.
reserved: this is a number that will be used to reflect some internal mechanisms - for example, if we discover a problem with the build but the next build has been started then we will use this number as a 'respin'.
Taking this forward when the 9th SRU is produced the output of uname -v will be:
$ uname -v 11.4.9.4.0
As an SRU typically has 4 builds we see the build number is 4 and, as the SRU is perfect, the reserved field is 0.
One other important change, which is not immediately obvious, is that the version is no longer encoded in the kernel at build time. Rather it is read from a file at boot: /etc/versions/uts_version. This brings about an important point - the system identity can be changed without the need to deliver a new kernel. This means, that potentially, SRUs can be delivered that modify userland binaries AND can update the system identity (ie no need to reboot to update the system identity). This file is protected from being modified via extended attributes used within the packaging system, and because it is a delivered file it is easy to detect if has been modified:
# pkg verify -p /etc/versions/uts_version PACKAGE STATUS pkg://solaris/entire ERROR file: etc/versions/uts_version ERROR: Hash: 7d5ef997d22686ef7e46cc9e06ff793d7b98fc14 should be 0fcd60579e8d0205c345cc224dfb27de72165d54
What about the previous advice to use 'pkg info entire' to identify the system? Using the packaging system to identify what is running on the system continues to be a sure fire way simply because trying to convey detailed information in 5 digits is really impossible for a variety of reasons.
The versions (fmri's) of packages have been changed. We have taken the leap to make them more reflective of the release. For example:
$ pkg list -H entire entire 11.4-11.4.0.0.0.12.1 i--
whereas in the 11.3 SRU case:
$ pkg list -H entire entire 0.5.11-0.175.3.28.0.4.0 i--
The fmri now indicates this is 11.4 and the branch scheme (numbers after the '-') has replaced 0.175 with a much more useful release version. The above example indicates Oracle Solaris 11.4, build 12 and a respin of 1. The exact details of the various digits are documented in the pkg(7).
uname -a
SunOS itmmtsun9 5.10 Generic_150400-51 sun4u sparc SUNW,Sun-Fire-V240
So the "Generic_nnnnnn" would be the kernel number.
Is this format still used on 11.4 on those systems and if so, what is the kernel version that would be there for the new 11.4?