"Configuring and enabling network interfaces" fails with ssh error #2614
Comments
|
I'm getting the same error with the same CentOS box and Vagrant 1.4.0. Still collecting details. |
|
Please run with |
|
But with the info provided it seems that |
|
I was just about to report the same issue. Environment you can reproduce with vagrant up policyserver produces |
|
Here's my debug log, https://gist.github.com/mwhahaha/7882462 |
|
My debug output: https://gist.github.com/jeremyfelt/7882501 |
|
Same issue here: https://gist.github.com/lukedemi/7884896 Vagrant 1.4.0 Relevant portion of Vagrantfile: |
|
Thanks for all the debug logs. This should be easily reproducible. |
|
The code change which seems to have introduced this is in 1ad756d While the comment is correct that the interface is down at this point, running results in an error of on CentOS 6.5 for me. Simple fix is to just add |
|
To be more precise, the interface is not just down at that point it's actually missing and not configured, i.e. |
|
I agree with your assessment @makern. Reading through this code it doesn't make any sense that that |
|
Great, thanks! |
|
The stack traces show that the error comes from line 26. Same commit/PR, but earlier block. -> Reopening. |
|
You are right @tmatilai, should have checked this more closely. Adding |
|
Yeah, might not make sense to retry multiple times in the first block either. But I haven't had time to test this myself, so didn't make a PR for that. Feel free to do so. =) |
guests/redhat: Don't error if ifdown fails [GH-2614]
|
Should be fixed with #2628 :) Closing againn. |
|
FWIW, this issue only seems to affect the initial creation of a VM. A VM that has already been created will still be able to be brought up fine but destroying the VM and recreating it produces this error. I've replicated this behaviour both on my MacBook Pro and my Fedora 20 workstation. |
|
Will we see a point release for this? I'd like to update but running with a home-grown Vagrant package isn't a good option for me. |
|
+1 for a point release. |
|
would be great to have a new release or somewhere we can download a nightly build ? |
|
Sure the release comes soonish, but if this is blocking you, you can always apply the patches directly into <vagrant_install_dir>/embedded/gems/gems/vagrant-1.4.0/. (This is of course not a good idea in general :)) |
|
@mikelaspina FWIW, As a workaround, I set that network to auto_config: false and I then used shell provisioning to take care of it. |
|
@frayedknot, can you describe the shell provision you do? I'm getting this error on vagrant 1.7.2 centos 6.6 |
|
should this issue be re-opened? It seems to keep cropping up as far back as 1.4? |
|
I am also getting a hang. vagrant 1.7.2 Says that it assumes that this command failed to run: /sbin/ifup enp0s8 I was trying to configure a private network with DHCP and telling virtualbox that it is an internal network. |
|
Same... Vagrant 1.7.2 Downgrade to 1.7.0 helped |
|
Having the same problem with Vagrant 1.7.2 (centos 6.6). Error output: Mine is a packaged box. First time if I use any given default box it works fine. When I try to package it as a box and run the box from local the above problem shows up. |
|
I have to fix this issue manualy after every box update, which is really annoying. |
|
Sorry forgot to update this: Actually, yah, almost the same thing I did too to make the network connection work. However, I think my case is a bit different. I have used a repackaged box which caused this issue. If I remove Hope this helps. Thanks. |
|
@istvan-ujjmeszaros your solution worked for me. Yosemite 10.10.3, Vagrant 1.7.2, VirtualBox 4.3.26, Centos 6.5 final. |
|
FWIW, I worked around this by avoiding the key replacement altogether. I instead used a "config.ssh.private_key_path = File.expand_path()" directive in the Vagrantfile. With that change, v1.7.2 is working fine. |
|
I should also note that in an earlier provisioning step, I update /etc/sysconfig/network-scripts/ifcfg-eth0 to set "ONBOOT=yes". I leave Adapter 1 in "NAT" mode for Vagrant in the source box/vm. I've been fine since making those changes. |
|
Would be nice if anyone could solve this finally?? Fresh box from veewee template, which I've converted to CentOS 7.1 doesn't work either got the same problem. I've tried to install biodevname package (yes. rpm exists), I've tried to set param for bootloader to stop using biosdevname.. nothing helps. Here's CentOS7 box: https://github.com/holms/vagrant-centos7-box/releases |
|
@mitchellh Some progress finally: Taken from here: Added two parameters in kickstart, to bootloader section: And here's the next issue: |
|
Some progress in here... I've removed udev rule, and added biosdevname package holms/vagrant-centos7-box@030375653 This is fully working for me :) |
|
Hi all, I have been banging my head against this for days now, trying all combinations of removing the udev rule 70-persistent-net.rules, adding all kinds of configuration to the network script at ifcfg-eth1, removing it and so on. Whenever I packaged the virtualbox machine and used it as a base box to spawn a new VM, I would be getting this: All that using VirtualBox 4.3.28, Vagrant 1.7.2 and a CentOS 6.5 image. The solution that finally worked for me was to remove if cfg-eth1 and linking the udev rules file to |
|
thanks, yakarij! Your solution worked for me! sudo rm /etc/udev/rules.d/70-persistent-net.rules then rebuild the base box. |
|
Cheers yakarij, I had the same problem with CentOS-6.7 (2.6.32-573.3.1.el6.x86_64) within Vagrant 1.7.4 and VirtualBox 5.0.2r102096 and problem still was there, your decision helped a lot! Thanks! |
|
+1 for jakarij's solution. The 'ln -sf /dev/null /etc/udev/rules.d/70-persistent-net.rules' was the magic for me. Vagrant 1.8.1 on Win 7 64 bit |
|
This problem shows up when I package a ubuntu 16.04 because by default this distribution does not use Or even better, vagrant should figure this out by itself. |
|
0505771 might be a fix for this but my version 1.8.1 does not seem to have this fix. How do I make a new vagrant binary from source? |
|
i am having the same issue as @kzw does. Is specifying a different O/S a workaround for this issue? |
|
Another variant. Haven't found a solution yet... |
|
I am seeing this error too [default] GuestAdditions 5.0.26 running --- OK. I am using vagrant-1.8.5 on host ubuntu 16.04 |
|
anyone who is looking for a solution when sitting on ubuntu 16.04 with vagrant 1.8: installing vagrant from deb package (vagrant 1.9.8 for example) fixes this issue. |
|
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. |
ghost
locked and limited conversation to collaborators
and others
I just updated to 1.4.0 and when I attempt to start up I'm getting an error when it attempts to configure eth1. This was previously working on 1.3.5. I'm running on OSX using VirtualBox and attempting to start up a centos box.
vagrant up output:
Vagrantfile:
When I log into the box, eth1 exists but doesn't have an ifcfg-eth1 configuration file.
When vagrant up is run with debug, here's the ERROR trace when it quits.
The text was updated successfully, but these errors were encountered: