3

I upgraded my Mac to Monterey today, and now I get the following error when I run vagrant up

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'tynesolutions/ruby-node-redis-mysql-ubuntu' version '2.0.0' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 (guest) => 3000 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "047f549a-e0be-48d9-93d5-6b1958594689", "--type", "headless"]

Stderr: VBoxManage: error: The virtual machine 'vm_default_1635193007482_74329' has terminated unexpectedly during startup because of signal 10
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

I tried reinstalling both Vagrant and Virtualbox but no luck.

Improve this question

3 Answers 3

Reset to default
1

This is a known issue and seems to be related to VirtualBox version 6.1.28.

The issue has been solved with the release of VirtualBox version 6.1.30.

There is a healthy and detailed thread in the official HashiCorp repo for Vagrant about this: “Vagrant up issues in Mac OS Monterey #12557”

The issue seems 100% unrelated to VirtualBox 6.1.28 or even the earlier 6.1.26 since people report the same overall behavior.

Note the specific error you have posted:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "047f549a-e0be-48d9-93d5-6b1958594689", "--type", "headless"]

The command that is failing is the default headless option for staring VMs via Vagrant. And the only work-around for now is to set the startup option to gui instead of headless.

As explained in the official Vagrant docs:

GUI vs. Headless

By default, VirtualBox machines are started in headless mode, meaning there is no UI for the machines visible on the host machine. Sometimes, you want to have a UI. Common use cases include wanting to see a browser that may be running in the machine, or debugging a strange boot issue. You can easily tell the VirtualBox provider to boot with a GUI:

config.vm.provider "virtualbox" do |v|
  v.gui = true
end

So just find the config.vm.provider "virtualbox" do block in your Vagrantfile and set that v.gui = true and it should work now; albeit with a GUI popping up which might be a wee bit annoying.

That said, another user in that issue thread states that config.vm.network networking commands might not work.

So this all might boil down to this being fixed in Vagrant 2.2.19? Or maybe VirtualBox is misbehaving as well?

Confusing and annoying, but hopefully this helps in some way.

UPDATE: It seems to be an issue in VirtualBox itself, and not Vagrant. The issue seems to be addressed in ticket number 20636 titled, “VBoxHeadless does not run in macOS Monterey 12.0.1 => fixed in SVN/next maintenance.” And according to a comment by the user “klaus”:

The latest 6.1 test build has the fix, but the usual "not notarized" caveat applies which is documented there, with the "disable SIP" workaround.

UPDATE: Fixed in VirtualBox version 6.1.30; the version 6.1 changelog explicitly references ticket number 20636:

VBoxHeadless: Fixed crash when running on macOS Monterey (bug #20636)

Improve this answer
3

I got an identical error when upgrading to Monterey. No amount of reinstalling seemed to work for me.

What finally worked for me was updating my Vagrantfile to set gui=true for virtualbox:

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
  vb.cpus = 6
  vb.gui = true  # Add this line
end

It's slightly annoying because it opens a VirtualBoxVM window with the console from the VM. But I was able to just minimize this window and it didn't require any input from me to run vagrant up like normal.

Improve this answer
-1

Ran into a similar issue when upgrading to Big Sur. This answer, or one very similar anyway, was the solution for me.

In the end, I had to run through the uninstall, reboot, re-install a couple times before the "Allow" button was tripped.

So, it was a permissions issue.

Improve this answer
3
  • 1
    Please quote the essential parts of the answer from the reference link(s), as the answer can become invalid if the linked page(s) change.
    – DavidPostill ♦
    Commented Oct 27, 2021 at 7:12
  • 1
    @DavidPostill even when the link is an SO link? I'm aware of the guidance you refer to, just wasn't sure it applied to internal links. And I believe I did include the essential bits from the other answer when I referenced what I had to do. That's basically all the other answer said.... uninstall and "allow" the access.
    – JoshP
    Commented Oct 28, 2021 at 15:15
  • 1
    It applies to all links. Content on other SE sites can be and does get deleted.
    – DavidPostill ♦
    Commented Oct 28, 2021 at 15:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .