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

84564221 · 2013-05-29T19:43:34Z

vagrant up node1

Error

[node1] 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

I've tried the following

vagrant ssh -c "sudo /sbin/ifup eth1 2> /dev/null"
Device eth1 does not seem to be present, delaying initialization.

The text was updated successfully, but these errors were encountered:

mconigliaro · 2013-05-30T05:27:36Z

This often means you already have another VM running with the same IP address.

jistanidiot · 2013-06-07T18:23:46Z

I've had this problem before. For me, it was related to this "notabug" bug from redhat https://bugzilla.redhat.com/show_bug.cgi?id=491432 where ethX doesn't always refer to the same interface if you don't have HWADDR set in the ifcfg-ethX file.

mitchellh · 2013-06-09T22:30:18Z

I need a lot more information:

Vagrantfile
Guest OS being used (answered by Vagrantfile usually)
Debug level logs

ghost · 2013-06-11T08:46:46Z

I have the same bug, it happens when I set the IP address manually

Vagrantfile excerpt:

        config.vm.define :builder do |builder|
                builder.vm.hostname = "builder"
                builder.vm.network :private_network, ip: "10.0.5.2"

                # Yum repository
                builder.vm.network :forwarded_port, guest: 80, host: 8088

                # Puppet provisioning
                builder.vm.provision :puppet do |puppet|
                puppet.manifests_path = "manifests"
                puppet.manifest_file  = "builder.pp"
                puppet.module_path = "manifests"
            end
        end

From the host I get:

   $ vagrant ssh builder -c "sudo /sbin/ifup eth1"
   Error, some other host already uses address 10.0.5.2.

From within the VM:

[vagrant@builder ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:95:60:67 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
    inet6 fe80::a00:27ff:fe95:6067/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:10:e2:fa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe10:e2fa/64 scope link 
       valid_lft forever preferred_lft forever

eth1 has not been configured. I suspect the destroy command to not totally cleanup network configuration, because as far as I can remember it always happens after I destroyed a VM.

If you tell me how to print debug level logs, I can try to provide them in this thread.

walesmd · 2013-06-11T09:21:26Z

I ran into this tonight as well. Let me preface this with saying I'm doing some stuff well beyond Vagrant's intended usage - so I'm not asking for support, just providing more information so that @mitchellh can debug other's issues if need be.

In my case, I just remove all of the VMs directly from within VirtualBox and spin them back up with Vagrant. I'm only in need of one at a time but have multiple copies of it from time to time during the process of packaging.

To reproduce (not sure if all steps required, particularly the "in VirtualBox" steps):

vagrant up a VirtualBox VM (CentOS 6.4 in my case)
vagrant package --output debugging.box
Make a copy of your project's directory, ie: cp vagrant-original vagrant-backup
Clone the VM directly within VirtualBox app, ie: vagrant-original to vagrant-clone
Delete the original VM directly within VirtualBox
Switch to the vagrant-backup directory, add your new box vagrant box add debugging ./debugging.box
vagrant init debugging
vagrant up - the error appears after Configuring and enabling network interfaces

Vagrantfiles, logs and my launcher script can be found here.

ikarishinjieva · 2013-06-21T09:34:25Z

remove /etc/udev/rules.d/70-persistent-net.rules before packing works for me.

iffy · 2013-06-27T20:20:05Z

I just ran into this using a packaged box. My Vagrantfile is this:

Vagrant.configure("2") do |config|
  config.vm.box = "centos64"
  config.vm.box_url = "http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box"
  config.vm.network :public_network
end

I packaged like this:

vagrant package --output webv3.27jun2013-2.box --vagrantfile Vagrantfile

I suspended the first vm:

vagrant suspend

I added the box and initialized a directory:

vagrant box add testing http://10.1.15.7:7007/webv3.27jun2013-2.box
mkdir foo
cd foo
vagrant init testing

Then vagrant up looked like this:

14:04:22 [matt] ~/vagrant/foo $ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'testing'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Available bridged network interfaces:
1) en0: Ethernet
2) en1: AirPort
3) vmnet1
4) vmnet8
What interface should the network bridge to? 1
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
cause things such as shared folders to not work properly. If you see
shared folder errors, please update the guest additions within the
virtual machine and reload your VM.

