Seravo/wordpress

Vagran't can't connect to SSH

JoosuaKoskinen opened this issue · 6 comments

I can't get Vagrant running as it gets in SSH connecting loop. Running vagrant up --debug I get the following error:

DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "f944bfba-5b2d-4887-8661-f41905ce9edb", "--machinereadable"]
DEBUG ssh: == Net-SSH connection debug-level log START ==
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG ssh: D, [2020-01-14T14:15:29.312574 #21620] DEBUG -- net.ssh.transport.session[3fc8b62a97fc]: establishing connection to 127.0.0.1:2222
D, [2020-01-14T14:15:29.314088 #21620] DEBUG -- net.ssh.transport.session[3fc8b62a97fc]: connection established
I, [2020-01-14T14:15:29.314619 #21620]  INFO -- net.ssh.transport.server_version[3fc8b62a91a8]: negotiating protocol version
D, [2020-01-14T14:15:29.314806 #21620] DEBUG -- net.ssh.transport.server_version[3fc8b62a91a8]: local is `SSH-2.0-Ruby/Net::SSH_5.1.0 x86_64-linux'

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: SSH not ready: #<Vagrant::Errors::NetSSHException: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

timeout during server version negotiating>

I tried killing ssh-agent as it instructs but made no difference. Also tried vagrant destroy multiple times. Is this an issue in our vagrant box, Vagrant overall or my system?

ottok commented

It was seravo/wordpress v20191227.0.0 but I upgraded to seravo/wordpress-beta v20201012.0.0 and the problem persists.

By the way, is that version number a typo? The month seems wrong: https://app.vagrantup.com/seravo/boxes/wordpress-beta

@ottok investigated this and it was due to VirtuaBox 6.1 being very slow. I now downgraded to VirtualBox 5.2 and the virtual machine booted in 10 seconds.

Just in case someone runs into this problem later, the host is running Ubuntu 19.10 and VirtualBox was the one meant for Ubuntu bionic.

ottok commented

You had VirtualBox 6.0 (not 6.1). I re-open this because some customer might have this issue as well. We need to verify if all 6.0 everywhere are very slow and what it might be due to.

That's right, my mistake.

ottok commented

The root cause here was the Virtualbox 6.0 is super slow and unusable. The fix is to use Virtualbox 5.2 as we currently recommend in our docs. In the future possible Virtualbox 6.1, as covered in #96.