Vagrant 1.2.2 / VirtualBox 4.2.12 / RedHat 6.4 : The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! /sbin/ifup eth1 2> /dev/null

[dougmcclure]

vagrant 1.2.2 / virtualbox 4.2.12 on win7, trying to build and spin up RedHat 6.4 base box

Tried numerous things I've seen related to ifcfg-eth0 options (onboot, hwaddr, etc.) and the 70-persistent-net.rules with no luck.

Here's a vagrant up with logging on: https://gist.github.com/dougmcclure/5521997

It looks very similar to other problems in this area related to eth0 / eth1 race conditions, etc. There isn't an eth1 set up in the base box I'm exporting from Virtualbox but it's being created during vagrant up.

I have this in ifcfg-eth1 after vagrant up but can't connect to that IP address.

[vagrant@vagrant-redhat64 network-scripts]$ cat ifcfg-eth1
# VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.

BOOTPROTO=none
IPADDR=10.10.10.5
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
# VAGRANT-END
# VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.

BOOTPROTO=none
IPADDR=10.10.10.5
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
# VAGRANT-END
# VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.

BOOTPROTO=none
IPADDR=10.10.10.5
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
# VAGRANT-END

[chorankates]

i'm probably biased, but this looks like #1577 to me

[bjwschaap]

Many people still have this issue. See the latest comments in #921 as well.

I can also reproduce this issue. Using VirtualBox 4.2.12, Vagrant 1.2.2 (from deb package) and this box http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210-nocm.box which gets new guest tools using vagrant-vbguest plugin.

My Vagrantfile:

Vagrant.configure("2") do |config|
   config.vm.box = "centos-64-minimal"
   config.vm.guest = :linux
   config.vm.hostname = "puppet"
   config.vm.network :private_network, ip: "10.10.10.1"  
   config.vm.synced_folder "transfer", "/tmp/transfer"
   config.vm.provider :virtualbox do |vb|
      vb.gui = true
      vb.customize ["modifyvm", :id, "--memory", 1024]
  end

end

Little bit of debug logging:

DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: /sbin/ifdown eth1 2> /dev/null (sudo=true)
DEBUG ssh: stdout: ERROR    : [ipv6_test_device_status] Missing parameter 'device' (arg 1)

DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: cat /tmp/vagrant-network-entry_1 >> /etc/sysconfig/network-scripts/ifcfg-eth1 (sudo=true)
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: /sbin/ifup eth1 2> /dev/null (sudo=true)
DEBUG ssh: stdout: Error, some other host already uses address 10.10.10.1.

DEBUG ssh: Exit status: 1
 INFO retryable: Retryable exception raised: #<Vagrant::Errors::VagrantError: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifup eth1 2> /dev/null>

I've tried the above mentioned workarounds as well, with no luck.

[apelliciari]

i have this issue too. is there an easy workaround?

[jensklose]

Try a vagrant version < 1.2.0

I've found the commit
static is not a valid BOOTPROTO value that
breakes my SLES (SuSE, Novell) box because there is a BOOTPROTO=static.

My ifcfg-eth1 looks like the redhat template and
/etc/ifup eth1 don't work with the new "BOOTPROTO=none" setting.

Please make a solution for SLES and Open Suse guests.

[jensklose]

Why don't you revert the [https://github.com/mitchellh/vagrant/commit/7ed406629b38ecbb90ff29d57083e41ed5d508d0] BOOTPROTO changes?
Yes, the Red Hat and CentOS docs don't listing the "static" value as valid but there are many other distribution around.

The commit doesn't fix any issue but creates some.

[zhenjl]

Same problem here. For me it happens whenever I change the private network IP address on a box that I packaged, and the original box had eth1 configured.

As an example, if I had the following ifcfg-eth1 initially

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
BOOTPROTO=none
IPADDR=172.16.100.11
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

Then I exit, vagrant halt, vi Vagrantfile to change IP to 172.16.100.12, vagrant up, I get

[default] Configuring and enabling network interfaces...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/ifup eth1 2> /dev/null

vagrant ssh, and look at ifcfg-eth1 again, I get 3x the config for the price of 1

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
BOOTPROTO=none
IPADDR=172.16.100.12
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
BOOTPROTO=none
IPADDR=172.16.100.12
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
BOOTPROTO=none
IPADDR=172.16.100.12
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

Even if I manually remove the 2 additional sections and then vagrant halt;vagrant up again, somehow the same config comes back.

rm ifcfg-eth1 and then halt/up again, same problem.

[pauljm]

Having the same problem as zhenjl, including the /sbin/ifup eth1-related error message on vagrant up and config parameters repeated 3x in /etc/sysconfig/network-scripts/ifcfg-eth1.

I have this issue on initial boot—that is, vagrant destroy followed immediately by vagrant up produces the error message above.

The relevant (I believe) portion of my Vagrantfile is

Vagrant.configure('2') do | config |

  # VirtualBox DNS issue
  config.vm.provider :virtualbox do | provider |
    provider.customize [ 'modifyvm', :id, '--natdnshostresolver1', 'on' ]
  end

  config.vm.box = 'centos6'
  config.vm.box_url = 'http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box'

  config.vm.network :private_network, ip: '10.0.99.1'