Guest Additions Version: 4.2.12
VirtualBox Version: 4.1
[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

The guest OS is CentOS (see the box in the top Vagrantfile)
Vagrant version 1.2.2
Oracle VM VirtualBox Manager 4.1.14

parnurzeal · 2013-07-02T07:01:51Z

remove /etc/udev/rules.d/70-persistent-net.rules before packing works for me too.
Any reason why???

tsechingho · 2013-07-03T10:22:41Z

@mconigliaro is RIGHT. It must be some VMs still running with network config same as what you want to run.

I vagrant up a VM, rename the project containing this vagrantfile without vagrant halt first.
I would get such /sbin/ifup eth1 2> /dev/null error when i vagrant up again.
Because default name of VM is named by project folder name, there would be two VMs runing with same network config.

jbpadgett · 2013-07-05T04:25:36Z

Deleting /etc/udev/rules.d/70-persistent-net.rules and removing mac entries from ifcfg-eth0 then re-creating the box file (CentOS6.4) and then doing a fresh vagrant up did not work for me.
Taking my Vagrantfile and removing any :private_network entries did however work. The VMs were booted and were as expected given a random DHCP address instead of the ones I had specified. This is not the behavior I want however.
Example) vm1.vm.network :private_network, ip: "192.168.56.71"
So, perhaps the issue is related to DHCP being configured in the ifcfg-ethx file in the base box and vagrant configuring a static IP in :private_network in the Vagrantfile?

renatogabrielbr · 2013-08-16T02:50:09Z

Centos 6.4
Deleting /etc/udev/rules.d/70-persistent-net.rule
vagrant reload box

worked fine for me.

XXBlackieXX · 2013-08-23T10:15:25Z

vagrant ssh then rm -f /etc/udev/rules.d/70-persistent-net.rule BEFORE vagrant package worked nice for me!

Vagrant 1.2.7
CentOS 6.4

I modified the box (http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-i386-v20130427.box) like installing httpd, mysql, etc, then simply packaged it. After that, I attempted to vagrant this package up. But following error came up.

[node1] 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

So I did
vagrant ssh
rm -f /etc/udev/rules.d/70-persistent-net.rule
rm -f /etc/sysconfig/network-scripts/ifcfg-eth1
vagrant reload
However this also gave me the same error and both 70-persistent-net.rule and ifcfg-eth1 files are regenerated.
After reloading the VM, ifcfg-eth1 is looked like this.

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
BOOTPROTO=none                                                                                                 
IPADDR=192.168.33.10
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=192.168.33.10
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=192.168.33.10
NETMASK=255.255.255.0
DEVICE=eth1
PEERDNS=no
#VAGRANT-END

Not related to how many times I did vagrant reload this VM, the description in ifcfg-eth1 was repeated 3 times.
Though this doesn't seem to be the cause of this issue, this was perhaps written by following script in vagrant-1.2.7/plugins/guests/redhat/cap/configure_networks.rb, t

48    retryable(:on => Vagrant::Errors::VagrantError, :tries => 3, :sleep => 2) do
49        machine.communicate.sudo("/sbin/ifdown eth#{interface} 2> /dev/null", :error_check => false)
50        machine.communicate.sudo("cat /tmp/vagrant-network-entry_#{interface} >> #{network_scripts_di    r}/ifcfg-eth#{interface}")
51        machine.communicate.sudo("ARPCHECK=no /sbin/ifup eth#{interface} 2> /dev/null")
52    end

Hope this issue to be fixed :)

pedroresende · 2013-08-28T15:01:29Z

I'm also having the same problem than @XXBlackieXX , but using http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box ... Any ideia when this issue will be fixed ?

pedroresende · 2013-08-28T15:35:19Z

After updating vagrant to 1.2.7, and using a private ip starting on .2, since .1 I get the following error

There are errors in the configuration of this machine. Please fix the following errors and try again:

vm:
* Static IPs cannot end in ".1" since that address is always
reserved for the router. Please use another ending.

it started working correctly, the ip I've used is 10.0.5.2

pedroresende · 2013-08-29T11:20:12Z

After investigating a bit more, I found out that the problem is related with the eth card. If you choose a different card (i.e. wlan0) it works correctly.

mitchellh · 2013-09-01T05:47:21Z

This was related to boxes it appears. Closing. Thanks!

casr · 2013-12-16T14:08:41Z

This was related to boxes it appears. Closing. Thanks!

