Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
84564221 opened this issue May 29, 2013 · 51 comments

Comments

@84564221
Copy link

commented May 29, 2013

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

This comment has been minimized.

Copy link

commented May 30, 2013

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

@jistanidiot

This comment has been minimized.

Copy link

commented Jun 7, 2013

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

This comment has been minimized.

Copy link
Member

commented Jun 9, 2013

I need a lot more information:

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

This comment has been minimized.

Copy link

commented Jun 11, 2013

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

This comment has been minimized.

Copy link

commented Jun 11, 2013

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

This comment has been minimized.

Copy link

commented Jun 21, 2013

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

@iffy

This comment has been minimized.

Copy link

commented Jun 27, 2013

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

This comment has been minimized.

Copy link

commented Jul 2, 2013

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

@tsechingho

This comment has been minimized.

Copy link

commented Jul 3, 2013

@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

This comment has been minimized.

Copy link

commented Jul 5, 2013

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?

@tidytrax

This comment has been minimized.

Copy link

commented Aug 16, 2013

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

worked fine for me.

@XXBlackieXX

This comment has been minimized.

Copy link

commented Aug 23, 2013

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

This comment has been minimized.

Copy link

commented Aug 28, 2013

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

This comment has been minimized.

Copy link

commented Aug 28, 2013

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

This comment has been minimized.

Copy link

commented Aug 29, 2013

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

This comment has been minimized.

Copy link
Member

commented Sep 1, 2013

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

@casr

This comment has been minimized.

Copy link

commented Dec 16, 2013

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 16, 2013

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

@casr

This comment has been minimized.

Copy link

commented Dec 16, 2013

@tmatilai Cheers for the info!

@kjprince

This comment has been minimized.

Copy link

commented Feb 13, 2014

Debian squeeze

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

Worked for me too.

@tsigian

This comment has been minimized.

Copy link

commented Feb 16, 2014

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

This comment has been minimized.

Copy link

commented Feb 17, 2014

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 18, 2014

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

@b-long

This comment has been minimized.

Copy link

commented Feb 26, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2014

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

This comment has been minimized.

Copy link

commented Feb 27, 2014

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

@84564221

This comment has been minimized.

Copy link
Author

commented Jul 18, 2014

Still not fixed, what the fuck ...

@kikitux

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2014

@cept0 such violent man..

@tartley

This comment has been minimized.

Copy link

commented Sep 3, 2014

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

This comment has been minimized.

Copy link

commented Sep 25, 2014

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

This comment has been minimized.

Copy link

commented Sep 25, 2014

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

This comment has been minimized.

Copy link

commented Sep 25, 2014

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

@lattera

This comment has been minimized.

Copy link

commented Feb 24, 2015

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?

This was referenced Mar 27, 2015

@GabLeRoux

This comment has been minimized.

Copy link

commented Apr 5, 2015

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

This comment has been minimized.

Copy link

commented Apr 9, 2015

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

This comment has been minimized.

Copy link

commented May 13, 2015

I've sold it like this: holms/vagrant-centos7-box@0303756
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

This comment has been minimized.

Copy link

commented Jul 9, 2015

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

This comment has been minimized.

Copy link

commented Aug 5, 2015

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

This comment has been minimized.

Copy link

commented Feb 22, 2016

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

@taylorotwell

This comment has been minimized.

Copy link

commented May 1, 2016

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

@balous

This comment has been minimized.

Copy link

commented May 2, 2016

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

This comment has been minimized.

Copy link

commented May 31, 2016

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

@HeathNaylor

This comment has been minimized.

Copy link

commented Jun 13, 2016

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

This comment has been minimized.

Copy link

commented Jul 25, 2016

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

@dylanninin

This comment has been minimized.

Copy link

commented Nov 2, 2016

Thanks for @masonfox

@pgporada

This comment has been minimized.

Copy link

commented Mar 15, 2017

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

This comment has been minimized.

Copy link

commented Apr 6, 2017

@pgporada you are a hero!!!!!

@CeuxDruman

This comment has been minimized.

Copy link

commented Sep 12, 2017

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
@metamaker

This comment has been minimized.

Copy link

commented Nov 22, 2017

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

This comment has been minimized.

Copy link

commented Jan 24, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.