virtualbox.org

Hi-

I just installed vbox 4.2.16 on solaris 11.1 (latest SRU) and got the following:

< normal pkgadd output up until .....>

## Executing postinstall script.
Checking for older bits...
Installing new ones...
Detected Solaris 11 Version 175
Loading VirtualBox kernel modules...
- Loaded: Host module
- Loaded: NetAdapter module
- Loaded: NetFilter (Crossbow) module
- Loaded: USBMonitor module
- Loaded: USB module
Configuring services...
svcadm: svc:/application/virtualbox/zoneaccess:default is misconfigured (lacks "restarter" property group).
* Warning!! Loading Zone access service ...FAILED.
* Warning!! Refer for details.
Installing MIME types and icons...
Installing Python bindings...
- Installed: Bindings for Python 2.6
Updating the boot archive...

Installation of <SUNWvbox> was successful.

--------------------

The tail end of the log file (/var/svc/log/application-virtualbox-zoneaccess:default.log) shows the following:

[ Jul 12 13:46:14 Method "start" exited with status 0. ]
[ Jul 12 13:51:29 Stopping because service disabled. ]
[ Jul 12 13:51:29 Executing stop method (:kill). ]
[ Jul 12 13:54:07 Enabled. ]
[ Jul 12 13:54:07 Executing start method ("/opt/VirtualBox/VBoxZoneAccess"). ]
[ Jul 12 13:54:07 Method "start" exited with status 0. ]
[ Jul 12 13:54:07 Rereading configuration. ]
[ Jul 12 13:54:07 No 'refresh' method defined. Treating as :true. ]

------------------

Can I assume the lack of a restarter method in the manafest is harmless based on the log treating it as true?

Bob

This looks like a race while importing the SMF service. I'll take a look at the installer, perhaps we need to wait until the full import has finished before attempting to start / restart the service.

I know this stuff changed somewhere in S11 and the waiting is kinda ugly. Thanks for the report.

The zoneaccess service is only needed for running VirtualBox from a Solaris zone. If you're not doing that, you can safely disable the service or don't have to worry if importing/starting it failed.

The fix should be fixed in the next major release; this hasn't been backported to 4.2.x branch yet, mainly because I'm not yet convinced this warrants a backport. Thanks again for the report.