Vagrant up fails with VMware provider

[ZimmerHao]

When execute vagrant up, getting this error

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ip -o -0 addr | grep -v LOOPBACK | awk '{print $2}' | sed 's/://'

Stdout from the command:

Stderr from the command:

OS: 13.5.1 (22G90) \ Vagrant: 2.4.0 \ Provider: vmware fusion 13 \ Vagrant Plugin: vagrant-vmware-desktop (3.0.3, global)

Debug output

DEBUG guest: Searching for cap: network_interfaces
DEBUG guest: Checking in: centos
DEBUG guest: Checking in: redhat
DEBUG guest: Checking in: linux
DEBUG guest: Found cap: network_interfaces in linux
 INFO guest: Execute capability: network_interfaces [#<Vagrant::Machine: default (HashiCorp::VagrantVMwareDesktop::Provider)>] (centos)
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: /sbin/ip -o -0 addr | grep -v LOOPBACK | awk '{print $2}' | sed 's/://' (sudo=true)
DEBUG ssh: stderr: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

DEBUG ssh: stderr: sudo
DEBUG ssh: stderr: :
DEBUG ssh: stderr: a password is required

DEBUG ssh: Exit status: 1
ERROR warden: Error occurred: The following SSH command responded with a non-zero exit status.

Expected behavior

Running

Actual behavior

Output error

Reproduction information

Vagrant version

2.4.0

Host operating system

macOS Ventura 13.5.1

Guest operating system

Centos 9

Steps to reproduce

1. vagrant up --provider vmware_desktop

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "gyptazy/centos9-arm64"
  config.vm.box_version = "1.0.0"

  config.vm.network :private_network

  config.vm.provider "vmware_desktop" do |v|
  #   # Display the VirtualBox GUI when booting the machine
    v.gui = false
  #
  #   # Customize the amount of memory on the VM:
    v.vmx["memsize"] = "2048"
    v.vmx["numvcpus"] = "2"
    v.vmx["ethernet0.pcislotnumber"] = "160"
  end
end

[ichilton-fastly]

I'm getting this too with a Debian guest.

Did you manage to fix/work around it?

[clwells]

Seeing this as well:

OS: 14.2.1
Vagrant: 2.4.0
Provider: vmware fusion 13
Vagrant Plugin: vagrant-vmware-desktop (3.0.3, global)

[extralooping]

Same problem here:

OS: 14.1
Vagrant: 2.4.0
Provider: vmware fusion 13.5
Vagrant Plugin: vagrant-vmware-desktop (3.0.3, global)

The author of the vagrant box answered somewhere else, that it is a known problem (=>https://superuser.com/questions/1813100/vagrant-up-fails-with-vmware-provider/1814380), suggesting that it's not a big deal, as vagrant ssh works. For some use cases hover, proper networking is essential. Sadly I was not able to find further information about that known issue or any workaround...

[jburns24]

So I was running into this same issue and figured it out (in my case). The smoking gun was

stderr: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

from vagrant up --debug logs. This told me that the box I was using did not have passwordless sudo correctly configured for the vagrant user. https://developer.hashicorp.com/vagrant/docs/boxes/base#password-less-sudo

Lucky for me I was building my own base box via packer. So in my case the issue was a bug in my preseed file (debian OS). Here is a link to the fix for those that are interested https://github.com/hashicorp/packer-plugin-vmware/pull/141/files#diff-6989dfb636a06edede23b1cfeaead81bff0e5d8df739889695b65cbdbc8dcc45L104-L107

For others being effected by this I would try running your vagrant up with the debug flag. Look carefully through the logs for the instance of something like

INFO ssh: Execute: /sbin/ip -o -0 addr | grep -v LOOPBACK | awk '{print $2}' | sed 's/://' (sudo=true)

The following line should be the real reason that errored. If you see this

DEBUG ssh: stderr: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

Then you are likely dealing with the same issue I had, a misconfigured base box. If you control the base box double check you are giving vagrant passwordless sudo if not make an issue with the box author