Reputation: 10771

Vagrant stuck connection timeout retrying

My vagrant was working perfectly fine last night. I've just turned the PC on, hit vagrant up, and this is what I get:

==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> 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: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...

Has anyone had this before? vagrant isn't widely covered on the web yet and I can't find a reason why this is occurring.

Upvotes: 430

Answers (30)

Abhishek D K

Reputation: 2425

encountered similar issue for ubuntu/bionic64

by enabling the gui in Vagrantfile, i was able to login using default vagrant/vagrant

config.vm.provider "virtualbox" do |vb|
   vb.gui = true
end

then reset the firewall using the following command

$ ufw force --reset

then rebooted the system now this time without UI
was able to boot in without any issues

make sure to keep the backup of firewall rules before doing reset

Upvotes: 1

Bruce Tong

Reputation: 1431

I'm just sharing this so that it may help another person in future. rubo77 above gave me the inspiration for this answer.

I encountered this getting stuck in a connection timeout loop after uncommenting two lines in my vagrant file.

vb.gui="true"
config.vm.network "forwarded_port", guest: 80, host: 8080

Apparently the 1st line brings up the GUI which asks if you want to skip mounting or let vagrant mount manually. Commenting it back allowed me to log in, however I could still see 'Connection Aborted. Retrying' in the terminal.

So i ssh into my vagrant and typed.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Then vagrant reload and did not encounter any connection error. However take not this accepts all incoming traffic. So u might want to add rules to only allow port 8080 if you are going to use your bos for a long time.

Digital Ocean gives a very nice tutorial on adding rules to your iptables.

Remember to install iptables-persistent to save your firewall config

Upvotes: 1

Alexar

Reputation: 1878

In my case, giving it a static IP address, simply solved the problem:

config.vm.network "private_network", ip: "192.168.50.50"

Upvotes: 1

HankCa

Reputation: 9659

Mine was running fine and then this "Warning: Remote connection disconnect. Retrying..." over and over - maybe 20 times - until it connected. Based on answers above I just

vagrant destroy
vagrant up

and it was all good. Mine was very simple but I made it that way by cutting down the Vagrantfile to just the config.vm.box = "ubuntu/trusty64" and it was still doing it. So that is why destroying and starting again seemed the best choice. Given the stateless nature of these Vagrant images I don't see why that wouldn't work in every case. I'm just getting into this and I may yet learn that that isn't true.

Upvotes: 36

wmaddox

Reputation: 160

I was testing a mounted folder in my vagrant VM by adding a new entry into /etc/fstab. Later on I logged out, ran vagrant halt, but when I ran vagrant up I got:

SSH auth method: private key
Warning: Remote connection disconnect. Retrying...

I read all these posts and tried all the ones that seemed relevant for my case (except for vagrant destroy, which would have certainly fixed my problem, but was a last resort in my case). The post by @Kiee gave me the idea to try to boot my VM directly from the VirtualBox GUI. During the boot process the VM halted itself and was asking me if I wanted to skip mounting the test folder that I had added earlier to /etc/fstab. (That's why vagrant couldn't boot the VM.) After answering 'NO' the VM booted no problem. I logged in, removed the naughty line from my fstab, and shutdown the VM.

After that vagrant was able to boot just fine.

Takeaway? If all of a sudden vagrant cannot boot back into your VM, try to boot directly from the provider (VirtualBox in my case). Chances are your boot is hanging for something totally unrelated to SSH.

Upvotes: 5

Tarik

Reputation: 4546

Here is how it worked for me:

After "vagrant up" started the virtual machine, turned off the machine and go to the new virtual machine settings in virtualbox. Then go to "Network" -> "Advanced"

Adapter Type: I changed from "Intel PRO XXXXX" to "PCNet-Fast" (or any other adpter other than Intel PRO did work)

Upvotes: 0

Dan Swain

Reputation: 3108

My solution turned out to be none of the above exactly. I'm running Ubuntu 14 as guest inside a Windows 7 host. I had been running this vagrant box fine, but I started it up again after not using it for a couple of months, and it kept coming up with the SSH connection timeout. It turned out that somehow the key pair didn't work - so I copied the Vagrant public key into Ubuntu according to the instructions on this page. But that wasn't all. I then discovered that the private key in my base box was different than the private key here. Putting this private key in as the vagrant_private_key file in C:\Users\your-user.vagrant.d\boxes\vagrant-box-name\nnnnnnnn\virtualbox after placing the public key into Ubuntu fixed the problem.

Upvotes: 0

David

Reputation: 1963

I've found out that on MacOS with VirtualBox adding this to Vagrantfile will let you go further:

config.vm.provider 'virtualbox' do |vb|
  vb.customize ['modifyvm', :id, '--cableconnected1', 'on']
end

Upvotes: 4

Masoud

Reputation: 1064

Check your CPU's virtualization in BIOS setup is enabled.

Upvotes: 1

kenorb

Reputation: 166833

The SSH connection timeout during initial booting may be related to variety of reasons such as:

check whether virtualization is enabled in BIOS (as per comment),
system awaits for user interaction (e.g. share partition is not ready),
mismatch of your private key (check the config via vagrant ssh-config),
the booting process takes much longer time (try increasing config.vm.boot_timeout),
it's booting from the wrong drive (e.g. from the installer ISO),
VM firewall misconfiguration (e.g. iptables configuration),
local firewall rules, port conflict or conflict with a VPN software,
sshd misconfiguration.

To debug the problem, please run it a --debug option or like:

VAGRANT_LOG=debug vagrant up

If there is nothing obvious, then try to connect to it from another terminal, by vagrant ssh or by:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

If the SSH still fails, try to run it with a GUI (e.g. config.gui = true).

If it's not, check the running processes (e.g. by: vagrant ssh -c 'pstree -a') or verify your sshd_config.

If it is disposable VM, you can always try to destroy it and up it again.

You should also consider upgrading your Vagrant and Virtualbox.

For more information, check the Debugging and Troubleshooting page.

Upvotes: 5

Geshan

Reputation: 1141

What worked for me was allowing 64 bit virtualization on a 64 bit OS (Ubuntu 13.10) from BIOS.

Upvotes: 1

dano

Reputation: 5630

My solution to this issue was that my old laptop was taking wayyyyyyyyyyy too long to start up. I opened Virtual Box, connected to the box and waited for the screen to load. Took about 8 minutes.

Then it connected and mounted my folders and went ahead.

just be patient sometimes!

Upvotes: 0

Cedric

Reputation: 1256

The solution I've found is to check the cable connection option in the adapter 1 which is attached to NAT. I really don't know, this is my 4th vagrant box but this is the only one with cable connection option not checked, and upon checking it, it works.

Upvotes: 44

telina

Reputation: 166

Like some people here already pointed out, the error appears - among other things - if the VirtualBox image did not boot properly. For me using the GUI mode on Vagrant did not help much as it only showed a black window. In the VirutalBox GUI I checked the settings on my VM and figured out that somehow the OS was set incorrectly (Debian 32 instead of 64 Bit).

So I can only recommend checking the VirtualBox settings of the VM manually and getting the VM to boot without using Vagrant in first place.

Upvotes: 1

Jarzka

Reputation: 773

I got this when running vagrant/VirtualBox inside VirtualBox. I resolved this by running the vagrant machine in the host machine.

Upvotes: 3

Jplus2

Reputation: 2531

For me it was the compatibility between vagrant and virtual box.

I'm on windows 10 and what I did I uninstalled vagrant and virtual box

Then install an old version of virtual box specifically version 4.3.38 ( Install extension pack too for this version )

Then installed latest copy of vagrant ( 1.8.5 at the moment )

After that it worked.

Upvotes: 2

Geshan

Reputation: 1141

If you are working on Windows 8 or 10, this is what worked for me:

Change BIOS settings to allow virtualization of 64bit.
Here is how:
- Restart PC using Advanced Startup (Go to Advanced Startup -'restart now'-'troubleshoot' -'advanced option'- 'UEFI Firmware Setting' - 'Restart')
- Inside BIOS window - Go to 'Advanced' menu/tab - Enable 'Intel Virtual Technology'
- Save & Exit.

Upvotes: 17

user1108948

Reputation:

I got it resolved when I killed putty process. Because I have git-ssh and putty both running. They were appearing to fight each other for ssh accessing. Only one is enough.

Upvotes: 0

giovannipds

Reputation: 3489

There are many good answers here, and I couldn't read it all, but, I just came by to gave my little contribution too. I had 2 different problems:

vagrant up wasn't able to find my ssh 'id_rsa' (because I didn't have it yet, at that time): I ran ssh-keygen -t rsa -b 4096 -C "[email protected]", based on this GitHub's article, and voilá, steped through that;
Then, I got the same problem of this question "Warning: Connection timed out. Retrying...", eternally...: So, after reading a lot, I've restarted my system and looked at my BIOS (F2 to get there, on PC), and there were Virtualization disabled. I've enabled that, saved, and started the system once again, to check if it has changed anything.

After that, vagrant up worked like a charm! It's 4am but it is running! How cool, hã? :D As I know there are very few masochist developers like me, that would try this at Windows, specially at Windows 10, I just couldn't not to forget coming here and left my word... another important information, is that, I was trying to set-up Laravel 5, using Homestead, VirtualBox, composer etc. It has worked. So, hope this answer helps like this question and answers helped me. My best wishes. G-bye!

Upvotes: 4

htmldrum

Reputation: 2449

If you're using a wrapper layer (like Kitchen CI) and you're running a 32b host, you'll have to preempt the installation of Vagrant boxes. Their default provider is the opscode "family" of binaries.

So before kitchen create default-ubuntu-1204 make sure you use:

vagrant box add default-ubuntu-1204 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04-i386_chef-provisionerless.box

for using the 32b image if your host doesn't support word size virtualization

Upvotes: 0

user2338925

Reputation:

Look for this line in your Homestead.yaml:

config.vm.network "forwarded_port", guest: 80, host: 8080

and change to:

config.vm.network "forwarded_port", guest: 80, host: 8000

then in Homestead directory, run:

vagrant destroy
vagrant up

See if it works.

Upvotes: 0

user1108948

Reputation:

Delete the file:

C:\Users\UserName\\.vagrant.d\insecure_private_key

Then run:

vagrant up

Upvotes: 2

Dmitrii Mikhailov

Reputation: 5241

I had the same issue after I deleted this line from my Vagrantfile:

config.vm.network "private_network", type: "dhcp"

VM loaded fine after I put this line back.

Upvotes: 8

Gwidryj

Reputation: 1035

I had the same issue, but none of other answers fully solved my problem. Answer by @Kiee was helpful, although all I could see in the GUI was a black screen (with underscore in top-left, this issue in Virtual Box also has been raised separately in stack overflow, again nothing helped).

Eventually, a solution proved to be very simple: check version of your virtual machine.

More precisely, I had a box from someone else with 64-bit Debian, but Virtual Box insisted to treat it as 32-bit, what I didn't notice. To change it, open Virtual Box, then open terminal and run

vagrant up

wait for the line

default: SSH auth method: private key

now you can hit ctrl+C (or wait for timeout) and run

vagrant halt

your virtual machine won't be destroyed, so you can see it in the menu of Virtual Box, but will be powered off, so you can change settings. Chose your machine in the menu, click 'Settings'->'General' and chose proper 'Version', for me it was 'Debian (64-bit)'. After this type vagrant up again.

If this is a case for you (or different changes in 'Settings' solved your issue), you can create new box from the repaired one typing

vagrant package --output mynew.box

Some more details: host 32-bit Ubuntu 12.04, guest 64-bit Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

Upvotes: 4

Mahbub

Reputation: 4942

I have faced the same problem. I fixed this by enabling Virtualization from BIOS setup.

Upvotes: 1

user1522091

Reputation: 187

The way I had to solve this wasn't mentioned in this thread, so I'm posting the details here in case it helps anyone else.

What causes this is that vagrant can't ssh into the machine after it boots up. There's various reasons for this, as mentioned in this thread, such as the machine not booting up all the way, or iptables firewall blocking SSH.

In my case, the problem was that I inadvertently setup a "private_network" with an IP address in the same subnet as the built-in VirtualBox NAT network (in my case 10.0.2.0/24). This messed up the NAT network for the machine (but no errors shown anywhere), and since vagrant connects via the NAT network, it wasn't able to connect even though the machine was running and no firewalls were enabled.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.2.31"
end

The fix was to update my VagrantFile and use a "private_network" IP that didn't conflict with VirtualBox's NAT network.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.4.31"
end

Upvotes: 0

henriale

Reputation: 1042

I solved by just typing ˆC(or ctrl+C on Windows) twice and quitting the connection failure screen.

Then, I could connect via SSH (vagrant ssh) and see the error by my own.

In my case, it was a path mistyped.

Upvotes: 0

Hinnerk

Reputation: 145

One more possible solution for users of the VMware provider: For me the issue was resolved after removing a parallel installation of VirtualBox on the same host machine. Network interfaces between VMware and VirtualBox were apparently conflicting

Upvotes: 1

Ambulare

Reputation: 933

Maybe this is too simple an answer to help a lot of people, but worth trying if you haven't: Do a "vagrant halt" instead of a "vagrant suspend" then restart the VM with "vagrant up".

I think my problem was due to some "kworker" process getting buggy and constantly timing out in the VM and so doing a hard reboot seemed to reload the process correctly whereas a save and restore was just restoring the broken process in its broken state.

Upvotes: 3

user4757351

Reputation:

Personally, for me, Tunnelblick VPN software was blocking the connection. Now when I'm booting up new VMs I temporary disable Tunnelblick.

Upvotes: 0

Vagrant stuck connection timeout retrying

Answers (30)

Related Questions