Skip to content
This repository has been archived by the owner on Feb 13, 2023. It is now read-only.

Vagrant Up stuck at SSH (Win8) #1129

Closed
AntoninSlejska opened this issue Jan 18, 2017 · 11 comments
Closed

Vagrant Up stuck at SSH (Win8) #1129

AntoninSlejska opened this issue Jan 18, 2017 · 11 comments

Comments

@AntoninSlejska
Copy link

AntoninSlejska commented Jan 18, 2017

Issue Type

  • Bug Report / Support Request

Environment

Drupal VM 4.1.1
Vagrant 1.9.1
Vagrant box: geerlingguy/ubuntu1604 (virtualbox, 1.0.7)
VirtualBox 5.1.14

OS

  • Windows 8.1 Pro

HW

  • Desktop: HP ProDesk 490 G2 MT
  • Processor: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
  • System type: 64-bit operating system, x64-based processor

Full console output

$ vagrant up
Bringing machine 'drupalvm' up with 'virtualbox' provider...
==> drupalvm: Importing base box 'geerlingguy/ubuntu1604'...
==> drupalvm: Matching MAC address for NAT networking...
==> drupalvm: Checking if box 'geerlingguy/ubuntu1604' is up to date...
==> drupalvm: Setting the name of the VM: drupalvm.dev
==> drupalvm: Clearing any previously set network interfaces...
==> drupalvm: Preparing network interfaces based on configuration...
    drupalvm: Adapter 1: nat
    drupalvm: Adapter 2: hostonly
==> drupalvm: Forwarding ports...
    drupalvm: 22 (guest) => 2222 (host) (adapter 1)
==> drupalvm: Running 'pre-boot' VM customizations...
==> drupalvm: Booting VM...
==> drupalvm: Waiting for machine to boot. This may take a few minutes...
    drupalvm: SSH address: 127.0.0.1:2222
    drupalvm: SSH username: vagrant
    drupalvm: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
$ vagrant provision
==> drupalvm: [vagrant-hostsupdater] Checking for host entries
==> drupalvm: [vagrant-hostsupdater]   found entry for: 192.168.88.88 drupalvm.dev
==> drupalvm: [vagrant-hostsupdater] Writing the following entries to (C:/Windows/system32/drivers/etc/hosts)
==> drupalvm: [vagrant-hostsupdater]   192.168.88.88  www.drupalvm.dev  # VAGRANT: cb7d32d7650abdc8b38ff3420060f992 (drupalvm) / 3be1392a-9f4d-4fd2-a64f-09254b5f72a3
==> drupalvm: [vagrant-hostsupdater]   192.168.88.88  adminer.drupalvm.dev  # VAGRANT: cb7d32d7650abdc8b38ff3420060f992 (drupalvm) / 3be1392a-9f4d-4fd2-a64f-09254b5f72a3
==> drupalvm: [vagrant-hostsupdater]   192.168.88.88  xhprof.drupalvm.dev  # VAGRANT: cb7d32d7650abdc8b38ff3420060f992 (drupalvm) / 3be1392a-9f4d-4fd2-a64f-09254b5f72a3
==> drupalvm: [vagrant-hostsupdater]   192.168.88.88  pimpmylog.drupalvm.dev  # VAGRANT: cb7d32d7650abdc8b38ff3420060f992 (drupalvm) / 3be1392a-9f4d-4fd2-a64f-09254b5f72a3
==> drupalvm: [vagrant-hostsupdater]   192.168.88.88  dashboard.drupalvm.dev  # VAGRANT: cb7d32d7650abdc8b38ff3420060f992 (drupalvm) / 3be1392a-9f4d-4fd2-a64f-09254b5f72a3
==> drupalvm: [vagrant-hostsupdater] This operation requires administrative access. You may skip it by manually adding equivalent entries to the hosts file.
C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/HostsUpdater.rb:98:in `initialize': Permission denied @ rb_sysopen - C:/Windows/system32/drivers/etc/hosts (Errno::
EACCES)
        from C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/HostsUpdater.rb:98:in `open'
        from C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/HostsUpdater.rb:98:in `addToHosts'
        from C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/HostsUpdater.rb:47:in `addHostEntries'
        from C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/Action/UpdateHosts.rb:17:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/machine.rb:225:in `action_raw'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/machine.rb:200:in `block in action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/environment.rb:567:in `lock'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `action'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/commands/provision/command.rb:30:in `block in execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:235:in `block in with_target_vms'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:229:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/plugin/v2/command.rb:229:in `with_target_vms'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/commands/provision/command.rb:29:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/cli.rb:42:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/lib/vagrant/environment.rb:308:in `cli'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.1/bin/vagrant:127:in `<main>'

Summary

The problem is the same as: #981, #965 or #953, but the described solutions did not work by me. The problem is probably with:

C:/Users/slejskaa/.vagrant.d/gems/2.2.5/gems/vagrant-hostsupdater-1.0.2/lib/vagrant-hostsupdater/HostsUpdater.rb:98:in `initialize': Permission denied @ rb_sysopen - C:/Windows/system32/drivers/etc/hosts (Errno::EACCES)

This is an old issue, e.g.: agiledivider/vagrant-hostsupdater#89, but I have found no solution, which would work for me.

@oxyc
Copy link
Collaborator

oxyc commented Jan 18, 2017

I havent tried it but it might be worth trying https://github.com/devopsgroup-io/vagrant-hostmanager instead. Drupal VM supports both but you should only have one installed so uninstall vagrant-hostsupdater before trying it.

@AntoninSlejska
Copy link
Author

@oxyc Thank you for the tip. It did not work:

$ vagrant plugin uninstall vagrant-hostsupdater
Uninstalling the 'vagrant-hostsupdater' plugin...
Successfully uninstalled vagrant-hostsupdater-1.0.2
$ vagrant destroy
    drupalvm: Are you sure you want to destroy the 'drupalvm' VM? [y/N] y
==> drupalvm: Forcing shutdown of VM...
==> drupalvm: Destroying VM and associated drives...
$ vagrant up
Bringing machine 'drupalvm' up with 'virtualbox' provider...
==> drupalvm: Importing base box 'geerlingguy/ubuntu1604'...
==> drupalvm: Matching MAC address for NAT networking...
==> drupalvm: Checking if box 'geerlingguy/ubuntu1604' is up to date...
==> drupalvm: Setting the name of the VM: drupalvm.dev
==> drupalvm: Clearing any previously set network interfaces...
==> drupalvm: Preparing network interfaces based on configuration...
    drupalvm: Adapter 1: nat
    drupalvm: Adapter 2: hostonly
==> drupalvm: Forwarding ports...
    drupalvm: 22 (guest) => 2222 (host) (adapter 1)
==> drupalvm: Running 'pre-boot' VM customizations...
==> drupalvm: Booting VM...
==> drupalvm: Waiting for machine to boot. This may take a few minutes...
    drupalvm: SSH address: 127.0.0.1:2222
    drupalvm: SSH username: vagrant
    drupalvm: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
$  vagrant provision
==> drupalvm: Running provisioner: ansible_local...
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 disabled the SSH agent:

$ export SSH_AUTH_SOCK=""

But without any effect.

@geerlingguy
Copy link
Owner

@AntoninSlejska - Yikes, didn't realize 5.1.14 is already out... I just updated my boxes to 5.1.12!

Can you try installing vagrant plugin install vagrant-vbguest and see if that fixes it?

@AntoninSlejska
Copy link
Author

AntoninSlejska commented Jan 19, 2017

@geerlingguy Thank you for your suggestion. I have installed vbguest in my previous trials. It did not help. I have received the following responces this time:

$ vagrant plugin install vagrant-vbguest
Installing the 'vagrant-vbguest' plugin. This can take a few minutes...
Installed the plugin 'vagrant-vbguest (0.13.0)'!
$ vagrant up
Bringing machine 'drupalvm' up with 'virtualbox' provider...
==> drupalvm: Checking if box 'geerlingguy/ubuntu1604' is up to date...
==> drupalvm: A newer version of the box 'geerlingguy/ubuntu1604' is available! You currently
==> drupalvm: have version '1.0.7'. The latest is version '1.0.8'. Run
==> drupalvm: `vagrant box update` to update.
==> drupalvm: Clearing any previously set forwarded ports...
==> drupalvm: Clearing any previously set network interfaces...
==> drupalvm: Preparing network interfaces based on configuration...
    drupalvm: Adapter 1: nat
    drupalvm: Adapter 2: hostonly
==> drupalvm: Forwarding ports...
    drupalvm: 22 (guest) => 2222 (host) (adapter 1)
==> drupalvm: Running 'pre-boot' VM customizations...
==> drupalvm: Booting VM...
==> drupalvm: Waiting for machine to boot. This may take a few minutes...
    drupalvm: SSH address: 127.0.0.1:2222
    drupalvm: SSH username: vagrant
    drupalvm: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
$ vagrant box update
==> drupalvm: Checking for updates to 'geerlingguy/ubuntu1604'
    drupalvm: Latest installed version: 1.0.7
    drupalvm: Version constraints:
    drupalvm: Provider: virtualbox
==> drupalvm: Updating 'geerlingguy/ubuntu1604' with provider 'virtualbox' from version
==> drupalvm: '1.0.7' to '1.0.8'...
==> drupalvm: Loading metadata for box 'https://atlas.hashicorp.com/geerlingguy/ubuntu1604'
==> drupalvm: Adding box 'geerlingguy/ubuntu1604' (v1.0.8) for provider: virtualbox
    drupalvm: Downloading: https://vagrantcloud.com/geerlingguy/boxes/ubuntu1604/versions/1.0.8/providers/virtualbox.box
    drupalvm: Progress: 100% (Rate: 6494k/s, Estimated time remaining: --:--:--)
==> drupalvm: Successfully added box 'geerlingguy/ubuntu1604' (v1.0.8) for 'virtualbox'!
$ vagrant destroy
    drupalvm: Are you sure you want to destroy the 'drupalvm' VM? [y/N] y
==> drupalvm: Forcing shutdown of VM...
==> drupalvm: Destroying VM and associated drives...
$ vagrant up
Bringing machine 'drupalvm' up with 'virtualbox' provider...
==> drupalvm: Importing base box 'geerlingguy/ubuntu1604'...
==> drupalvm: Matching MAC address for NAT networking...
==> drupalvm: Checking if box 'geerlingguy/ubuntu1604' is up to date...
==> drupalvm: Setting the name of the VM: drupalvm.dev
==> drupalvm: Clearing any previously set network interfaces...
==> drupalvm: Preparing network interfaces based on configuration...
    drupalvm: Adapter 1: nat
    drupalvm: Adapter 2: hostonly
==> drupalvm: Forwarding ports...
    drupalvm: 22 (guest) => 2222 (host) (adapter 1)
==> drupalvm: Running 'pre-boot' VM customizations...
==> drupalvm: Booting VM...
==> drupalvm: Waiting for machine to boot. This may take a few minutes...
    drupalvm: SSH address: 127.0.0.1:2222
    drupalvm: SSH username: vagrant
    drupalvm: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
$ vagrant provision
==> drupalvm: Running provisioner: ansible_local...
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
$ vagrant ssh-config
Host drupalvm
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/Users/slejskaa/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes

@geerlingguy
Copy link
Owner

See also: #509

If you just run vagrant ssh, does that not connect either? In that case, it looks like the problem is likely something related to networking. Either a corporate firewall, the dreaded 'cable connected not being checked in the VM settings' issue, or something else entirely.

@AntoninSlejska
Copy link
Author

AntoninSlejska commented Jan 20, 2017

@geerlingguy Thank you again, Jeff. I have read #509, but none of the suggestions worked by me. The command vagrant ssh returns the following message:

$ vagrant up
...
    drupalvm: SSH auth method: private key
Timed out while waiting for the machine to boot...
$ vagrant ssh
ssh_exchange_identification: read: Connection reset by peer

I have found a lot of tips for this error message, but nothing worked. As a hint can serve the following screen, which I have got, after I had added the line v.gui = true to Vagrantfile (see: http://superuser.com/a/342477):

  # VirtualBox.
  config.vm.provider :virtualbox do |v|
    v.linked_clone = true if Vagrant::VERSION =~ /^1.8/
    v.name = vconfig['vagrant_hostname']
    v.memory = vconfig['vagrant_memory']
    v.cpus = vconfig['vagrant_cpus']
    v.customize ['modifyvm', :id, '--natdnshostresolver1', 'on']
    v.customize ['modifyvm', :id, '--ioapic', 'on']
    v.gui = true
  end

vb-gui

I have found also for this error message a lot of suggestions. I tried (see https://forums.virtualbox.org/viewtopic.php?f=6&t=59433#p276476):

  1. enable hardware-virtualzation enabled in the hosts bios (not possible, in my bios are only memory test and hard drive test)
  2. select a 64-bit in General -> Basic -> version (in my Virtual Box is already a 64-bit version of Ubuntu)
    ubuntu64
  3. I have activated the Hyper-V, but without any effect.
    windows-features

@geerlingguy
Copy link
Owner

@AntoninSlejska - Aha! Hopefully you have an Intel core processor or M-series—otherwise some VM features won't work correctly. Can you read this: http://docs.drupalvm.com/en/latest/other/linux/#intel-vt-x-virtualization-support

And check if your computer's BIOS or UEFI settings have VT-X emulation disabled?

@AntoninSlejska
Copy link
Author

@geerlingguy Thank you for your help! The Drupal VM works now.

Processor: Intel(R) Core(TM) i7-4790 CPU @3.60GHz
System type: 64/bit operating system, x64/based processor

At first I thought, that there are no settings in my BIOS:
img_20170123_075544

But then I have found (www.makeuseof.com/tag/how-to-access-the-bios-on-a-windows-8-computer/), that in Win8 it is not so straightforward to change the BIOS settings. After that I could enable the virtualization technology (VTx/VTd):
img_20170123_084453

Then I just rebooted and Drupal VM (Vagrant) worked as expected.

@geerlingguy
Copy link
Owner

@AntoninSlejska - Excellent! I'll go ahead and close out the issue now.

What was the model of your HP laptop, btw? Putting that in here may help others with the same model to find out why they're having an issue.

@AntoninSlejska
Copy link
Author

@geerlingguy It is a desktop: HP ProDesk 490 G2 MT. I'll write it to the environment specs. Thanks.

@geerlingguy
Copy link
Owner

Ah, thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants