Last modified: 2014-08-28 20:32:07 UTC
on OS X 10.9.4 $ vagrant plugin install vagrant-vbguest Installing the 'vagrant-vbguest' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: An error occurred while installing nokogiri (1.6.3.1), and Bundler cannot continue. Make sure that `gem install nokogiri -v '1.6.3.1'` succeeds before bundling. $ ls -l $(which vagrant) lrwxr-xr-x 1 root wheel 33 Jul 22 16:14 /usr/bin/vagrant -> /Applications/Vagrant/bin/vagrant $ vagrant --version Vagrant 1.6.3
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
