illumos Release History: OpenSolaris to OpenIndiana, OmniOS and Support

illumos is the open source operating system core that was forked from OpenSolaris in August 2010, after Oracle bought Sun and stopped publishing OpenSolaris source updates. illumos itself is not a distribution. You install OmniOS, OpenIndiana, SmartOS or Tribblix, and each sets its own release and support policy. As of 25 October 2026, OmniOS supports r151058 until 3 May 2027, r151056 until 2 November 2026 and the r151054 LTS until 1 May 2028, while OpenIndiana Hipster is a rolling release whose latest snapshot is 2026.04.

That split between a shared core and independent distributions is the key to illumos support. A kernel fix lands once, in illumos-gate, and each distribution then decides when and how to ship it. This post covers the lineage from OpenSolaris to the fork, what illumos contains, every OmniOS release with its dates, OpenIndiana's Hipster snapshots, SmartOS and Tribblix, and a step by step routine for updating inside a boot environment and rolling back.

Key takeaways

• The fork date is 3 August 2010. The illumos announcement page records that Garrett D'Amore announced the project that day as an effort to swap the closed source parts of OpenSolaris for open implementations. The illumos history page says Oracle "silently closed the gate" after acquiring Sun in 2010.
• illumos is a core, not a product. The about page compares it to "a BSD source tree, or Linux's kernel.org". It contains the kernel, drivers, core libraries and utilities, under the CDDL, and supports 64 bit x86 hardware.
• OmniOS has the clearest published support dates. Stable releases ship around the first week of May and November and get one year of support. Every fourth stable release is an LTS with three years. The OmniOS schedule lists three supported releases today: r151058, r151056 and the r151054 LTS.
• r151056 reaches end of support on 2 November 2026. If you run it, the supported paths are r151058 (stable, until 3 May 2027) or r151054 (LTS, until 1 May 2028).
• OpenIndiana Hipster has no per release support window. It is a rolling branch. Snapshots such as 2026.04 (announced 5 May 2026) are install media, and support means staying current with the Hipster repository.
• SmartOS ships a new platform image roughly every two weeks. The public release directory runs from 13 August 2011 to 23 October 2026. SmartOS runs from memory, so updating means booting a newer image.
• Security fixes land in illumos-gate on an embargo date, then flow to distributions. The illumos security policy forbids distributions from shipping a coordinated fix before it lands in illumos-gate, and requires the CVE record to be fully updated within 48 hours of announcement.
• Boot environments make updates reversible. Both OmniOS and OpenIndiana update into a cloned ZFS boot environment, so a bad update is undone by activating the previous environment and rebooting.
• Solaris 11 patches do not apply. illumos and Oracle Solaris diverged in 2010. Oracle's current Solaris 11.4 has separate packages, SRUs and support.

This post sits alongside our BSD release histories. For comparison with other Unix lineages and their support models, see every FreeBSD major version and its security support model, the NetBSD release history and pkgsrc and OpenBSD's release history and security innovations.

What was OpenSolaris, and why did illumos fork from it?

Solaris 10 and the opening of the source

The illumos history page starts the story in 2005, when "Sun Microsystems released Solaris 10 which contains several truly innovative features we continue to rely on to this day", and at the same time open sourced the operating system as OpenSolaris. The page is candid that there "were a few governance missteps along the way", but calls the move bold.

Jim Grisanzio, who managed OpenSolaris community projects at Sun from 2004 to 2010, keeps a detailed publication history of OpenSolaris that gives the exact source release dates. Three of them matter most for anyone running illumos today:

• 25 January 2005: the DTrace source code from the OS/Networking (ON) consolidation was published, months before the rest of the kernel.
• 14 June 2005: the ON consolidation, meaning the kernel source, was published. This is the date usually given as the launch of OpenSolaris.
• 16 November 2005: the ZFS project was integrated into ON build 27.

His list continues through 2009. BrandZ, the framework that later made Linux branded zones possible, was integrated into ON build 49 on 11 September 2006. By 26 February 2009 the documentation consolidation included guides for the Image Packaging System and for managing boot environments, the two technologies that still define how OmniOS and OpenIndiana are updated today. The same page records that Sun wrote a new license for the code, the Common Development and Distribution License, based on the Mozilla Public License, and built several OpenSolaris branded binary distributions alongside the source.

