Solaris 11.3 non-global zones not inheriting IPS facet changes (to version-lock)

I have a Solaris 11.3 system without (presently) a support contract. I am therefore using the IPS repository at http://pkg.oracle.com/solaris/release/, which I have now mirrored locally using pkgrecv.

I am using pkg change-facet to change version-lock to false on a large number of packages, such that I can update these packages to their latest version. This works fine.

The 'issue' is that these changed facets are not being inherited by my non-global zones. So while in the global zone I see the changed facet, and can upgrade the affected packages, the same is not true in any non-global zone I later create: it shows the original, unchanged facet, and cannot upgrade the affected packages.

pkg(5) indicates that changes to facets are inherited by child images, such as a non-global zone inheriting from a global zone. But this is not happening for me.

Initially I thought this was a problem, but after further reflection I've realised that in fact I probably wouldn't want facet changes in the global to always inherit into non-globals. This was proved to me when shortly afterwards I found I wanted to install test zones with base software, without changing these facets.

Nonetheless, I'm still confused by the documentation indicating they do inherit, and I believe that ideally there should be a way to configure certain facets to inherit.

Therefore, my questions are:

  1. Is there a way to optionally make certain facets inherit into all non-globals - perhaps by creating a new IPS image?
  2. Why does the IPS documentation indicate facets do inherit - is it talking about only certain types of facets?

This is what I am doing in full:

I have been investigating the use of the new FOSS packages that Oracle provides. I have been following the guide here: How to access selected FOSS Evaluation packages for Oracle Solaris 11.3.

This guide explains that it is necessary to change the facet version-lock to false before packages can be updated, and that updated FOSS packages can be found in bulk in the Release repo with a version number string matching \*@\*-5.12.0.0.0.122. The document recommends manipulating the output of pkg list to create pkg change-facet commands to unlock all versions.

I have done this in my global zone, and subsequently doing pkg update --accept successfully results in a large number of upgraded packages.

But if I then install a new non-global zone, it will default to the base version for these packages. If in that global zone I run pkg facet, I will see the facets are unchanged in the zone. For example, here a zone shows the unchanged version-lock=True for Bash:

root@goldenzone:~# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          True  system

Whereas its global shows the correct, newly changed version-lock=False:

root@magrathea:/system/zones# pkg facet -a | grep version-lock.shell/bash
version-lock.shell/bash                                          False local

Workaround:

As per my comment below, I am now solving this issue by installing my golden zone with custom auto_install manifest that includes <facet set="false">facet.version-lock.*</facet>.

This works OK (albeit at the cost of unlocking all version locks, rather than only those that have FOSS updates), but it would still be good to know if there is a way to make facets inherit between globals and non-globals, as the documentation seems to indicate they should.

Thanks in advance.


I'm one of the primary authors and designers of the Image Packaging System.

I imagine your confusion is due to a misunderstanding of what the documentation states. In particular, note carefully what this sentence from pkg(5) says:

...a non-global zone can inherit a facet from the global zone. Inherited facets are evaluated before, and take priority over, any locally set facets.

Note it says can, not will. So the documentation describes what will happen when facets are inherited, but intentionally (I believe) does not state when they will be inherited. That is, it tells you how to determine whether they are inherited (by looking for "parent" in the SRC column of "pkg facet"), but not under which conditions they will be inherited:

https://docs.oracle.com/cd/E53394_01/html/E54739/glmke.html

Now for the missing part -- in general, inherited facets only usually apply to facet.version-lock.* facets used in packages, because some of the related packages have parent dependencies on themselves like this:

depend type=parent fmri=feature/package/dependency/self

A parent dependency, expressed as above, simply states that to install this package in a non-global zone, the same package must be present at the same version in the global zone first. This is used for packages that must be in-sync between the global and non-global zone(s).

In short, inheritance doesn't usually apply to most facets. The logic for determining which facets will be inherited can be found here:

https://github.com/oracle/solaris-ips/blob/master/src/modules/client/linkedimage/common.py#L3462

This was intentional because zones are a container technology intended to allow isolated environments where administrators can setup configurations that differ from the global zone.

Now with that said, if you want to apply a change-facet operation to the global zone and all non-global zones, you can do so by using the '-r' (recursive) option to change-facet:

pkg change-facet -r ...

(See pkg(1), as apparently I can't post more than two links.)

You can even apply it to specific zones using -z.

Oh, and finally, you really don't want to set the facets to False for all version-locks. Not only will that make the system incredibly slow to update, but you lose all of the safeties that make sure you're actually using a tested combination of components.