end

If I vagrant ssh and run sudo /sbin/ifup eth1 I get

Error, some other host already uses address 10.0.99.1.

This leads me to believe that the root cause of the problem may actually be the repeated config parameters rather than the BOOTPROTO value.

[zhenjl]

@pauljm, I was able to make it work by running these commands

rm /etc/sysconfig/network-scripts/ifcfg-eth1
rm /etc/udev/rules.d/70-persistent-net.rules

Before packaging the box.

[pauljm]

Thanks @zhenjl. I gave that a shot. First I deleted both files, halted and re-upped. When that didn't work, I tried deleting them and repackaging, all to no avail.

I did a little more poking around and found that removing the duplicate config params from ifcfg-eth1 and re-running sudo ifup eth1 still gives the same error message:

Error, some other host already uses address 10.0.99.1.

Changing the IPADDR parameter in ifcfg-eth1 to 10. 100 .99.1 and rerunning ifup does work, however.

As a sanity check, I ran vagrant destroy, changed the IP in my Vagrantfile to 10.100.99.1 and ran vagrant up. I still got the error message reported above:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
/sbin/ifup eth1 2> /dev/null

I changed the IPADDR back to the original 10.0.99.1 and ifup succeeded. ifconfig gives:

...

eth1      Link encap:Ethernet  HWaddr 08:00:27:B3:EA:8F  
          inet addr:10.0.99.1  Bcast:10.0.99.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feb3:ea8f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2562 (2.5 KiB)  TX bytes:1454 (1.4 KiB)

...

Whatever is going wrong affects only the IP address specified in the Vagrantfile. So the issue isn't BOOTPROTO or duplicated config params (which was an under-reasoned conclusion on my part), but something else.

I now suspect the culprit is VirtualBox's network interface on the host:

vboxnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 0a:00:27:00:00:00 
    inet 10.100.99.1 netmask 0xffffff00 broadcast 10.100.99.255

Sure enough, ping 10.100.99.1 from the Vagrant box gets a response.

Gonna have to dig into VBox networking details a little.

[pauljm]

The problem here is VirtualBox's host only network interface, vboxnet0, on the host machine.

Normally, vboxnet0 is the host's interface to the guest's private network. The problem is that, until the corresponding interface on the guest machine—eth1 in this case—comes up, vboxnet0 loops back to the host.

On startup, the Vagrant box's eth0 interface is connected to a NAT adapter—effectively a virtual router between the box and the host. When Vagrant tries to bring up eth1 with the private IP specified in Vagrantfile, the box broadcasts an ARP request, the NAT routes it to vboxnet0, vboxnet0 forwards it to the host, and the host responds that the address is already taken.

That vboxnet0 loops back to the host until connected to the guest machine is strange behavior; I would have expected it to be a black hole until connected up to the guest. On some level, this is a VirtualBox, not a Vagrant, issue.

One solution might be to bring the private network up on eth0 and then the NAT on eth1.

In my case, I don't need the host to be able to access the box at its private IP (vagrant ssh is enough), so the solution was to add:

config.vm.provider :virtualbox do | provider |
    provider.customize [ 'modifyvm', :id, '--nic2', 'intnet' ] # nic2 corresponds with eth1
end

This causes VBox to switch nic2 to an internal network, which isn't accessible from the host and so doesn't have a corresponding vboxnet interface on the host. This overrides Vagrant's attempt to configure it at a host-only network:

INFO subprocess: Starting process: ["VBoxManage", "modifyvm", "cacf5428-2286-4ea6-ab0e-044ba1d334d6", "--nic1", "nat", "--nic2", "hostonly", "--hostonlyadapter2", "vboxnet0"]
...
INFO subprocess: Starting process: ["VBoxManage", "modifyvm", "cacf5428-2286-4ea6-ab0e-044ba1d334d6", "--nic2", "intnet"]

Strangely, the vboxnet0 interface survives; it just doesn't interfere with bringing up eth1. Will post back if I get any more clarity on that.

[aknrdureegaesr]

Some of these could be an instance of the problem that I ask be fixed with #2519, maybe?

[jason-ni]

Hi @pauljm , I think @zhenjl solution should work for rhel6.4 boxing. I did like that, not rm but deleted the line of eth1. The key is that after you delete the udev rule for eth1, you should just shutdown the vm and package it, instead of up it again. Udev rules for eth1 will be generated automatically when vm upped.

[mitchellh]

Sorry to do this, but I need a fresher repro case with a newer version of Vagrant to test this. I'm actually unsure anymore if this still exists or if it is exists in the same form, since a lot of updates have gone into the RHEL code.

[pvoznenko]

So guys, anyone found out how to fix it? since @zhenjl solution works after box is created. So if you base box I remove eth1 configure and create from it new box - new box for some reason comes with eth1 error :(

[pvoznenko]

so it looks like error happened only on machine where box was build. so you should fix it only for your self with @zhenjl solution.