Not all of OpenSolaris was open

The OpenSolaris source was never complete. In his announcement webinar, transcribed on the illumos announcement page, D'Amore listed what was missing: "libc-i18n", a component needed to build a working C library, the NFS lock manager, the crypto framework and "a number of really important drivers". Anyone who wanted to build a working system from the published source needed binary blobs that only Sun, and later Oracle, could supply. D'Amore named Nexenta and other derivative distributions as downstream projects that depended on them.

What happened in 2010

Oracle completed its acquisition of Sun in 2010. According to the illumos history page, Oracle then "silently closed the gate": the source code stopped being updated and communication with the open source community stopped. The page's conclusion is blunt: "OpenSolaris was effectively dead."

The illumos project was announced on 3 August 2010. In the words quoted on its announcement page, it was "a community effort of some core Solaris engineers to create a truly open source Solaris by swapping closed source bits of OpenSolaris with open implementations." D'Amore described the technical approach as a child repository of OS/Net that tracked the upstream closely, with a goal of binary compatibility so that an application built for Solaris would run unchanged on illumos. The name, he explained, combines the Latin "illum" for light with "OS".

Once Oracle stopped publishing OS/Net, there was no upstream left to track, and illumos became the upstream for every distribution that had depended on OpenSolaris.

The illumos FAQ adds that the project "was initiated by then-employees of Nexenta in collaboration with former OpenSolaris community members and volunteers", that several companies have sponsored work, and that the project "is independent of their business decisions". It also notes that some inherited binary only components remain, but that unlike OpenSolaris, illumos does not require a closed source compiler.

What does illumos include?

The consolidation

The illumos about page quotes the illumos Developer's Guide: illumos "is a consolidation of software that forms the core of an Operating System. It includes the kernel, device drivers, core system libraries, and utilities." The FAQ adds that the code base is a fork of the Sun and Oracle tree called OS/Net, or ON, and covers the kernel, network stack, file systems, device drivers and "all of the basic userland libraries and applications".

The about page is explicit about what illumos is not: it "does not offer an OS distribution", it does not ship third party software such as web servers, and "distributions include their own package management". That is why your release, support window and update command all come from the distribution, not from illumos.

The core technologies

The about page and the illumos features page list the shared technologies every illumos distribution should include:

The features page notes that KVM and QEMU were ported to illumos in 2011, and that bhyve from FreeBSD is available in at least SmartOS and OmniOS. The about page says illumos "currently supports 64-bit x86 hardware from Intel and AMD"; some distributions also publish SPARC builds.

How illumos relates to OpenZFS

ZFS is the part of the illumos heritage most people meet outside illumos. The features page says ZFS "was developed at Sun Microsystems in the early 2000s and released as open source in 2005 as part of the OpenSolaris project", and that "OpenZFS was announced in 2013". Grisanzio's history pins the integration into ON build 27 at 16 November 2005.

Today the relationship runs in two directions. illumos carries its own ZFS implementation inside illumos-gate, and that is the ZFS you run on OmniOS, OpenIndiana, SmartOS and Tribblix. The OpenZFS documentation is the home of the separate, cross platform OpenZFS code base: its getting started section covers Linux distributions and FreeBSD, and its man pages are versioned up to the 2.4 series. illumos does not appear on that getting started list.

The practical consequence is pool portability. ZFS pools use feature flags, and a pool with a feature the importing system lacks cannot be fully imported there. If pools move between illumos and OpenZFS hosts, compare the feature@ properties from zpool get all on both sides before running zpool upgrade, which enables every locally supported feature and cannot be undone.

Which distributions are built on illumos?

The illumos distributions page explains that some distributions "are maintained by enthusiasts, while others are primarily developed by companies with their own priorities and focus", and that not all distributions have the latest features or support all hardware. Its comparison chart lists OmniOS CE, OpenIndiana, SmartOS, NexentaStor, Tribblix, DilOS, XStreamOS, v9os and Danube Cloud. Four of them have active public release streams that this post covers in detail.

OmniOS Community Edition

OmniOS describes itself on its home page as "The Open Source Enterprise Server OS with just the features you need", an illumos based server OS with ZFS, bhyve, DTrace, Crossbow, SMF and Linux zone support. Its installer, Kayak, can build a VM "in less than 2 minutes", and its packages are digitally signed.

