== Some notes on finding package versions in OmniOS with _pkg_ 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: .pn prewrap on $ 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 http://omnios.omniti.com/wiki.php/ReleaseNotes/r151014]] 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 http://omnios.omniti.com/wiki.php/GeneralAdministration]]. 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 http://permalink.gmane.org/gmane.os.omnios.general/5324]] in answer to me asking how to do this sort of stuff.