Version 0.10.0 of the vagrant-vbguest plugin *used* to install for me on OS X 10.8.5, but it now fails similarly to the report in comment #1.

This plugin has been a pain in our butt before. I had a patch which was reverted at some point in the past that cherry-picked the core logic for upgrading the vbguest extensions into our mediawiki-vagrant plugin. As I recall it didn't need a lot of extra libraries. The revert was because of a bug in one particular version of the VirtualBox extensions that caused an install failure. Maybe we should stop using the upstream plugin and restore the simpler middleware.

Right now, setting up MediaWiki-Vagrant may be broken for anyone who doesn't already have the plugin installed (at least on OS X).

I eventually got the plugin to install, but it took a long time and gave some ominous looking warnings along the way:

$ vagrant plugin install vagrant-vbguest
Installing the 'vagrant-vbguest' plugin. This can take a few minutes...
Building nokogiri using packaged libraries.
Building libxml2-2.8.0 for nokogiri with the following patches applied:

• 0001-Fix-parser-local-buffers-size-problems.patch
• 0002-Fix-entities-local-buffers-size-problems.patch
• 0003-Fix-an-error-in-previous-commit.patch
• 0004-Fix-potential-out-of-bound-access.patch
• 0005-Detect-excessive-entities-expansion-upon-replacement.patch
• 0006-Do-not-fetch-external-parsed-entities.patch
• 0007-Enforce-XML_PARSER_EOF-state-handling-through-the-pa.patch
• 0008-Improve-handling-of-xmlStopParser.patch
• 0009-Fix-a-couple-of-return-without-value.patch
• 0010-Keep-non-significant-blanks-node-in-HTML-parser.patch
• 0011-Do-not-fetch-external-parameter-entities.patch ****************

IMPORTANT! Nokogiri builds and uses a packaged version of libxml2.

If this is a concern for you and you want to use the system library
instead, abort this installation process and reinstall nokogiri as
follows:

gem install nokogiri -- --use-system-libraries

If you are using Bundler, tell it to use the option:

bundle config build.nokogiri --use-system-libraries
bundle install

However, note that nokogiri does not necessarily support all versions
of libxml2.

For example, libxml2-2.9.0 and higher are currently known to be broken
and thus unsupported by nokogiri, due to compatibility problems and
XPath optimization bugs.

Building libxslt-1.1.28 for nokogiri with the following patches applied:

• 0001-Adding-doc-update-related-to-1.1.28.patch
• 0002-Fix-a-couple-of-places-where-f-printf-parameters-wer.patch
• 0003-Initialize-pseudo-random-number-generator-with-curre.patch
• 0004-EXSLT-function-str-replace-is-broken-as-is.patch
• 0006-Fix-str-padding-to-work-with-UTF-8-strings.patch
• 0007-Separate-function-for-predicate-matching-in-patterns.patch
• 0008-Fix-direct-pattern-matching.patch
• 0009-Fix-certain-patterns-with-predicates.patch
• 0010-Fix-handling-of-UTF-8-strings-in-EXSLT-crypto-module.patch
• 0013-Memory-leak-in-xsltCompileIdKeyPattern-error-path.patch
• 0014-Fix-for-bug-436589.patch
• 0015-Fix-mkdir-for-mingw.patch ****************

IMPORTANT! Nokogiri builds and uses a packaged version of libxslt.

If this is a concern for you and you want to use the system library
instead, abort this installation process and reinstall nokogiri as
follows:

gem install nokogiri -- --use-system-libraries

If you are using Bundler, tell it to use the option:

bundle config build.nokogiri --use-system-libraries
bundle install

Installed the plugin 'vagrant-vbguest (0.10.0)'!

Thanks. That did the trick. I had to use sudo for some weird reason.
I think I need to straighten out my permissions.
Did a sudo chown -R whoami:staff on the vagrant repo folder, which made 'vagrant up' much happier.

Still not completely without errors but I think it's getting close. I pasted the
full output here: http://pastebin.com/xAW2kuVt