Has the behaviour for bringing up a private network changed between v1.3.5..v1.4.0? Previously, Vagrant was able to bring up the second network interface, eth1, but this now fails in v1.4.0. I've patched[1] my Vagrant box so that it always activates eth1 on boot now but this wasn't required before.

So is this still an issue for boxes to be concerned about or a new bug in Vagrant?

tmatilai · 2013-12-16T14:13:16Z

@casr You're hitting #2614, which will be fixed in the next point release.

casr · 2013-12-16T14:17:28Z

@tmatilai Cheers for the info!

kjprince · 2014-02-13T05:36:09Z

Debian squeeze

rm -rf /etc/udev/rules.d/70-persistent-net.rule

Worked for me too.

tsigian · 2014-02-16T13:43:39Z

To my point of view and what i do for my CentOS box is:

--Each MAC should be unique, so if you have HWADDR or UUID in your box/template ifcfg-eth0 your clones will obtain the same. So you have to delete them for your box before packaging.
--70-persistent-net.rules keeps persistent rules for net interfaces, so it should be deleted.
--ifcfg-eth1 will be created by vagrant for every new clone, so it should be deleted from the box too.

before packaging:
rm -rf /etc/udev/rules.d/70-persistent-net.rules
sed -i '/HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
sed -i '/UUID/d' /etc/sysconfig/network-scripts/ifcfg-eth0
rm -rf /etc/sysconfig/network-scripts/ifcfg-eth1

You create the box with "vagrant package" and you should have any issues while create new hosts based on that box

svpernova09 · 2014-02-17T19:15:38Z

Having the same issue with this setup:

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'My-Awesome-VagrantBox'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Running 'pre-boot' VM customizations...
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[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!

ARPCHECK=no /sbin/ifup eth1 2> /dev/null

Stdout from the command:

Device eth1 does not seem to be present, delaying initialization.


Stderr from the command:


vagrant up: 01:21

Host:

Mint 16 (wheezy/sid)
Virtualbox 4.3.6 r91406
- Extentions: 4.3.6r91406
Vagrant 1.4.3

Guest:

CentOS release 6.5 (Final)

Running sudo rm /etc/udev/rules.d/70-persistent-net.rules in my guest before packaging fixes the issue.

kikitux · 2014-02-18T00:33:43Z

those are issues with the boxes, rather than vagrant.

glad you fix the box.

On Tue, Feb 18, 2014 at 8:15 AM, Svpernova09 notifications@github.51.alwrote:

Having the same issue with this setup:

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'My-Awesome-VagrantBox'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Running 'pre-boot' VM customizations...
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[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!

ARPCHECK=no /sbin/ifup eth1 2> /dev/null

Stdout from the command:

Device eth1 does not seem to be present, delaying initialization.

Stderr from the command:

vagrant up: 01:21

Host:

Mint 16 (wheezy/sid)

Virtualbox 4.3.6 r91406

Extentions: 4.3.6r91406

Vagrant 1.4.3

Guest:

CentOS release 6.5 (Final)

Running sudo rm /etc/udev/rules.d/70-persistent-net.rules in my guest
before packaging fixes the issue.

Reply to this email directly or view it on GitHubhttps://github.com//issues/1777#issuecomment-35314019
.

b-long · 2014-02-26T01:27:35Z

I assume this is related to the wiki page "vagrant up hangs at "Waiting for VM to boot. This can take a few minutes"" , right? Since the solution to this seems to be properly building (and removing) network configuration files before the box is packaged, is this common issue enumerated somewhere? Any plans to enforce the convention during the packaging of a box? I also saw talk of this on the mailing list; essentially following these steps (and then re-packaging) fixed my issue: Re: vagrant up hangs for a newly created Fedora 19 box. Can't login?.

bmorg · 2014-02-27T19:51:41Z

Adding some information concerning the udev problem in Debian Squeeze:

udev persists the mapping MAC address <-> interface name in the file /etc/udev/rules.d/70-persistent-net.rules.

If you delete that file before packaging, it will be created again at the next boot.

There are actually some rules already to not create this mapping inside a virtual machine. Unfortunately the required rule for Virtualbox was only added in Wheezy.

Fix for Debian Squeeze

To fix this permanently, you need to:

Copy the generator rules to /etc:

$  cp /lib/udev/rules.d/75-persistent-net-generator.rules /etc/udev/rules.d/

Edit the new file /etc/udev/rules.d/75-persistent-net-generator.rules, find the following block...

# ignore interfaces with locally administered or null MAC addresses
# and KVM and VMWare virtual interfaces
ENV{MATCHADDR}=="?[2367abef]:*",        ENV{MATCHADDR}=""
ENV{MATCHADDR}=="00:00:00:00:00:00",    ENV{MATCHADDR}=""
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", ENV{MATCHADDR}=""
ENV{MATCHADDR}=="52:54:00:*|54:52:00:*", ENV{MATCHADDR}=""

... and add this line at the end:

ENV{MATCHADDR}=="08:00:27:*",       ENV{MATCHADDR}=""

Now remove the mapping file for the last time:

$ rm -rf /etc/udev/rules.d/70-persistent-net.rules

That's it!

For more about udev rules files see the section Rules files in the udev manual.

b-long · 2014-02-27T20:00:16Z

@bmorg I really appreciate the response, that information is really helpful. Does Vagrant provide some sort of FAQ for building a .box file? I should have given more info here, but I did give more information on the mailing list (see here). I assume this issues presents itself in a handful of linux environments (not just debian-based distros)?

tartley · 2014-09-03T10:14:03Z

This is an issue for me and others on my team.
Our host is Ubuntu 14.04.1.
Our guest image is Debian 6.0.4 with a few packages installed (e.g. Python libraries)
How to I get debug logs?
Our Vagrantfile:

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # web machine runs ERP application
  config.vm.define "web" do |web|
    web.vm.box = "erp-base"
    web.vm.provision :shell, path: "bootstrap.sh"
    web.vm.network "forwarded_port", guest: 8180, host: 8069, auto_correct: true
    web.vm.network "forwarded_port", guest: 22, host: 8888, auto_correct: true
    web.vm.network "private_network", ip: "192.168.50.4"
    web.vm.synced_folder "..", "/opt/openerp/development-6.1",
        owner: "openerp", group: "openerp"
    web.vm.synced_folder "../../3rd-party-addons", "/opt/openerp/3rd-party-addons",
        owner: "openerp", group: "openerp"
  end

  # db machine runs postgres
  config.vm.define "db" do |db|
    db.vm.box = "erp-database"
    db.vm.provision :shell, path: "bootstrap_db.sh"
    db.vm.network "private_network", ip: "192.168.50.5"
    db.vm.network :forwarded_port, id: "ssh", guest: 22, host: 2223
  end

  # Provider-specific configuration for VirtualBox
  config.vm.provider "virtualbox" do |vb|
    # Use VBoxManage to customize the VM. For example to change memory:
    vb.memory = 2048
    vb.cpus = 2
  end

end

ryanschmidt · 2014-09-25T14:20:13Z

Any fix for a *.box file that did not first have the /etc/udev/rules.d/70-persistent-net.rules file removed? I'm stuck...

tsigian · 2014-09-25T14:22:20Z

you should be able to 'vagrant ssh' into it. then remove the line and reboot

2014-09-25 15:20 GMT+01:00 Ryan Schmidt notifications@github.com:

Any fix for a *.box file that did not first have the
/etc/udev/rules.d/70-persistent-net.rules file removed? I'm stuck...

—
Reply to this email directly or view it on GitHub
#1777 (comment).

ryanschmidt · 2014-09-25T14:28:38Z

Thanks so much @tsigian! This fixed it for me: #1777 (comment)

lattera · 2015-02-24T19:45:31Z

I have a VirtualBox VM that is set up as a DHCP, DNS, and firewall that has an IP of 192.168.1.1. This VM serves Internet access to the rest of my VMs. Vagrant not allowing me to use a .1 address for that VM is really going to cause headaches going forward. Is there any way to force Vagrant to allow me to use 192.168.1.1?

GabLeRoux · 2015-04-05T18:01:01Z

I had a similar problem on a slow network, I commented config.vm.network :public_network from my Vagrantfile as I don't need that feature atm. In my case, I think my vm didn't close properly last time, anyway, if this can help someone.

Here's what I had before:

vagrant up
1
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Couldn't find Cheffile at ./Cheffile.
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) en1: Wi-Fi (AirPort)
2) en0: Ethernet
3) p2p0
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
    default: Which interface should the network bridge to? ==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
    default: Adapter 3: bridged
==> default: Forwarding ports...
    default: 3306 => 3333 (adapter 1)
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...


    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> 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!

ARPCHECK=no /sbin/ifup eth2 2> /dev/null

