Vagrant: VirtualBox 5.x not detected on OS X
Vagrant version
1.84
Latest VirtualBox available from homebrew cask. 5.1.
Host operating system
On a 2012 MBP running the latest OS X 10.11.5.
Guest operating system
N/A
Vagrantfile
vagrant init
Debug output
→ vagrant up --provider virtualbox
No usable default provider could be found for your system.
Vagrant relies on interactions with 3rd party systems, known as
"providers", to provide Vagrant with resources to run development
environments. Examples are VirtualBox, VMware, Hyper-V.
The easiest solution to this message is to install VirtualBox, which
is available for free on all major platforms.
If you believe you already have a provider available, make sure it
is properly installed and configured. You can see more details about
why a particular provider isn't working by forcing usage with
`vagrant up --provider=PROVIDER`, which should give you a more specific
error message for that particular provider.
full debug: http://hastebin.com/gibipinezo
Expected behavior
Virtual Box should be found.
Actual behavior
Virtual Box is not found.
Steps to reproduce
- brew cask install vagrant virtualbox virtualbox-extension-pack
- vagrant init
- vagrant up --provider virtualbox [--install-provider]
References
jhgorse
All 13 comments
This is already fixed on master.
sethvargo
on 14 Jul 2016
I'm experiencing the same issue:
OSX 10.11.5
Vagrant 1.8.4
VirtualBox 5.1.0
SeanROlszewski
on 14 Jul 2016
@sethvargo would you recommend building the latest version of master for those of us experiencing the issue?
SeanROlszewski
on 14 Jul 2016
@sethvargo is there a timeline for when you're going to cut a release?
iankronquist
on 14 Jul 2016
_kicks off the build_
jhgorse
on 14 Jul 2016
using rvm 2.2.4-dev and bundler
git clone https://github.com/mitchellh/vagrant
cd vagrant
bundler
bundle exec vagrant up
works
jhgorse
on 14 Jul 2016
@iankronquist look at the milestone 😄
sethvargo
on 14 Jul 2016
@sethvargo Is there any way to keep a tighter sync with VirtualBox? It seems like this is a bit of a reaction to their 5.1 release, which has been in beta for over a month.
https://github.com/mitchellh/vagrant/commit/b57b0e0d48fe8b4196ca6b7e01bb6c1ecb4b69f9
https://www.virtualbox.org/wiki/News
jhgorse
on 14 Jul 2016
Hi @jhgorse
VirtualBox is just one of many providers. Vagrant has a specific release cycle that has been published long before this beta was even announced.
sethvargo
on 14 Jul 2016
Right. It is also the default provider. The one most folks are using, if I had to speculate.
So I will be more specific. I have only recently jumped into Vagrant-land to evaluate it as an official development methodology, which we may eventually purchase a number of seats for vmware if it works out. When the demos breaks for the default provider for a scheduled and known update from a fairly well-behaved upstream source, it does not inspire the right kind of confidence for the behavior of the paid options.
Furthermore, this is part of the core contract that Vagrant offers to its users: seamless integration and sane error messages for when things eventually break somewhere. So even if it means putting a better error message for if the reported version number does not match the driver's capabilities instead of keeping sync with other trees, so be it. In general, it is difficult to to sell this idea to my colleagues when 25% of my demos don't work when people try them (N=4, multiple tests for each N).
Nevertheless, Vagrant is a good tool with a lot of potential. The integration problem that it attempts to solve is a difficult one and I respect the work you guys do. Keep up the good work and pursue the path to excellence. =)
Cheers,
Joe
jhgorse
on 14 Jul 2016
I understand that there's a well established release cycle for Vagrant, but I feel like there should at least be a very clear indication of the last supported version of providers on the download page at vagrantup.com and maybe a mention in the Getting Started guide.
The release for the next milestone is still a month and half away. I agree that it looks bad and is frustrating for people just starting to try it out until then.
yuters
on 17 Jul 2016
The very least that can be done is to provide a workaround in the meantime.
ferdis
on 18 Jul 2016
@uitgewis There are two workarounds, building a version of Vagrant off of master and downgrading virtualbox. To build vagrant, follow the instructions in the README. To downgrade virtualbox, run the uninstall.tool script which came with virtualbox on the .dmg file, and then download and install virtualbox 5.0, which is still a supported version.
iankronquist
on 18 Jul 2016
Related issues
dorinlazar
·
3Comments
StefanScherer
·
3Comments
barkingfoodog
·
3Comments
lebogan
·
3Comments
bbaassssiiee
·
3Comments
Most helpful comment
Right. It is also the default provider. The one most folks are using, if I had to speculate.
So I will be more specific. I have only recently jumped into Vagrant-land to evaluate it as an official development methodology, which we may eventually purchase a number of seats for vmware if it works out. When the demos breaks for the default provider for a scheduled and known update from a fairly well-behaved upstream source, it does not inspire the right kind of confidence for the behavior of the paid options.
Furthermore, this is part of the core contract that Vagrant offers to its users: seamless integration and sane error messages for when things eventually break somewhere. So even if it means putting a better error message for if the reported version number does not match the driver's capabilities instead of keeping sync with other trees, so be it. In general, it is difficult to to sell this idea to my colleagues when 25% of my demos don't work when people try them (N=4, multiple tests for each N).
Nevertheless, Vagrant is a good tool with a lot of potential. The integration problem that it attempts to solve is a difficult one and I respect the work you guys do. Keep up the good work and pursue the path to excellence. =)
Cheers,
Joe