OmniOS was originally released by OmniTI. The OmniOS release notes index lists the archived OmniTI releases from r151002 (2 April 2012) to r151022 (12 May 2017). The OmniOS about page records that on 21 April 2017 OmniTI announced it would suspend active development and not renew support contracts, after "five years of releases twice a year". Fourteen weeks later, OmniOS Community Edition was a reality. It is now maintained by the OmniOS Community Edition Association, a Swiss association whose board controls access to the OmniOS certificate authority used to sign packages.

The r151058 announcement gives a candid figure: almost 2,000 active installations and fewer than 20 regular contributors.

OpenIndiana

OpenIndiana calls itself the "Community-driven illumos Distribution" on its home page. The illumos distributions chart describes its focus as workstations and servers, with IPS packaging and both x86 and SPARC. The OpenIndiana handbook explains that the current branch is Hipster, a rolling release, and that "the legacy oi-dev-151x branch is no longer maintained". OpenIndiana is the closest thing to the old OpenSolaris desktop experience, with a MATE desktop, Firefox and Thunderbird in the repository.

SmartOS

The SmartOS documentation describes SmartOS as "a specialized Type 1 Hypervisor platform based on illumos". It runs two kinds of guest: OS virtual machines, which are zones, and hardware virtual machines under KVM or bhyve, which themselves run inside a stripped down zone. It is a "live OS", booted from PXE, ISO or USB and run entirely from memory, so local disks are used only for the ZFS pool that holds virtual machines. The SmartOS site describes it as the hypervisor underneath the Triton cloud platform, and uses pkgsrc rather than IPS for packages inside zones.

Tribblix

Tribblix is "the retro illumos distribution", created by Peter Tribble. The distributions chart lists its packaging as SVR4, the original Solaris package format, and its focus as workstations and servers on x86 and SPARC. Tribblix releases are numbered milestones. Its home page announced Milestone 41 on 5 August 2026, and an upgrade path for SPARC to m35 on 23 September 2026. The Tribblix download page offers m41 in standard and minimal images, each with an optional LX zones variant.

Distributions compared

Only OmniOS publishes a dated end of support for each release. For the others, supported means running the current image or repository.

OpenIndiana Hipster: the rolling model and its snapshots

How Hipster works

The handbook says that "approximately every six months, the OpenIndiana project releases a snapshot of the Hipster rolling release branch". A snapshot is not a separate release with its own repository. It is a fresh set of ISO and USB images built from the Hipster repository on that date. A system installed from the 2024.04 images and updated today is running the same packages as one installed from 2026.04 and updated today.

The handbook is honest about the trade off: "Hipster is a rapid development branch where software versions are frequently updated", and while every package is tested, "caution is nevertheless warranted when deploying Hipster into mission critical production environments." The OpenIndiana downloads page says installations "can be updated regularly using the Hipster repository, and receive security fixes".

Three dated changes from the handbook and downloads page are worth knowing if you meet an older install:

• 2016.10: the FreeBSD boot loader was ported and introduced with this snapshot. Older Hipster images, including the legacy oi-dev-151x builds, need a different USB preparation method and did not support UEFI.
• 2017.04: running on 32 bit systems stopped being supported, and the userland began moving to 64 bit only. From this release every image is signed with the OpenIndiana Release Engineering GPG key, id DBE31887.
• Today: current Hipster supports UEFI without Secure Boot, and needs a 64 bit CPU, 16 GB of disk and 2 GB of RAM for a server install, or 20 GB and 4 GB for a desktop.

Recent snapshot history

The dates below come from the announcements listed on the OpenIndiana home page. The date is when the announcement was posted, which is sometimes weeks after the images appeared; the 2024.10 announcement itself opens by saying the snapshots "have been updated a while ago".

The 2023.05 entry is the clearest example of how a rolling distribution handles a severe flaw. The 2023.05 announcement explains that the project had been made aware of "a severe security Issue in illumos-gate", that the fix was already in the repository, and that new images were being built so that people installing from media would get the fix without having to update first. Existing systems only needed pkg update and a reboot.

What a snapshot changes

The 2026.04 announcement shows the mix of work that goes into a six month window. It lists OpenSSH 10.3p1, CVE patches for openssl 1.1 imported from OmniOS, CVE fixes for libsoup3 and jq, Firefox and Thunderbird 150, Rust 1.95, Clang 21 as the default compiler, Go 1.26 as the new default with Go 1.22, 1.23 and 1.24 obsoleted, Python 3.14.4 and 3.13.13 alongside 3.12 and 3.9, QEMU 11.0, VirtualBox 7.2.8, new bhyve features from illumos, the igc 2.5G NIC driver and new virtio and storage drivers.

Two lessons sit in that list. Distributions share userland fixes directly: the openssl 1.1 patches came from OmniOS, not through illumos-gate. And obsoleting old runtimes is part of the rolling model, so an application that depends on Go 1.22 from the repository needs a plan before the next update removes it.

OmniOS: release cadence, LTS and support dates

The rules

The OmniOS release schedule sets out the policy in four sentences that are worth reading in full on the page. Summarised:

1. Even numbered releases are stable; odd numbered releases are the unstable development branch, called bloody.
2. Stable releases come out roughly every six months, around the first week of May and the first week of November, and each is supported for one year.
3. Every fourth stable release is a long term support (LTS) release, supported for three years.
4. LTS releases overlap by one year "to allow time for validation and upgrade even in complex environments", and regular stable releases overlap by six months.

The stable versus bloody page explains what support means inside a release. Stable is "designed to be run in production with minimal disruption". Kernel updates within a stable release are made "only if they are security- or stability-related and no work-around exists". Non disruptive updates are published weekly when there is something to ship, and moving to a new stable release always requires a reboot. Bloody incorporates kernel and userland updates aggressively as they become available.

Every OmniOS Community Edition release

Release and end of support dates are copied from the schedule as published on 25 October 2026.

The LTS sequence is r151022, r151030, r151038, r151046 and r151054, exactly every fourth stable release. On that pattern the next LTS would be r151062, due around May 2027, but the schedule does not list it yet, so treat that as an expectation rather than a date.

The OmniTI releases before the community edition

The release notes index keeps the original OmniTI releases as an archive. None of them are supported.

Upgrade paths

The OmniOS upgrade guide lists which jumps are tested. Paths that are not shown "have not been tested and are not supported". The current table allows r151054 LTS to go to r151056 or r151058, and r151052 to go to r151054. Older releases have to step through intermediate releases, for example r151046 LTS through r151048, r151050 or r151052 to reach r151054. The guide also warns that the GRUB boot loader "is not supported as of the r151054 LTS release", and that legacy OpenSSH options must be removed before upgrading or the SSH service may fail to start afterwards. If you manage a server remotely, that second warning is the one to act on first.

What end of support means for r151056

r151056 reaches end of support on 2 November 2026, and weekly updates for it stop. When r151058 shipped, its announcement said "LTS r151046 is now end-of-life" and pointed users to r151054 or r151058. r151056 systems face the same choice now: r151058 if you upgrade every six months, or r151054 to stay put until May 2028.

SmartOS and Tribblix release patterns

SmartOS platform images

SmartOS releases are platform images named by their UTC build timestamp. We listed the public SmartOS release directory on 25 October 2026. Its earliest entry is 20110813T221858Z, built on 13 August 2011, and its latest is 20261023T001807Z, built on 23 October 2026. Through 2025 and 2026 a new image appears about every two weeks, with occasional extra builds a day or two after a regular one, such as 20260611T000507Z followed by 20260611T215617Z. A community changelog parses each release's changelog file into a readable list.

Because SmartOS runs from memory, its documentation lists "no need for patching" among the advantages. The unit of update is the whole platform image: put the new image on the boot USB key or PXE server and reboot. pkgsrc packages inside zones still need their own updates.

Tribblix milestones

Tribblix numbers releases as milestones: Milestone 41 for x86 on 5 August 2026, and on 23 September 2026 a SPARC upgrade to m35, "a synthetic release with new packages atop m34". The home page says the SPARC version "still suffers from lack of testing", while "the x86 version is pretty solid". There is no dated support window per milestone.

Timeline: from OpenSolaris to today

How security fixes reach an illumos system

The illumos security process

The illumos security page starts from a structural fact: "The illumos project supplies multiple downstream distributions, so a vulnerability in illumos must have its mitigations and fixes available to the distributions." Reports go confidentially to security@illumos.org. For a report received under confidentiality, the documented process is:

