vagrant up times out (regression between 1.2.7 and 1.3.1) #2163

Closed
spasche opened this Issue Sep 8, 2013 · 17 comments

Comments

Projects
None yet
10 participants
@spasche

spasche commented Sep 8, 2013

Hi,

I updated to 1.3.1 and vagrant up doesn't work any more on a Vagrant file that used to work with 1.2.7.
Host: Windows 8 64-bit
VirtualBox: 4.2.16
box: http://files.vagrantup.com/precise64.box

With 1.3.1, vagrant up ends with an error:
Vagrant was unable to communicate with the guest machine within
the configured ("config.ssh.timeout" value) time period.

1.2.7 logs: http://pastebin.com/raw.php?i=qBrNvUXW
1.3.1 logs: http://pastebin.com/raw.php?i=1DTHMGZx

@mitchellh

This comment has been minimized.

Show comment Hide comment
@mitchellh

mitchellh Sep 8, 2013

Owner

Increase config.ssh.timeout. It defaults to 5 minutes but Windows guests often need much more time.

Previous versions of Vagrant would simply try forever.

Owner

mitchellh commented Sep 8, 2013

Increase config.ssh.timeout. It defaults to 5 minutes but Windows guests often need much more time.

Previous versions of Vagrant would simply try forever.

@mitchellh mitchellh closed this Sep 8, 2013

@spasche

This comment has been minimized.

Show comment Hide comment
@spasche

spasche Sep 8, 2013

Thanks for the quick feedback.

With version 1.2.7, "vagrant up" executes in much less time than 5 minutes (the machine was previously destroyed):

time vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Configuring and enabling network interfaces...
[default] Mounting shared folders...
[default] -- /vagrant

real 0m39.831s
user 0m0.045s
sys 0m0.076s

So I'm not sure the issue with 1.3 is due to a smaller timeout.

I tried enabling the ui, and I can see that the machine has finished booting but vagrant up is still displaying the "waiting for machine to boot" message until it times out after about 5 minutes.

spasche commented Sep 8, 2013

Thanks for the quick feedback.

With version 1.2.7, "vagrant up" executes in much less time than 5 minutes (the machine was previously destroyed):

time vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Configuring and enabling network interfaces...
[default] Mounting shared folders...
[default] -- /vagrant

real 0m39.831s
user 0m0.045s
sys 0m0.076s

So I'm not sure the issue with 1.3 is due to a smaller timeout.

I tried enabling the ui, and I can see that the machine has finished booting but vagrant up is still displaying the "waiting for machine to boot" message until it times out after about 5 minutes.

@mitchellh

This comment has been minimized.

Show comment Hide comment
@mitchellh

mitchellh Sep 8, 2013

Owner

Ah, gotcha, reopened. I'll take a closer look.

Owner

mitchellh commented Sep 8, 2013

Ah, gotcha, reopened. I'll take a closer look.

@mitchellh mitchellh reopened this Sep 8, 2013

@joliver

This comment has been minimized.

Show comment Hide comment
@joliver

joliver Sep 12, 2013

I'm getting the same type of thing. Mac OSX host with precise64.box as the guest. The CPU spikes and hits 100% during the "Waiting for machine to boot." The funny part is that it's RUBY that's causing it to spike, not VBoxManage like you would expect. I'm using 1.3.1. 1.2.7 did not exhibit this behavior.

joliver commented Sep 12, 2013

I'm getting the same type of thing. Mac OSX host with precise64.box as the guest. The CPU spikes and hits 100% during the "Waiting for machine to boot." The funny part is that it's RUBY that's causing it to spike, not VBoxManage like you would expect. I'm using 1.3.1. 1.2.7 did not exhibit this behavior.

@mitchellh

This comment has been minimized.

Show comment Hide comment
@mitchellh

mitchellh Sep 16, 2013

Owner

@joliver I fixed the 100% CPU issue in git. Still looking into this issue.

Owner

mitchellh commented Sep 16, 2013