Stdout from the command:


Determining IP information for eth2...PING 10.0.2.1 (10.0.2.1) from 10.0.2.53 eth2: 56(84) bytes of data.

--- 10.0.2.1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3006ms
pipe 3
 failed.


Stderr from the command:

nckrse · 2015-04-09T19:22:26Z

I added a second network:
config.vm.network "private_network", ip: "192.168.33.10"

And got the same error but for some reason, it was because eth2 was the created interface and not eth1... Fixed with:
~ $ sudo sed -i 's/eth1/eth2/' /etc/sysconfig/network-scripts/ifcfg-eth1
~ $ sudo /sbin/ifup eth1
Determining if ip address 192.168.33.10 is already in use for device eth2...
~ $

holms · 2015-05-13T00:56:25Z

I've sold it like this: holms/vagrant-centos7-box@030375653a
Also you need to set only second adapter ip, not the first one: config.vm.network "private_network", ip: "10.1.1.5", :adapter => 2

svpernova09 · 2015-07-09T23:18:01Z

I gave up on this long ago, (not long after my previous comment) and I ran into this again tonight where CentOS 7 wasn't getting the private_network interface, wanted to mention that @holms comment of adding , :adapter => 2 seems to have solved this for me. Thanks!

iyoung · 2015-08-05T14:36:54Z

Just running vagrant up, seeing the issue described above, I was able to resolve this by just running vagrant ssh, then removing /etc/udev/rules.d/70-persistent-net.rules, exiting, running vagrant halt; vagrant up and all was fine.

ghost · 2016-02-22T10:34:37Z

I uninstalled vagrant and virtualbox and reinstalled, there was no problem again.

taylorotwell · 2016-05-01T02:54:30Z

Getting this on bento/ubuntu-16-04 box. :(

balous · 2016-05-02T11:25:38Z

I am getting this error on ubutnu 16.04. I guess the cause is that ubuntu now uses different names for ethernet interfaces:

vagrant@base-ubuntu-xenial:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:63:c5:ab brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe63:c5ab/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:af:e3:8b brd ff:ff:ff:ff:ff:ff

vagrant@base-ubuntu-xenial:~$ dmesg | grep eth
[    1.317883] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:63:c5:ab
[    1.317889] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.797896] e1000 0000:00:08.0 eth1: (PCI:33MHz:32-bit) 08:00:27:af:e3:8b
[    1.797900] e1000 0000:00:08.0 eth1: Intel(R) PRO/1000 Network Connection
[    1.799479] e1000 0000:00:03.0 enp0s3: renamed from eth0
[    1.815309] e1000 0000:00:08.0 enp0s8: renamed from eth1

xwdeng · 2016-05-31T02:45:08Z

I agree with balous and I have the same problem. what should I do next?

HeathNaylor · 2016-06-13T20:58:41Z

Getting this on ubuntu/xenial64 when using private network.\

Note, private networking works with geerlingguy/ubuntu1604. Not really sure what he did to get it working.

masonfox · 2016-07-25T00:40:48Z

Was able to fix this with a complete uninstall of vagrant and adding the box again. Followed the uninstallation directions here.

dylanninin · 2016-11-02T06:16:09Z

Thanks for @masonfox

pgporada · 2017-03-15T16:52:35Z

I have something similarly related in #8373 on Centos7. I did the following

vagrant up # fails, but it's "ok"
vagrant ssh
sudo su -
mv /etc/sysconfig/network-scripts/ifcfg-enp0s3 /etc/sysconfig/network-scripts/OFF_ifcfg-enp0s3
exit
exit
vagrant reload

crazytan · 2017-04-06T17:59:48Z

@pgporada you are a hero!!!!!

CeuxDruman · 2017-09-12T09:11:01Z

I fixed it!

SO: Ubuntu 16.04.2
MV for vagrant: virtualbox

I had vagrant installed via apt-get, but it seems to be broken/downgraded/bugged.
My solution was to uninstall and reinstall it from the official website package:

Unsinstall vagrant
sudo apt-get remove --purge vagrant
Delete ".vagrant" directory from your MV (Don't need to delete it or change Vagrantfile)
sudo rm -rf <your_mv_directory>/.vagrant/
Install Vagrant package from the official website: https://www.vagrantup.com/downloads.html (In my case: https://releases.hashicorp.com/vagrant/2.0.0/vagrant_2.0.0_x86_64.deb?_ga=2.157298489.244283658.1505144298-1807825711.1505144298)
Run it!
vagrant up

dmytro-y-dev · 2017-11-22T23:09:22Z

I use Mint 18.2 and apt version of vagrant was failing with same error. Installation of newer release from Vagrant's official website solved the problem (see explanation at https://askubuntu.com/questions/760871/network-settings-fail-for-ubuntu-xenial64-vagrant-box).

hadley8899 · 2018-01-24T19:16:50Z

This may not be the fix for most but i ran into this problem today and this was the first result on google
I am using a bento/ubuntu-17.10 and ran into this same issue. I cured it by doing vagrant up, SSHing into the box and install
ifupdown

sudo apt-get install ifupdown

Worked perfectly straight after

ghost · 2020-03-31T01:57:58Z

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

mitchellh closed this as completed Sep 1, 2013

mitchellh mentioned this issue Sep 1, 2013

Centos 6.3 public_network setup fails #1771

Closed

jabclab mentioned this issue Sep 16, 2013

vagrant package results in box with no guest additions #2198

Closed

scribu mentioned this issue Dec 16, 2013

/sbin/ifdown error when setting static IP 2creatives/vagrant-centos#3

Closed

jong99 mentioned this issue Jul 25, 2014

Centos 7: Error "Device eth1 does not seem to be present" with private network jedi4ever/veewee#970

Closed

This was referenced Mar 27, 2015

Create Fedora 21 box chef/bento#312

Closed

chef/fedora-21 chef/bento#333

Closed

This was referenced Jul 26, 2015

Authentication appears to fail for CentOS 6.x Base Boxes jrgriffiniii/vagrant-islandora#1

Open

Authentication appears to fail for CentOS 6.x Base Boxes jrgriffiniii/vagrant-fedoragsearch#1

Open

clong mentioned this issue Dec 15, 2017

Interface Error upon Vagrant Up clong/DetectionLab#28

Closed

ghost locked and limited conversation to collaborators Mar 31, 2020

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

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

Comments

84564221 commented May 29, 2013

mconigliaro commented May 30, 2013

jistanidiot commented Jun 7, 2013

mitchellh commented Jun 9, 2013

ghost commented Jun 11, 2013

walesmd commented Jun 11, 2013

ikarishinjieva commented Jun 21, 2013

iffy commented Jun 27, 2013

parnurzeal commented Jul 2, 2013

tsechingho commented Jul 3, 2013

jbpadgett commented Jul 5, 2013

renatogabrielbr commented Aug 16, 2013

XXBlackieXX commented Aug 23, 2013

pedroresende commented Aug 28, 2013

pedroresende commented Aug 28, 2013

pedroresende commented Aug 29, 2013

mitchellh commented Sep 1, 2013

casr commented Dec 16, 2013

tmatilai commented Dec 16, 2013

casr commented Dec 16, 2013

kjprince commented Feb 13, 2014

tsigian commented Feb 16, 2014

svpernova09 commented Feb 17, 2014

kikitux commented Feb 18, 2014

b-long commented Feb 26, 2014

bmorg commented Feb 27, 2014

Fix for Debian Squeeze

b-long commented Feb 27, 2014

tartley commented Sep 3, 2014

ryanschmidt commented Sep 25, 2014

tsigian commented Sep 25, 2014

ryanschmidt commented Sep 25, 2014

lattera commented Feb 24, 2015

GabLeRoux commented Apr 5, 2015

nckrse commented Apr 9, 2015

holms commented May 13, 2015

svpernova09 commented Jul 9, 2015

iyoung commented Aug 5, 2015

ghost commented Feb 22, 2016

taylorotwell commented May 1, 2016

balous commented May 2, 2016 • edited Loading

xwdeng commented May 31, 2016

HeathNaylor commented Jun 13, 2016 • edited Loading

masonfox commented Jul 25, 2016

dylanninin commented Nov 2, 2016

pgporada commented Mar 15, 2017 • edited Loading

crazytan commented Apr 6, 2017

CeuxDruman commented Sep 12, 2017

dmytro-y-dev commented Nov 22, 2017

hadley8899 commented Jan 24, 2018

ghost commented Mar 31, 2020

balous commented May 2, 2016 •

edited

Loading

HeathNaylor commented Jun 13, 2016 •

edited

Loading

pgporada commented Mar 15, 2017 •

edited

Loading