1. The security team analyses and confirms the report, possibly with help from distributions' security contacts.
2. It reserves a CVE number before public disclosure.
3. It makes sure a fix is written, tested, reviewed and approved for illumos-gate, but does not land it immediately.
4. It contacts distributions to coordinate, including those with long term support releases that may also be affected, and sets an embargo date.
5. On the embargo date the fix lands in illumos-gate. Distributions that coordinated may land it in their own trees "no earlier than when it lands in illumos-gate itself".
6. The issue is announced, and the CVE record is fully updated no later than 48 hours after announcement.

When a vulnerability is disclosed publicly first, the team discusses fixes as soon as possible, tells distributions, announces any mitigation available before a fix, and helps write and integrate the fix.

A dated example: CVE-2023-31284

The clearest recent example is CVE-2023-31284. The OmniOS security alert, posted on 4 May 2023, reproduces the illumos security team's advisory. It describes a kernel stack overflow "that can be performed by an unprivileged user, either in the global zone, or any non-global zone". The advisory said the team did not know of anyone exploiting it in the wild, that stack protection (the illumos default) could turn it into a denial of service but was "not a guarantee", and that the fix was a commit in illumos-gate.

The response shows how the model works in practice:

• OmniOS told users of every supported release, and of the just retired r151042, to run pkg update and reboot. r151046, released three days earlier on 1 May 2023, already included the fix.
• OpenIndiana built the 2023.05 security release the same day so that new installs from media were fixed, while existing systems updated from the repository.
• Both made the same point: the fix is in the kernel, so a reboot is required.

The general lesson: on illumos, a kernel fix is never live until you reboot into the boot environment that contains it.

IPS packages and signatures

OmniOS and OpenIndiana both use the Image Packaging System, IPS, which the OpenIndiana handbook describes as "a network-centric packaging system" written in Python. Packages are identified by FMRIs such as pkg:/editor/gnu-emacs@29.1-2023.0.0.1, served from publishers such as https://pkg.openindiana.org/hipster or https://pkg.omnios.org/r151058/core. The OmniOS home page says its updates are digitally signed, and the OmniOS about page notes that the association's board controls the OmniOS certificate authority. The upgrade guide shows how anyone moving from OmniTI OmniOS installs the community CA certificate and checks its SHA1 fingerprint before trusting packages signed under it.

For security work, two IPS properties matter: pkg update with no arguments moves every installed package to the newest version the installed incorporation allows, and pkg history logs what changed and when.

Boot environments

A boot environment is a bootable clone of the root file system on ZFS. The handbook describes beadm as "designed to work in concert with the ZFS file system and the IPS package manager", and explains that when you run pkg update, IPS automatically creates a clone of the boot environment for updates that need one. The original environment is left untouched, so if the update misbehaves, beadm activate on the previous environment and a reboot puts the system back exactly as it was.

The OmniOS upgrade guide adds a caution: changes made to the current boot environment after an upgrade starts, logs included, "will be lost once you reboot into the new one". Stop services that write data you care about first.

How fast fixes arrive

There is no single number. A coordinated kernel fix reaches illumos-gate and the distributions on the same embargo day; after that, speed depends on the distribution's model:

Step by step: install, check, update and roll back

This walkthrough uses OmniOS r151058 in a virtual machine, with notes where OpenIndiana differs. Run these on a test VM first. None of the commands below erase disks, but the installer does, so read the warning before step 1.

Step 1: download and verify the installer

Warning: the OmniOS and OpenIndiana installers overwrite the disk you select. In a VM, give the guest a fresh virtual disk. On hardware, confirm the target disk in the installer's disk list against its size and serial number before you continue.

Download the ISO and its checksum from the distribution's download page, then verify it on your workstation before booting it:

# Linux or macOS workstation: compare the published SHA-256
sha256sum -c omnios-r151058.iso.sha256    # Linux
shasum -a 256 omnios-r151058.iso          # macOS, compare by eye

# OpenIndiana images since 2017.04 are also signed with GPG key DBE31887
gpg --recv-keys DBE31887
gpg --verify <signature-file-from-download-page> <iso-file>

Use the exact file names from the download page. Give the VM at least 2 GB of RAM and 16 GB of disk.

Step 2: confirm what you are running

After installation, check the release and kernel:

cat /etc/release
uname -a
pkg info entire | grep -E 'Name|Version|Branch'
pkg publisher

