I had hoped that #1738 as released in 1.2.5 was going to fix this issue for me, but it hasn't.
Here's the error:
The following SSH command responded with a non-zero exit status.
/sbin/ifup p7p1 2> /dev/null
Stdout from the command:
ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth1 does not seem to be present, delaying initialisation.
Stderr from the command:
Here's more from the cmd-line after the failure:
nelz-air:fedora nelz$ vagrant ssh
Here's the Gist with my debugging output and my Vagrantfile: https://gist.github.com/nelz9999/6096052
I've been trying to do my due diligence with this report, but I'm new to the Ops-y side of things, coming from a long history of DEV-side. Let me know if there's more info I can provide.
The text was updated successfully, but these errors were encountered:
So I get to work today, and tell my coworker about this bug report. And just to verify my work he downloads the .box file and tries it. AND IT WORKED! (angry face)
The differences between his environment and mine: he has 0 plugins whereas I have 2 (vagrant-berkshelf and vagrant-cachier); and he's on 1.2.2 whereas I am on 1.2.5.
So, I rip out my plugins, and it's still failing for me.
So, I go back to 1.2.2 and LO AND BEHOLD: It works!
So, I start iterating through the releases:
So, the workaround for me is to go back to 1.2.4.
I have updated my gist with a new debug-level output. (The striking difference between the 1.2.4 version is 2.5k lines for the success and 6.0K lines for the failure.)
Can this possibly be re-opened? I'm the co-worker of Nelz9999.
Systemd has implemented something called "Predictable Network Interface Names", the intent being that when hardware is added or removed, the names will remain that same. This means you get ethernet device names like "enp0s3" instead of "eth0". It's pretty well documented here: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
The workaround is pretty simple:
The presence of this symlink over-rides the "predictable" names and uses the old-school "ethN".
Critically, this needs to be done in the packaged up box. Also, this issue only appears when you have more than one interface set up. So the guidance is, set up your box/image this way, and you are all set.
At some point, it would be great to detect and notify Vagrant users of this circumstance, or be able to handle it gracefully.
It seems to be an issue with the way the Fedora boxes are configured. Some of them implement "Predictable Network Interface Names" (let's set on PNIN for short), some others don't. The base box we used happens to have PNIN disabled, maybe because back in the day Vagrant always assumed
I could try to re-enable PNIN on my box (even though it seem to be disabled using a non-standard method), but a more permanent solution would be check whether PNIN is enabled on the box before trying to bring the network up. Maybe checking the
I'd be happy to contribute a patch if I find a consistent solution.
This may not be the best solution, but checking the output of
I can write up a patch for this tonight if it sounds like the way we want to go.
@ryansb the problem with that approach is a configuration like ours, where both eth0 and p7p1 exist. This is the output from
I guess this is because we are using host-only networking.
I tried to use "public_network", but this issue was occurred at my environment Fedora20, Vagrant 1.5.0, VirtualBox 4.3.6.
I just ran into the issue. Is there a temporary fix? Is the solution just downgrading vagrant?
Fedora 20 Guest, Ubuntu 14.04 Host
and I'm using VirtualBox 4.3.14