For reasons that don't fit within the margins of this entry, I recently had to poke around the pkg system on OmniOS in order to find out some information about packages, such as which package versions are available in the OmniOS repo, what package versions are on the system, and what packages provide certain files.

So, first, versions. pkg packages have a short version and a long one, as so:

$ pkg list kernel
NAME (PUBLISHER)  VERSION
system/kernel     0.5.11-0.151014
$ pkg list -v kernel
FMRI
pkg://omnios/system/kernel@0.5.11-0.151014:20150929T225337Z

(In all my examples, some output is condensed and fields omitted.)

As you might guess from the format of the short version, all kernel packages for OmniOS r151014 have the same short version; they differ only in the timestamp on the long version. This means that if you care about the specific kernel version for some reason you must ask for the long version.

The OmniOS r151014 repo has (at least right now) all kernel versions published for r151014, from the start onwards. You can see all of the available versions with 'pkg list -afv kernel':

$ pkg list -afv kernel
FMRI
pkg://omnios/system/kernel@0.5.11-0.151014:20150929T225337Z
pkg://omnios/system/kernel@0.5.11-0.151014:20150914T195008Z
[...]
pkg://omnios/system/kernel@0.5.11-0.151014:20150402T175237Z

If for some reason you want to install an older kernel, this is what you may need to do to find out its specific full version.

Now, the OmniOS kernel is not delivered in just the kernel package; instead there are a whole collection of packages that contain kernel drivers and other modules. So if you want 'a specific older kernel', you probably want not just the basic kernel package but all of the related drivers to be from that older kernel. This leads to the question of what installed packages on your system supply kernel drivers, and for that we turn to 'pkg contents'. To get a list of all such files along with the package names of the packages that supply them, we want:

$ pkg contents -t file -o path,pkg.name -a 'path=kernel/*'
PATH                    PKG.NAME
kernel/amd64/genunix    system/kernel
[...]
kernel/drv/aac          driver/storage/aac
[...]
kernel/drv/amd64/fct    storage/stmf
[...]
kernel/drv/amd64/fm     service/fault-management
[...]
kernel/drv/amd64/iscsi  network/iscsi/initiator
[...]
kernel/drv/amd64/zfs    system/file-system/zfs
[...]
kernel/fs/amd64/nfs     system/file-system/nfs
[...]
kernel/kmdb/amd64/arp   developer/debug/mdb
[...]

(To get long versions, ask for pkg.fmri instead of pkg.name. I've used short names because this example is already long enough.)

As this rather long example shows, packages from all over the package namespace can wind up providing kernel modules; they are by no means confined to driver/* and system/kernel* as you might innocently initially expect (although those certainly have the majority of kernel-related packages). You might wonder if the versions of all of these packages are tightly tied together so that they must be installed or updated as a set. As far as I know, the answer is that they (mostly?) aren't, apparently because Illumos has a stable kernel module API and most or all kernel modules use it. Whether or not the result works really well is an open question, but the package system itself won't prevent a mix and match situation in my brief testing.

To get just the package names (or FMRIs), we just need the second field like so:

$ pkg contents -t file -H -o path,pkg.fmri -a 'path=kernel/*' |
      awk '{print $2}' | sort -u

This will give us a nice list of specific package versions that are responsible for files under /kernel in our current system.

However, suppose that we've recently updated to the latest r151014 update but the new kernel may have problems in our testing, and what we'd really like to get is the versions of the last kernel. Since a kernel update makes a new boot environment, one option is to just reboot into the old pre-update boot environment and run these 'pkg contents' or 'pkg list' commands. But that might be disruptive to ongoing tests and it turns out that we don't need to, because we can make pkg look at alternate boot environments (although not directly).

First we need to know what boot environments we have:

# beadm list
BE                Active [...]
[...]
omnios-cslab2-2   -
omnios-cslab2-3   NR

Assuming that we want the obvious previous BE, now we need to mount it somewhere:

# beadm -s ro omnios-cslab2-2 /mnt

Now we can look at package information for this old BE by giving pkg the -R option, for example:

$ pkg -R /mnt contents [...]

When you're done, unmount the BE with 'beadm umount'.

This provides a handy and relatively non-intrusive way to recover specific package versions from an old boot environment (or, for that matter, just a list of installed packages).

Sidebar: My sources for this

Some of this is derived from information in the OmniOS wiki's general administration guide. It gives a number of 'pkg contents' examples that were quite helpful. In general 'pkg contents' can be used to do all sorts of things, it's not at all limited to mapping files to packages and packages to files.

Information about 'pkg list' and pointing pkg at alternate BEs is from Lauri Tirkkonen on omnios-discuss in answer to me asking how to do this sort of stuff.