On OmniOS, /etc/release names the release number, such as r151058, and pkg publisher shows the release specific repository, such as https://pkg.omnios.org/r151058/core/. On OpenIndiana the publisher is https://pkg.openindiana.org/hipster/. The publisher URL is the most reliable way to tell an OmniOS release apart from another, because it is what pkg update actually talks to.

Step 3: list boot environments and take a manual one

beadm list
beadm create pre-update-2026-10-25
beadm list

The beadm list output shows which environment is active now (N) and which will be active on reboot (R). The manual environment is your fallback even if a later pkg update decides it does not need a new one.

Step 4: preview the update

pkg update -nv

The -n flag is a dry run, and -v prints each package that would change and whether a new boot environment will be created. Read the list. If it includes system/kernel, system/library or the entire incorporation, plan for a reboot.

Step 5: apply the update into a new boot environment

pkg update -v --be-name omnios-r151058-2026-10-25
beadm list

--be-name forces the update into a new, named boot environment. When the command finishes, beadm list shows the new environment marked R, active on reboot. Reboot when you are ready:

init 6

Then confirm the result with cat /etc/release, uname -v and pkg history -l | tail -40.

Step 6: roll back if something is wrong

beadm list
beadm activate pre-update-2026-10-25
init 6

After the reboot you are back on the exact pre update file system. Once you have fixed the cause, activate the newer environment again or repeat the update. When you are sure, remove old environments to free space:

beadm destroy pre-update-2026-10-25

Step 7: move between OmniOS releases

To move from r151056 to r151058 before 2 November 2026, follow the upgrade guide. In outline:

# 1. Check legacy OpenSSH options first, per the upgrade guide
# 2. Make a backup boot environment
beadm create r151056-backup

# 3. Point the global zone and linked zones at the new release
pkg set-publisher -r -O https://pkg.omnios.org/r151058/core omnios
pkg set-publisher -r -O https://pkg.omnios.org/r151058/extra extra.omnios

# 4. Update into a new boot environment and reboot
pkg update -f -r --be-name=r151058
init 6

If you run ipkg zones, the guide also covers shutting them down and detaching them before the upgrade, then attaching them with zoneadm -z <zonename> attach -u afterwards, and recommends a recursive ZFS snapshot of each zone root first. For an LTS track, the same steps with r151054 in the publisher URLs keep you supported until 1 May 2028.

Step 8: on OpenIndiana

OpenIndiana uses the same commands without the release switch, because Hipster is one rolling repository:

pfexec pkg update -nv
pfexec pkg update -v
beadm list

By default new boot environments are named from the auto-be-name image property, for example openindiana-2026:10:25, and the boot menu lets you pick an older one if the new one does not come up.

Common mistakes

Running an OmniOS release past its end of support date. The schedule is public and precise. r151056 stops being supported on 2 November 2026. A host that is never moved to r151058 or r151054 stops receiving even the weekly security updates, and the longer it waits, the more intermediate releases it may have to step through.

Assuming every even numbered release is an LTS. Only every fourth stable release is LTS. r151056 and r151058 are regular stable releases with one year of support. Check the Type column in the schedule, not the release number.

Updating without a boot environment. pkg update usually creates one for core changes, but not for every update. Making a manual one with beadm create costs seconds and turns any update into a reversible one.

Forgetting to reboot after a kernel fix. The CVE-2023-31284 advisories from both OmniOS and OpenIndiana said a reboot was required. Until you reboot into the new boot environment, the running kernel is the old one, whatever pkg list says.

Treating OpenIndiana snapshots as releases with their own support. Installing from the 2024.10 images and never updating leaves you on 2024 software. The snapshot only sets your starting point. Support on Hipster means regular pkg update.

Assuming Solaris 11 binaries, packages or patches apply. illumos and Oracle Solaris have developed separately since 2010. Oracle's current release is Solaris 11.4, with its own repositories and support. Do not point an illumos system at a Solaris 11 IPS publisher, do not apply Solaris SRUs, and do not assume a Solaris advisory's fixed version means anything on illumos. Many old Solaris 10 era binaries do run on illumos, which is a benefit of the shared heritage, but compatibility is something to test, not assume.

Running zpool upgrade on a pool you share with OpenZFS hosts. Upgrading enables every feature the local ZFS supports, and some may not exist on the other side. Check feature flags first, and upgrade only when every system that imports the pool supports them.