@joliver I fixed the 100% CPU issue in git. Still looking into this issue.

@mitchellh

This comment has been minimized.

Show comment Hide comment
@mitchellh

mitchellh Sep 16, 2013

Owner

Fixed

Owner

mitchellh commented Sep 16, 2013

Fixed

@mitchellh mitchellh closed this Sep 16, 2013

@borgenk

This comment has been minimized.

Show comment Hide comment
@borgenk

borgenk Sep 29, 2013

I still have this issue. The VM starts up within 10 seconds or so, but Vagrant is stalling at "Waiting for machine to boot" and Ruby is using alot of CPU. Eventually it times out.

The problem only occurs on the first vagrant up when it has to import base box, but any consecutive vagrant up is taking alot longer than usual (compared to 1.2.7).

http://cloud-images.ubuntu.com/vagrant/raring/current/raring-server-cloudimg-amd64-vagrant-disk1.box

Vagrant 1.3.3
Virtualbox 4.2.18
Windows 8 64bit

borgenk commented Sep 29, 2013

I still have this issue. The VM starts up within 10 seconds or so, but Vagrant is stalling at "Waiting for machine to boot" and Ruby is using alot of CPU. Eventually it times out.

The problem only occurs on the first vagrant up when it has to import base box, but any consecutive vagrant up is taking alot longer than usual (compared to 1.2.7).

http://cloud-images.ubuntu.com/vagrant/raring/current/raring-server-cloudimg-amd64-vagrant-disk1.box

Vagrant 1.3.3
Virtualbox 4.2.18
Windows 8 64bit

@joliver

This comment has been minimized.

Show comment Hide comment
@joliver

joliver Sep 29, 2013

@mitchellh I'm still getting the CPU at 100% in Vagrant 1.3.3 on OSX 10.8.4.

joliver commented Sep 29, 2013

@mitchellh I'm still getting the CPU at 100% in Vagrant 1.3.3 on OSX 10.8.4.

@martinchooooooo

This comment has been minimized.

Show comment Hide comment
@martinchooooooo

martinchooooooo Oct 4, 2013

Same happening for me. I had it running nicely a few days ago, and I updated my VBox up to 4.2.18. I'm not sure what version I was running before that unfortunately, so maybe the issue has to do with VBox?

Vagrant 1.3.4
VBox 4.2.18
OSX 10.8.5

Same happening for me. I had it running nicely a few days ago, and I updated my VBox up to 4.2.18. I'm not sure what version I was running before that unfortunately, so maybe the issue has to do with VBox?

Vagrant 1.3.4
VBox 4.2.18
OSX 10.8.5

@joliver

This comment has been minimized.

Show comment Hide comment
@joliver

joliver Oct 4, 2013

Same here.
Vagrant 1.3.4
VBox 4.2.18
OSX 10.8.5

Still getting Ruby at 100% during "vagrant up".

joliver commented Oct 4, 2013

Same here.
Vagrant 1.3.4
VBox 4.2.18
OSX 10.8.5

Still getting Ruby at 100% during "vagrant up".

@borgenk

This comment has been minimized.

Show comment Hide comment
@borgenk

borgenk Oct 4, 2013

I think my problem was due to a bug in the raring cloud image which I believe has been fixed.

https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1217950

borgenk commented Oct 4, 2013

I think my problem was due to a bug in the raring cloud image which I believe has been fixed.

https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1217950

@martinchooooooo

This comment has been minimized.

Show comment Hide comment
@martinchooooooo

martinchooooooo Oct 4, 2013

Fun fact, I reverted my version of Vagrant back to 1.1.4 (which I was running before I upgraded to 1.3.4) and it works fine now. vagrant up doesn't time out and I can vagrant ssh into my boxes.

Fun fact, I reverted my version of Vagrant back to 1.1.4 (which I was running before I upgraded to 1.3.4) and it works fine now. vagrant up doesn't time out and I can vagrant ssh into my boxes.

@jitendravyas

This comment has been minimized.

Show comment Hide comment
@jitendravyas

jitendravyas Oct 16, 2013

I also having this problem with latest version of Vargant and virtualbox on windows 7 http://i.imgur.com/Iyz724P.png

I also having this problem with latest version of Vargant and virtualbox on windows 7 http://i.imgur.com/Iyz724P.png

@steenhulthin

This comment has been minimized.

Show comment Hide comment
@steenhulthin

steenhulthin Nov 16, 2013

Same as @jitendravyas here.
Vagrant 1.3.5
VirtualBox 4.2.18

host-OS: windows 8.1
guest-OS: windows 7

Same as @jitendravyas here.
Vagrant 1.3.5
VirtualBox 4.2.18

host-OS: windows 8.1
guest-OS: windows 7

@linuxgurugamer

This comment has been minimized.

Show comment Hide comment
@linuxgurugamer

linuxgurugamer Nov 29, 2013

Same here:

Vagrant 1.3.5
Virtualbox 4.3.2

Host os: OSX Mavericks, fully updated
Guest ok: Centos 6

The guest boots, but vagrant aka ruby is holding at 100% cpu. Eventually it times out. If I use ctrl-c to stop it, and then did vagrant ssh, I get in. I can also get in after it times out.

Guest os can be booted directly with VirtualBox without any problem

I tried downgrading Vagrant, but only 1.3.5 seems to support the current version of Virtualbox

Same here:

Vagrant 1.3.5
Virtualbox 4.3.2

Host os: OSX Mavericks, fully updated
Guest ok: Centos 6

The guest boots, but vagrant aka ruby is holding at 100% cpu. Eventually it times out. If I use ctrl-c to stop it, and then did vagrant ssh, I get in. I can also get in after it times out.

Guest os can be booted directly with VirtualBox without any problem

I tried downgrading Vagrant, but only 1.3.5 seems to support the current version of Virtualbox

@Sureiya

This comment has been minimized.

Show comment Hide comment
@Sureiya

Sureiya Nov 30, 2013

Also having this problem
Vagrant 1.3.5
Virtualbox 4.3.4

Windows 8.1 Host
The official vagrant precise32 and 64 images.

I'm able to use vagrant ssh after.

The VM comes up in seconds, and increasing the timeout to an insanely high value does nothing.

Sureiya commented Nov 30, 2013

Also having this problem
Vagrant 1.3.5
Virtualbox 4.3.4

Windows 8.1 Host
The official vagrant precise32 and 64 images.

I'm able to use vagrant ssh after.

The VM comes up in seconds, and increasing the timeout to an insanely high value does nothing.

konstantint added a commit to konstantint/vagrant that referenced this issue Oct 23, 2014

Addresses issue #2163
In the situation where the SSH key has invalid permissions/owner, the reconnect-loop keeps failing repeatedly yet stays silent about the reasons. A message must be reported from the default exception handler (added). In addition, the situations where the SSH key owner or permissions are wrong must lead to a proper failure (added). Ideally, though, the owner/permissions check must happen before launching the VM, hence this is not a perfect fix.
@konstantint

This comment has been minimized.

Show comment Hide comment
@konstantint

konstantint Oct 23, 2014

Contributor

Encountered the problem today. I believe the cause for most of the reports above is the wrong setting of the owner/permissions of the ~/.vagrant.d/insecure_private_key file that Vagrant uses to log into the new machine. So, until the fix is incorporated in the newer version, make sure the private key file is owned by the same user that runs Vagrant, and has permissions 600.

Contributor

konstantint commented Oct 23, 2014

Encountered the problem today. I believe the cause for most of the reports above is the wrong setting of the owner/permissions of the ~/.vagrant.d/insecure_private_key file that Vagrant uses to log into the new machine. So, until the fix is incorporated in the newer version, make sure the private key file is owned by the same user that runs Vagrant, and has permissions 600.

mitchellh added a commit that referenced this issue Oct 23, 2014

Merge pull request #4696 from konstantint/patch-1
core: raise errors if bad key perms/owner [GH-2163]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment