[bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone

Mantis Bug Tracker noreply at opencsw.org
Sat Sep 4 00:54:28 CEST 2010

A NOTE has been added to this issue. 
Reported By:                gadavis
Assigned To:                phil
Project:                    alternatives
Issue ID:                   4538
Category:                   regular use
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Date Submitted:             2010-08-31 22:19 CEST
Last Modified:              2010-09-04 00:54 CEST
Summary:                    Symbolic links not created in new sparse-root zone
There appears to be a bug in the alternatives mechanism when creating a new
sparse-root zone on Solaris 10 systems.

I have a global zone with CSW alternatives, CSWneon, CSWsudo, and
CSWsudo-common installed. The alternatives mechanism has registered the
symlinks in the right locations and alternatives --display neon and
alternatives --display sudo work as expected.

If I then create a new non-global zone with the default inherited paths
(your typical sparse-root zone), alternatives --display whatever shows the
correct paths listed, but the symlinks are not there.

After zone creation, I have to manually force the alternatives mechanism
to install the needed symlinks by running a shell loop:

for d in `ls /opt/csw/share/alternatives`; do 
	alt=`basename $d`; 
	alternatives --auto $alt; 

Note that if I uninstall CSWsudo inside the zone and then re-install it,
the alternatives mechanism works as expected. It's only upon initial zone
creation that the alternatives symlinks do not get created.

 (0008267) gadavis (developer) - 2010-09-04 00:54
Well, here are my thoughts on it.

Our systems have a baseline Solaris install of SUNW packages that we don't
tweak on a per host basis, at least for those in the /usr tree. I think the
jumpstart cluster used is SUNWcxall

However, the individual zones vary significantly from one another in terms
of their OpenCSW packages. Our development zones have compilers installed,
automake, header files, etc - all stuff that doesn't really belong on a
production system. Often, development and production Zones live on the same
hosting physical system. Even among production systems, there's little
reason for one of our data acquisition hosts to have Apache installed for

In summary, the biggest difference between individual Zones in our
environment is it's selection of CSW packages, not SUNW packages (Sun
Studio being the only notable exception). Having a whole-root zone would
result in a much larger duplication of packages.

More information about the bug-notifications mailing list