Failed configuring network interfaces after packaging

[petesiss]

Im using OSX 10.7.4 for running vagrant, and Centos6 vm boxes.

I set up a new VM from a fully working base box, and then package it as my own box having made very few (or even no) changes.

When I then add the new .box file and and try to use it for a new vm it fails to set up the network interfaces correctly:

[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

It doesn't seem to matter which networking I choose in the Vagrantfile (host only / bridged) or whether I package it in the directory with the running vm or elsewhere using the --base [vm-name]. I always get the same result.

I have found I can solve this by:

• manually going in to the vm and clearing everything apart from eth0 out of /etc/udev/rules.d/70-persistent-net.rules
• removing any /etc/sysconfig/network-scripts/ifcfg-eth1 or similar files (except the one for eth0).

Once I do that then the machine reloads fine and all the interfaces come back up.

For my use case its not a huge issue as we're not doing this on a large scale, but it would be great to know whats going wrong. Could be something Im missing when packaging.

[philsturgeon]

I was getting this exact same issue Vagrant version 1.0.3, where I had a working base box, ran vagrant and provisioned with puppet a few times, installed some extra packages (SCP and NFS werent working on the original box) then re-packaged and tried again.

I got the exact same errors until I followed the bullet pointed steps above, and now running reload works fine.

Any suggestions on how to resolve this permanently? I don't want other people having to Google around trying to find this, and dont want it effecting others who use my box.

[ngduc]

Hi,
I also use vagrant_1.0.3 & CentOS-6.3-x86_64-minimal.box
I have setup base box bridged network successfully, then run: vagrant package
After add another box from base box & vagrant up, it says:

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 have tried petesiss's solution above, but eth1 still not working.
any idea how to fix this? thanks.

[ngduc]

Now I know what the issue is.
After cloning, VirtualBox generates a new MAC address for the bridged Network Adapter, then vagrant adds "eth2" (with that MAC address) to: sudo vi /etc/udev/rules.d/70-persistent-net.rules

I had to edit that file & changed "eth2" to "eth1". Now eth1 is up normally.
A minor thing is vagrant still shows the failed msg:

"Vagrant assumes that this means the command failed!
/sbin/ifup eth1 2> /dev/null"

[petesiss]

I wonder if the problem arises when you make a new base box with a VM that already has both an eth0 and eth1 when you package it.

This might mean the eth1 is ever present, and confuses Vagrant down the line when it tries to create eth1 on boot in response to the config in the users Vagrantfile.

So the solution might be to ensure that when you package your box it only has the default eth0 set, and not eth1.

I'll test this on a new base box when I get a chance.

[komapa]

Guys, just make sure you delete /etc/udev/rules.d/70-persistent-net.rules before packaging the box and all is good. No need to edit the file, simply delete it to be regenerated appropriately.

[levpaul]

I'm running into the same issue, /sbin/ifup eth1 hangs, but /sbin/ifup eth0 works fine. Is there anyway I can specify vagrant to only call ifup on eth0? I thought the :adapter option might be the one, but no. Kind of lost actually, because it seems like that's the interface used for sharing folders..

[kelbyers]

I am having this same issue, and (for me, at least), it has nothing to do with /etc/udev/rules.d/70-persistent-net.rules. That file does not exist in my packaged box, and it does not exist on my vagrant vms. What I see happening is that once vagrant brings up a vm, it creates (or edits, if it already exists) /etc/sysconfig/network-scripts/ifcfg-eth1, and puts the statement "ONBOOT=yes", in that file. Upon reboot, the network interface is configured automatically by the OS. Vagrant then comes along and runs "/sbin/ifup eth1", which fails, because eth1 is already up.

If I edit the ifcfg-eth1 file to change ONBOOT=no, it boots just fine the next time, but it again changes the file to contain ONBOOT=yes, and deletes my manual change, regardless of where it was in the file. With this vagrant added change, the next reboot will have the same failure again.

Without resorting to creating some sort of service that will either delete the ifcfg-eth1 file or edit it before the network actually gets started, I don't see any way to fix this automatically, since Vagrant seems to be very aggressive in making this change.

EDIT: it appears that vagrant did not delete my manual change, it just added its values below it in the file, so that they overwrite my manually set ONBOOT=no option.

[jgerbasi]

I have the same problem as above except it complains about eth2. Even if I set ONBOOT=no it still fails. Any idea on how I can maybe reset the network settings on the VM so that it can successfully start up each of the network interfaces?

[haf]

I have the identical problem for Windows 8 RTM/64 bits host and CentOS 6.3 64bits guest, VirtualBox 4.2. Doing sudo rm /etc/udev/rules.d/70-persistent-net.rules does NOT help, at reboot I get same problem. Using NREL-CentOS-6.3 box. Network config in Vagrantfile: config.vm.network :bridged. Fresh install of everything.

[pdurbin]

I'm having this problem too. I'm working on an OpenStack deployment and found a great git repo that with a make all spins up two OpenStack nodes, a controller and a compute host, and a VM running on the compute host: https://github.com/lorin/openstack-ansible

Again that repo is great, almost like magic (I wrote about it at http://wiki.greptilian.com/openstack ). I was thinking maybe I'd fork it and convert it to the environment we use at work... which is to say... remove Ansible and replace it with Puppet... and (importantly for this issue) replace Ubuntu and replace it with CentOS.

But, the minute I tweak the Vagrantfile at https://github.com/lorin/openstack-ansible/blob/master/vms/Vagrantfile to use CentOS rather than Ubuntu, the network setup is gone. The assignments of 192.168.206.131 and 192.168.100.131 are not made in the "compute1" VM, for example.

As reported by others on this issue, removing /etc/udev/rules.d/70-persistent-net.rules didn't seem to solve the problem. I tested my colleague's image here: http://irclog.perlgeek.de/crimsonfu/2012-10-31#i_6116658

It would be nice (I think) to iterate quickly on OpenStack stuff in Vagrant and it seems like I could if I worked in an Ubuntu shop. But without this networking piece I'll probably hack on CentOS running on physical hardware.

[pdurbin]

I asked in #vagrant about this and quickly got a solution!

tl;dr: try your fancy networking config with this base box: http://dl.dropbox.com/u/9227672/CentOS-6.0-x86_64-netboot-4.1.6.box

That base box worked for me with https://github.com/lorin/openstack-ansible/blob/master/vms/Vagrantfile

The postinstall used to build this base box has the magic to get hostonly networking to work on CentOS. This is especially important, from what I understand:

# Kill us some udev crap.
ln -sf /dev/null /lib/udev/rules.d/75-persistent-net-generator.rules
rm -f /etc/udev/rules.d/70-persistent-net.rules

The log from #vagrant is available at http://irclogger.com/.vagrant/2012-10-31#1351737777

Happy hacking! :)

[smerrill]

Just to add to this, the next set of lines are also important. Building boxes w/ Veewee right now includes a kickstart run, a reboot, and running postinstall.sh. In the course of that, it's possible for both eth0 and eth1 to get created (or at least it was awhile ago when I was creating these boxes.) That's why the postinstall.sh for that box also has the following lines to ensure that HWADDR is gone from both eth0 and eth1 and that eth1 does not try to come up as DHCP on the first post-package boot:

# On startup, remove HWADDR from the eth0 interface.
cp -f /etc/sysconfig/network-scripts/ifcfg-eth0 /tmp/eth0
sed "/^HWADDR/d" /tmp/eth0 > /etc/sysconfig/network-scripts/ifcfg-eth0
sed -e "s/dhcp/none/;s/eth0/eth1/" /etc/sysconfig/network-scripts/ifcfg-eth0 > /etc/sysconfig/network-scripts/ifcfg-eth1

[samsworldofno]

For posterity, I'll add - this issue can also be caused if you're accidentally defining the same box in your Vagrantfile multiple times, which I found on a project today!

[ellisio]

The above referenced commit resolves all issues I've been having with bridged connections on CentOS 6.3. Can this please make it in to Vagrant?

[jphalip]

This is probably related to #921 (maybe a duplicate). FWIW, the error went away for me after restarting VirtualBox...

[narkisr]

It would be great if this gets fixed

[blalor]

This is reproducible in v1.1.4 by running vagrant reload with config.vm.network :private_network, type: :dhcp configured. The initial vagrant up works fine, but reload bombs with

[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

Logging in and running /sbin/ifup eth1 as root gives

[root@vagrant-centos63 ~]# /sbin/ifup eth1

Determining IP information for eth1...dhclient(1052) is already running - exiting. 

This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.

Please report for this software via the CentOS Bugs Database:
    http://bugs.centos.org/

exiting.
 failed.

This is because /etc/sysconfig/network-scripts/ifcfg-eth1 still has ONBOOT=yes.

[blalor]

This does appear to be a duplicate of #921.

[mitchellh]

This looks like a dupe of #921 let's continue discussions there. I'd love to get this fixed.

[samukasmk]

Hey Guys,

I had, the centos minimal installed with same error.

I deleted the file: /etc/udev/rules.d/70-persistent-net.rules and works perfectly.

Thanks,
SamukaSMk

[claco]

In addition to /etc/udev/rules.d/70-persistent-net.rules, if you have booted with multiple additional network interfaces, remove the vagrant section with eth1/2, etc from /etc/network/interfaces as well (leaving eth0). This solved it for me completely.

[ed-]

I manually removed /e/u/r.d/70-perisistent-net.rules, wiped all mention of eth1 from /e/n/interfaces, and halted my box. After another vagrant up --provision, things are working fine again.

[jimmychu0807]

Just want to add I also encountered this issue after repackaging a CentOS 6.5 box. Removing /etc/udev/rules.d/70-persistent-net.rules and /etc/sysconfig/network-scripts/ifcfg-eth1, and then a vagrant reload --provision works for me.

[ageofzetta]

Same problem here.
Ubuntu 14.04 on a Windows 8.1 host
Vagrant 1.7.4 on Virtualbox 4.3.28

The VM network got misconfigured after i added the public_network option on the Vagrantfile

To solve it i deleted the following file: /etc/udev/rules.d/70-persistent-net.rules

Also i edited the file /etc/network/interfaces and removed everything but eth0 configuration (just delete everyithing between #VAGRANT-BEGIN and #VAGRANT-END )

NOTE: I also removed the public_network option

[pporada-gl]

I packaged a Centos 7.1 virtualbox where I run the following and am still encountering issues starting up a vagrant.

rm -f /etc/udev/rules.d/70-persistent-net.rules;
rm -f /etc/sysconfig/network-scripts/ifcfg-eth1
ln -sf /dev/null /etc/udev/rules.d/70-persistent-net.rules
ln -sf /dev/null /lib/udev/rules.d/75-persistent-net-generator.rules

for ndev in `ls -1 /etc/sysconfig/network-scripts/ifcfg-*`; do
    if [ "`basename $ndev`" != "ifcfg-lo" ]; then
        sed -i '/^HWADDR/d' "$ndev";
        sed -i '/^UUID/d' "$ndev";
    fi
done

The output from the gui shows "work still pending". I can login but no IP address is every assigned. I have the following lines relevant to networking in my Vagrantfile.

config.vm.provider :virtualbox do |vb|
        vb.memory = 1024
        vb.cpus = 1
        vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
        vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
        vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
    end
    config.vm.network "private_network", ip: "192.168.200.42"

I can run vagrant destroy -f and vagrant up till the cows come home and SOMETIMES I can get the vagrant to actually start successfully.