I also see this a couple of time in there:

Installing Virtualbox Guest Additions 4.3.12 - guest version is 4.3.10

Note that I have VirtualBox 4.3.12 installed right now. Should I downgrade to 4.3.10?

I see the virtual machine is running in VirtualBox Manager but I cannot connect to it via http://127.0.0.1:8080/ (503 - Service Unavailable).

http://127.0.0.1:8080/info.php does spit out lots of output.

Tried vagrant reload, which seemed to have no problems. Still Service Unavailable at http://127.0.0.1:8080/. So I tried vagrant provision since that was mentioned in the output from the previous command. This produced some of the earlier error messages.

Forgot to update the pastebin with the reload and the provision output: http://pastebin.com/5aHEpMuH

Also did the vagrant shh at the end, which worked. Again, I think it's getting really close but wondering why I get the 503 when I browse to http://127.0.0.1:8080/ .

(In reply to Bernd Sitzmann from comment #3)

I also see this a couple of time in there:

Installing Virtualbox Guest Additions 4.3.12 - guest version is 4.3.10

Note that I have VirtualBox 4.3.12 installed right now. Should I downgrade
to 4.3.10?

No, running the latest Virtualbox is generally best. This output is the result of the plugin that was having difficulty installing earlier. It's job is to ensure that the Virtualbox kernel extensions inside the guest match your local Virtualbox install.

(In reply to Bernd Sitzmann from comment #4)

Forgot to update the pastebin with the reload and the provision output:
http://pastebin.com/5aHEpMuH

Also did the vagrant shh at the end, which worked. Again, I think it's
getting really close but wondering why I get the 503 when I browse to
http://127.0.0.1:8080/ .

"Uncaught exception: Could not open extension /usr/lib/hphp/extensions/20131007/luasandbox.so" -- Your MediaWiki-Vagrant puppet configuration is out of sync with the HHVM binary that is installed. This should be fixed by updating your MediaWiki-Vagrant git checkout; the config change to support the latest HHVM package (I986205e) was merged recently.

Thanks! I've updated both VirtualBox to the latest 4.3.14 and did the vagrant git-update.

Still getting similar errors: http://pastebin.com/66fHgip8

Again "Uncaught exception: Could not open extension /usr/lib/hphp/extensions/20131007/luasandbox.so"

There's no /usr/lib/hphp directory on my machine.

(In reply to Bernd Sitzmann from comment #6)

Thanks! I've updated both VirtualBox to the latest 4.3.14 and did the
vagrant git-update.

Still getting similar errors: http://pastebin.com/66fHgip8

Again "Uncaught exception: Could not open extension
/usr/lib/hphp/extensions/20131007/luasandbox.so"

There's no /usr/lib/hphp directory on my machine.

Hmmm... was this an existing Vagrant guest VM that you are updating? If so you may need to vagrant destroy; vagrant up to update the guest OS. Check the output of lsb_release -a if you are not sure. MediaWiki-Vagrant is expecting a Ubuntu 14.04 "trusty" base install on the VM. Although if that is the problem I would expect many many more puppet failures.

I think vagrant destroy; vagrant up helped. When I checked the existance of the hphp directory I mistakenly checked on my host box. The file /usr/lib/hphp/extensions/20140702/luasandbox.so actually exists in the guest os.

vagrant@mediawiki-vagrant:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

Here's vagrant reload --provision with errors:
http://pastebin.com/RMMv65Yc

Still 503 on http://127.0.0.1:8080/

I think the problem is that I have /usr/lib/hphp/extensions/20140702/luasandbox.so
but hhvmsh is looking for /usr/lib/hphp/extensions/20131007/luasandbox.so instead.

vagrant@mediawiki-vagrant:~$ hhvmsh
Uncaught exception: Could not open extension /usr/lib/hphp/extensions/20131007/luasandbox.so: /usr/lib/hphp/extensions/20131007/luasandbox.so: cannot open shared object file: No such file or directory

What's the best way to correct this?

(In reply to Bernd Sitzmann from comment #8)

I think the problem is that I have
/usr/lib/hphp/extensions/20140702/luasandbox.so
but hhvmsh is looking for /usr/lib/hphp/extensions/20131007/luasandbox.so
instead.

vagrant@mediawiki-vagrant:~$ hhvmsh
Uncaught exception: Could not open extension
/usr/lib/hphp/extensions/20131007/luasandbox.so:
/usr/lib/hphp/extensions/20131007/luasandbox.so: cannot open shared object
file: No such file or directory

What's the best way to correct this?

This is the state I was expecting in comment #5 when I said:

"Uncaught exception: Could not open extension
/usr/lib/hphp/extensions/20131007/luasandbox.so" -- Your MediaWiki-Vagrant
puppet configuration is out of sync with the HHVM binary that is installed.
This should be fixed by updating your MediaWiki-Vagrant git checkout; the
config change to support the latest HHVM package (I986205e) was merged
recently.

You have a version 3.1+20140723 of the hhvm package installed but the configuration files have not been updated to reflect the ABI (application binary interface) change that hhvm build introduces. Updating your MediaWiki-Vagrant checkout to the latest version and running vagrant provision should correct this. The fix was merged ~17 hours ago. Just in time bug correction. :)

Looks like vagrant git-update still relies on the old extension:

besiair:vagrant besi$ vagrant git-update

> Updating /vagrant/mediawiki ...

Already up-to-date.

> Updating composer dependencies ...

Uncaught exception: Could not open extension /usr/lib/hphp/extensions/20131007/luasandbox.so: /usr/lib/hphp/extensions/20131007/luasandbox.so: cannot open shared object file: No such file or directory

> Updating database ...

(In reply to Bernd Sitzmann from comment #10)

Looks like vagrant git-update still relies on the old extension:

besiair:vagrant besi$ vagrant git-update

> Updating /vagrant/mediawiki ...

Already up-to-date.

> Updating composer dependencies ...

Uncaught exception: Could not open extension
/usr/lib/hphp/extensions/20131007/luasandbox.so:
/usr/lib/hphp/extensions/20131007/luasandbox.so: cannot open shared object
file: No such file or directory

> Updating database ...

Sure, because until you get to the end of vagrant provision hhvm is broken in the VM.

Got it fixed on IRC. Just updating here for documentation purposes:

$ grep hhvm.dynamic_extension_path puppet/modules/hhvm/templates/php.ini.erb
hhvm.dynamic_extension_path = /usr/lib/hphp/extensions/20131007

$ git fetch; git rebase origin/master
$ grep hhvm.dynamic_extension_path puppet/modules/hhvm/templates/php.ini.erb
hhvm.dynamic_extension_path = /usr/lib/hphp/extensions/20140702
$ vagrant provision

All good now :)
http://127.0.0.1:8080/wiki/Main_Page showing up.

(In reply to Bryan Davis from comment #11)

(In reply to Bernd Sitzmann from comment #10)

Looks like vagrant git-update still relies on the old extension:

besiair:vagrant besi$ vagrant git-update

> Updating /vagrant/mediawiki ...

Already up-to-date.

This says that git pull reported the vagrant working dir as up to date, but we proved with the grep commands that was a lie. I'm not sure what happened. :/

Thanks for not giving up Bernd.

Eventually everything worked out. There are probably legitimate bugs to be fixed buried in here, but we wandered all over the place and this became a support ticket more than a bug report. Feel free to open new bugs for any repeatable problems.

I ran into a similar problem with a clean install on OS X 10.9.4. I finally got it working by first installing libiconv from source, and then pointing nokogiri to the libxml2 that came with XCode and telling nokogiri install to use system libraries:

$ sudo /Applications/Vagrant/embedded/bin/gem install --install-dir ~/.vagrant.d/gems nokogiri -v '1.6.3.1' -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2 --use-system-libraries