search

hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.26k stars 4.43k forks source link

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

Closed 84564221 closed 11 years ago

84564221 commented 11 years ago 
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.
mconigliaro commented 11 years ago

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

jistanidiot commented 11 years ago

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 commented 11 years ago

I need a lot more information:

ghost commented 11 years ago

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 commented 11 years ago

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):

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

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

ikarishinjieva commented 11 years ago

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

iffy commented 11 years ago

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 commented 11 years ago

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

tsechingho commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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

worked fine for me.

XXBlackieXX commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

casr commented 10 years ago

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 commented 10 years ago

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

casr commented 10 years ago

@tmatilai Cheers for the info!

kjprince commented 10 years ago

Debian squeeze

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

Worked for me too.

tsigian commented 10 years ago

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 commented 10 years ago

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:

Guest:

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

kikitux commented 10 years ago

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.comwrote:

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/mitchellh/vagrant/issues/1777#issuecomment-35314019 .

b-long commented 10 years ago

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 commented 10 years ago

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:

$  cp /lib/udev/rules.d/75-persistent-net-generator.rules /etc/udev/rules.d/
# 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}=""
ENV{MATCHADDR}=="08:00:27:*",       ENV{MATCHADDR}=""
$ 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 commented 10 years ago

@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)?

bmorg commented 10 years ago

@b-long There is the general guide to creating base boxes and the guide for creating a base box for VirtualBox. Those don't really contain extensive information about OS configuration though.

As for the above problem: for Debian this was addressed in Squeeze (Debian 7). I have not created my own base boxes for any other distribution yet, so unfortunately I cannot comment on that.

84564221 commented 10 years ago

Still not fixed, what the fuck ...

kikitux commented 10 years ago

@cept0 such violent man..

tartley commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 https://github.com/mitchellh/vagrant/issues/1777#issuecomment-56825282.

ryanschmidt commented 10 years ago

Thanks so much @tsigian! This fixed it for me: https://github.com/mitchellh/vagrant/issues/1777#issuecomment-36283427

lattera commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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

taylorotwell commented 8 years ago

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

balous commented 8 years ago

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 commented 8 years ago

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

HeathNaylor commented 8 years ago

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 commented 8 years ago

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

dylanninin commented 7 years ago

Thanks for @masonfox

pgporada commented 7 years ago

I have something similarly related in https://github.com/mitchellh/vagrant/issues/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 commented 7 years ago

@pgporada you are a hero!!!!!

CeuxDruman commented 7 years ago

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:

  1. Unsinstall vagrant sudo apt-get remove --purge vagrant
  2. Delete ".vagrant" directory from your MV (Don't need to delete it or change Vagrantfile) sudo rm -rf <your_mv_directory>/.vagrant/
  3. 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)
  4. Run it! vagrant up
dmytro-y-dev commented 6 years ago

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).