vagrant-digitalocean freezes after getting IP.

[danyal14]

Hi Guys,

I am using puphpet + vagrant-digitalocean & runing vagrant up does create the droplet at DO and get's the IP. But right after that it freezes.

Puphpet is saying, that it's not their issue but vagrant-digitalocean.

Can you please verify, if this is an known issue? and if yes, what is the solution?

Best Regards
Danyal

[danyal14]

Here is the output after 30 mins of time and vagrant up is interrupted with folloing output.

==> web-staging: Destroying the droplet...
/Users/dab/.vagrant.d/gems/gems/vagrant-digitalocean-0.9.1/lib/vagrant-digitalocean/actions/create.rb:60:in block in call': not ready (RuntimeError) from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/util/retryable.rb:17:inretryable'
from /Users/dab/.vagrant.d/gems/gems/vagrant-digitalocean-0.9.1/lib/vagrant-digitalocean/actions/create.rb:58:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:incall'
from /Users/dab/.vagrant.d/gems/gems/vagrant-digitalocean-0.9.1/lib/vagrant-digitalocean/actions/setup_key.rb:33:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:95:in block in finalize_action' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/builder.rb:116:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/runner.rb:66:in block in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/util/busy.rb:19:inbusy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/runner.rb:66:in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/builtin/call.rb:53:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/builtin/config_validate.rb:25:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:in call' from /Users/dab/.vagrant.d/gems/gems/vagrant-rekey-ssh-0.1.9/lib/vagrant-rekey-ssh/actions/ssh_info.rb:47:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/builder.rb:116:incall'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/runner.rb:66:in block in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/util/busy.rb:19:inbusy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/action/runner.rb:66:in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/machine.rb:225:inaction_raw'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/machine.rb:200:in block in action' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/environment.rb:561:inlock'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/machine.rb:186:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/machine.rb:186:inaction'
from /opt/vagrant/embedded/gems/gems/vagrant-1.8.5/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

[seth-reeser]

Please provide a snippet from your Vagrantfile of the machine in question. Is SELinux enabled? When the machine is up can you SSH into it?

[glennslaven]

I'm getting the same issue, here's my config

  config.vm.define "digitalocean" do |machine|
    machine.vm.provider :digital_ocean do |provider, override|
      override.ssh.private_key_path = '~/.ssh/id_rsa'
      override.vm.box = 'digital_ocean'
      override.vm.box_url = "https://github.com/devopsgroup-io/vagrant-digitalocean/raw/master/box/digital_ocean.box"
      provider.token = '<token>'
      provider.image = 'ubuntu-14-04-x64'
      provider.region = 'sfo1'
      provider.size = '2gb'
    end
  end

[bitsandbooks]

Are we required to use the box/box_url in the repo, or can we let DO use the provider.image to build that?

[2bithacker]

Seeing the same problem here. It appears vagrant is repeatedly trying to SSH to the droplet, but isn't authenticating. I can run vagrant ssh alongside the vagrant up after it creates the droplet, and looking in /var/log/auth.log shows multiple 'Connection closed by {ip} port {port} [preauth]' messages coming from my IP.

Vagrant version 1.9.1
vagrant-digitalocean version 0.9.1
Mac OS X 10.12.3 (Sierra)

[Nevario]

I'm seeing the same issue.

Vagrant version 1.9.1
vagrant-digitalocean version 0.9.1
Mac OS X 10.11.4

[byzent]

I had the same issue, I removed the Vagrant SSH key from DO:
https://cloud.digitalocean.com/settings/security
and ran it again.
That fixed it for me.

[pernico]

I ran in the same issue and I'd like to clarify that if a key named Vagrant already exist in the DO account, it needs to be suppressed in order for the plugin to upload the new one.

This means that it's not possible, at least by default, to use two different ssh keys to authenticate to your droplets has the plugin only uses the key named Vagrant in the account. Is there a way to specify a different DO key name for different key, I'd like that to be possible.

Hope this will help anyone having the same issue.

[gsauthof]

@pernico - it should be possible as long as you configure different provider.ssh_key_name values, as well (the default is 'Vagrant').

[2bithacker]

Happened to be running into this again and did a bit more digging. With vagrant up --debug I noticed the following message:

 INFO ssh: SSH not up: #<Vagrant::Errors::SSHKeyTypeNotSupported: The private key you're attempting to use with this Vagrant box uses
an unsupported encryption type. The SSH library Vagrant uses does not support
this key type. Please use `ssh-rsa` or `ssh-dss` instead. Note that
sometimes keys in your ssh-agent can interfere with this as well,
so verify the keys are valid there in addition to standard
file paths.>

Turns out it doesn't like my ssh-ed25519 key. Tried again with an ssh-rsa key and everything worked fine.