· Solaris · Unix

Which Solaris Release Matches Which SunOS Kernel Version?

The full SunOS-to-Solaris version table, why Sun dropped the '2.' after 2.6, and the uname, showrev, and /etc/release output that show both numbers live.

Which Solaris Release Matches Which SunOS Kernel Version?

Purpose

Is Solaris 9 the same release as SunOS 5.8, or SunOS 5.9? The two labels look close enough to swap by accident, and a support case, an old Sun advisory, or a config file inherited from a decommissioned box will just as often carry one number as the other. Only one of the two — the SunOS kernel version — prints directly from a running system; the Solaris marketing name has to be read off a separate file or a separate command.

The split has a fixed origin. In 1987, AT&T Corporation and Sun Microsystems agreed to merge the era's competing Unix variants — BSD, System V, and Xenix — into a single System V Release 4 base. On September 4, 1991, Sun confirmed that its next major operating-system release would leave the BSD-derived SunOS 4 codebase behind for one built on SVR4. Internally, that release stayed SunOS 5. Externally, Sun gave it a new name: Solaris. Sun's own stated reason for the rebrand was that "Solaris" covered more ground than the kernel alone — it wrapped the OpenWindows desktop environment and Open Network Computing services into a single product name alongside SunOS. The older SunOS 4.1.x micro-releases were retroactively given Solaris 1.x names after the fact, even though they predate the SVR4 rewrite by years and share no codebase with the SunOS 5.x line that everyone means by "Solaris" today.

This post lays out the SunOS-to-Solaris mapping and the commands that pull both numbers off a running Solaris 8 host. That version check is one of the entries collected on the Solaris commands and scripts page .

Code

 1$ uname -a
 2SunOS smurf 5.8 Generic sun4u sparc SUNW,Ultra-5_10
 3
 4$ cat /etc/release
 5                       Solaris 8 2/04 s28s_hw4wos_05a SPARC
 6           Copyright 2004 Sun Microsystems, Inc.  All Rights Reserved.
 7                        Assembled 26 February 2000
 8
 9$ showrev -a
10Hostname: smurf
11Hostid: 1a2b3c4d
12Release: 5.8
13Kernel architecture: sun4u
14Application architecture: sparc
15Hardware provider: Sun_Microsystems
16Domain: lab
17Kernel version: SunOS 5.8 s28_26 February 2000
18OpenWindows version: OpenWindows Version 3.6.2 9 August 1999
19No patches are installed
20
21$ hostid
221a2b3c4d

Code Breakdown

  • uname -a — prints the kernel name and kernel version (5.8) along with hostname, kernel architecture (sun4u), and application architecture (sparc). This is the SunOS-numbering half only; it never prints the word "Solaris."
  • cat /etc/release — the file Sun shipped with the customer-facing name already baked in: "Solaris 8 2/04." It is the fastest single command for the marketing name, and the assembly date at the bottom of the file pins down exactly which update of the release is installed, not just the major version.
  • showrev -a — the only command in this set that puts both numbers on one screen at once: Release: 5.8 sits directly above Kernel version: SunOS 5.8 s28_26 February 2000. It also reports the hostid and the bundled OpenWindows version, plus a patch-status line, which is why it is the stronger command to paste whole into a support case.
  • hostid — a single hexadecimal identifier tied to the host's hardware and license identity. It carries no version information on its own, but it is worth capturing in the same pass, since it is the field most support tickets ask for right after the release number.

Key Points

The SunOS 5.x line is the one every admin means by "Solaris" today, and the mapping between its kernel version and the marketing name is fixed and well documented:

SunOS version (uname -r)Solaris name
5.02.0
5.12.1
5.22.2
5.32.3
5.42.4
5.52.5
5.5.12.5.1
5.62.6
5.77
5.88
5.99
5.1010
5.1111
  • Through SunOS 5.6, the Solaris marketing number matched the SunOS minor version exactly, just with a leading "2." — SunOS 5.4 is Solaris 2.4, SunOS 5.6 is Solaris 2.6.
  • After Solaris 2.6, Sun dropped the "2." entirely, so SunOS 5.7 became "Solaris 7," not "Solaris 2.7." Any document that references "Solaris 2.7" or later is either predating that decision or simply wrong.
  • The offset rule still holds today: the current release line is Solaris 11.4, corresponding to SunOS 5.11, decades after the naming split.
  • Before the SVR4 rewrite, Sun also retroactively applied the Solaris name to its last SunOS 4.1.x micro-releases — Solaris 1.0 through 1.1.2 — even though nothing in that line shares a codebase with the SunOS 5.x line. SunOS 4.1.4, the final SunOS 4 release, corresponds to Solaris 1.1.2.
  • Sun's own staff at the time frequently kept calling those pre-SVR4 builds by their SunOS names rather than their new Solaris 1.x aliases, because the OpenWindows version bundled with each one moved on its own separate schedule.

Insights and Best Practices

Reading an old advisory or archived document correctly

Check whether a version number carries the "5." prefix before assuming it is wrong. "5.8" and "8" name the same release; "5.6" and "2.6" also name the same release. "Solaris 2.7" was never a shipped name, since Sun retired the "2." starting with the very next release.

Scripting a fleet inventory across mixed releases

uname -r is the more stable field to grep across a fleet that spans SunOS 5.0 through current Solaris — its format has not changed across the whole SVR4-based lineage. /etc/release is easier to read in a one-off human report, but its exact wording — spacing, the copyright line, the assembly-date format — has drifted release to release and update to update, which makes it a weaker choice for anything parsed programmatically. showrev -a is the safest single command to capture for a support ticket, since it puts the kernel version, the release number, and the hostid on one screen.

Why the Solaris 1.x names rarely matter day to day

Nothing running SunOS 4.1.x, or its Solaris 1.x alias, is realistically still in production. The only reason the early mapping still matters is archival: it explains why an old Sun document, an old newsgroup archive, or an old box's paperwork can carry a "1.x" label that has nothing in common with the current 1x-numbered releases like Solaris 10 or 11.4. Confusing a 1990s SunOS 4 build with the current release line is an easy, avoidable mistake once the two eras are kept separate — Solaris 1.x predates the SVR4 rewrite; Solaris 10 and later do not.

When to Run This

  • Confirming which kernel patches, driver builds, or compatibility notes apply to a box when a vendor advisory is written in SunOS terms but your inventory tracks Solaris marketing names.
  • Auditing a mixed fleet of SPARC hosts where /etc/release text has drifted across rebuilt images or cloned installs, and the kernel version is needed as a fixed cross-check.
  • Filing or reading a support case, where the version field usually wants the uname -r string rather than the marketing name.
  • Reading old Sun documentation or archived discussion threads that reference "Solaris 1.x" or "Solaris 2.x" and needing to know immediately which real kernel generation is being described.

Troubleshooting Common Issues

  • uname -a and /etc/release show numbers that don't fit the mapping at all. Check whether the release file was hand-edited or copied over from another build during imaging. The offset between the two counters is fixed, so a mismatch outside the documented pattern usually means the release file is stale, not that the mapping has an exception.
  • An advisory references "Solaris 2.7," "2.8," or "2.9" and nothing in your inventory matches. Those names were never shipped. Sun renamed the release "Solaris 7" before it went out the door, and every release after 2.6 dropped the "2." entirely. Treat any "2.x" reference past 2.6 as a naming error, not a missing release.
  • showrev -a doesn't reflect patches you know are applied. That legacy patch-database format applies to Solaris 8 and earlier updates of Solaris 9; later releases moved patch tracking toward package- and image-based mechanisms, so showrev -a's patch line will read empty even on a fully patched host.
  • You can't tell whether a document means the SVR4 Solaris or the old SunOS-4-era "Solaris 1.x." Look for the paired SunOS version. Anything paired with SunOS 4.1.x is the old BSD-derived line; anything paired with SunOS 5.x is the SVR4-based operating system that current Solaris documentation and support cover.

References