Ignoring the packages inside zones. On SmartOS, a new platform image updates the hypervisor but not pkgsrc packages inside zones. On OmniOS and OpenIndiana, zones have their own package state too. Inventory and update both layers.

FAQ

Is illumos the same as OpenSolaris?

No. illumos is a fork of the OpenSolaris OS/Net code base, announced on 3 August 2010 after Oracle stopped updating OpenSolaris. It has developed independently since then, replacing closed source parts and adding features such as bhyve and LX branded zones.

What is the latest version of OmniOS?

As of 25 October 2026, the current stable release is r151058, released on 4 May 2026 and supported until 3 May 2027. The current LTS is r151054, released on 5 May 2025 and supported until 1 May 2028. The next stable release is expected in the first week of November 2026, per the schedule's May and November pattern.

When does OmniOS r151056 reach end of life?

On 2 November 2026, according to the OmniOS schedule. Upgrade to r151058 or to the r151054 LTS before then.

How long is an OmniOS LTS release supported?

Three years. Every fourth stable release is LTS, and LTS releases overlap by one year so you have a full year to validate and move to the next one.

What is OpenIndiana Hipster?

Hipster is OpenIndiana's rolling release branch. Packages are updated continuously in one repository, and about every six months the project publishes new install images, called snapshots, such as 2026.04. There is no separate support window per snapshot.

Can I run Solaris 11 software on illumos?

Sometimes, but it is not guaranteed. illumos began with a goal of binary compatibility with Solaris, but the two systems have diverged since 2010. Test each application, and never apply Solaris 11 patches or IPS repositories to an illumos system.

Does illumos use OpenZFS?

illumos carries its own ZFS implementation in illumos-gate, inherited from OpenSolaris. OpenZFS is the separate cross platform project, announced in 2013, whose current releases target Linux and FreeBSD. Pools can move between them as long as both sides support the pool's enabled feature flags.

How do I undo a bad update on OmniOS or OpenIndiana?

List boot environments with beadm list, activate the one from before the update with beadm activate <name>, and reboot. The previous environment is an untouched ZFS clone, so the system returns exactly to its pre update state.

illumos hosts serve storage to, or run zones and virtual machines for, applications that pull open source dependencies and container images, and those layers need the same patch discipline as the operating system underneath. The illumos kernel and IPS packages still come from your distribution, so the steps below apply to the software you build and run on top of it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard's fit with illumos is indirect, and it is worth being plain about it. Safeguard does not track illumos-gate, IPS publishers, SmartOS platform images or OmniOS support dates, and it does not patch an illumos kernel; those come from your distribution and the steps earlier in this post. Where it does help is the application layer: the repositories, container images and SBOMs for software you build, including software that runs in zones, under bhyve or against storage served by an illumos host.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a build machine that produces the services you deploy to illumos zones or to Linux guests on a SmartOS or OmniOS host, that is the route for scanning those repositories and images where they are built.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node.js service you run in an illumos zone, where the vulnerable dependency is in your repository rather than in an IPS package, so the fix is a change you make and test yourself.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, that connection lets you ask which of them contain a given component and version, which is the question you need answered when a library such as OpenSSL is patched and you want every application you ship to an illumos host checked, separately from the host's own pkg update.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• illumos project home
• What is illumos? (illumos about page)
• illumos history
• illumos project announcement and transcript
• illumos features
• illumos FAQ
• illumos distributions
• illumos security information
• Jim Grisanzio: OpenSolaris history and source publication list
• OmniOS home and news
• OmniOS release schedule
• OmniOS release notes index
• Upgrading OmniOS
• About OmniOS Community Edition
• OmniOS stable versus bloody
• OmniOS r151058 announcement
• OmniOS r151054 announcement
• OmniOS security alert: CVE-2023-31284
• OpenIndiana home and announcements
• OpenIndiana downloads
• OpenIndiana handbook: getting started
• OpenIndiana security release 2023.05
• OpenIndiana snapshot 2026.04
• SmartOS home
• SmartOS documentation
• SmartOS public release directory
• SmartOS changelog
• Tribblix home
• Tribblix downloads
• OpenZFS documentation
• Oracle Solaris 11 (context only)

Last reviewed: 25 October 2026. Release and support dates change; check the OmniOS schedule and each distribution's announcements for the latest status.