Closed brandondrew closed 12 years ago
I have the problem with both Ruby 1.9.2 & Vagrant 1.0.2 as well as Ruby 1.9.3 & Vagrant 1.0.3.
After skimming through the entire (exhaustively long) DEBUG info, two things stand out to me. The first is that there is a lot of info about _other_ VMs other than the one I'm booting. Is this normal?
The second thing that stands out to me is that "Remaining to timeout:" keeps getting set back up to 32000, even though it occasionally goes down to 31999 or 31998. That seems very strange.
The full DEBUG info was cut off. There seems to be a lot of repetition, but here's how it is supposed to end:
VRDEActiveConnection="off"
VRDEClients=0
GuestMemoryBalloon=0
GuestOSType="Linux26_64"
GuestAdditionsRunLevel=2
GuestAdditionsVersion="4.1.18r78361"
GuestAdditionsFacility_VirtualBox Base Driver=50,1344620841213
GuestAdditionsFacility_VirtualBox System Service=50,1344620849710
GuestAdditionsFacility_Seamless Mode=0,1344620841213
GuestAdditionsFacility_Graphics Mode=0,1344620841213
SnapshotName="failing_to_boot_1"
SnapshotUUID="4492fac3-9e45-40f4-b9f1-2c12ce00673a"
SnapshotName-1="added test file"
SnapshotUUID-1="9870481a-869f-47ad-aef5-fefdf70f8f5b"
SnapshotName-2="before restoring 'failing_to_boot_1'"
SnapshotUUID-2="35c14999-3c6b-431a-9387-d446ad693648"
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG ssh: Checking whether SSH is ready...
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
ERROR warden: Error occurred: open failed (1)
c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connection/channel.r
b:524:in `do_open_failed': open failed (1) (Net::SSH::ChannelOpenFailed)
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:541:in `channel_open_failure'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:456:in `dispatch_incoming_packets'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:213:in `preprocess'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:197:in `process'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:161:in `block in loop'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:161:in `loop'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:161:in `loop'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/channel.rb:269:in `wait'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/net-ssh-2.2.2/lib/net/ssh/connect
ion/session.rb:355:in `exec!'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/communi
cation/ssh.rb:100:in `connect'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/communi
cation/ssh.rb:29:in `block in ready?'
from c:/Languages/Ruby/1.9.2/lib/ruby/1.9.1/timeout.rb:58:in `timeout'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/communi
cation/ssh.rb:28:in `ready?'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/boot.rb:29:in `block in wait_for_boot'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/boot.rb:28:in `times'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/boot.rb:28:in `wait_for_boot'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/boot.rb:15:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/customize.rb:31:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/sane_defaults.rb:39:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/network.rb:62:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/clear_network_interfaces.rb:26:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/host_name.rb:10:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/share_folders.rb:20:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/clear_shared_folders.rb:13:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/nfs.rb:41:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/prune_nfs_exports.rb:15:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/provision.rb:27:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/forward_ports.rb:24:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/check_port_collisions.rb:42:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
env/set.rb:16:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/clear_forwarded_ports.rb:13:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/clean_machine_folder.rb:17:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
vm/check_accessible.rb:18:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
general/validate.rb:13:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
general/check_virtualbox.rb:23:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
warden.rb:33:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
builder.rb:92:in `call'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
runner.rb:49:in `block in run'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/util/bu
sy.rb:19:in `busy'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/action/
runner.rb:49:in `run'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/vm.rb:1
92:in `run_action'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/vm.rb:1
52:in `start'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/command
/up.rb:28:in `block in execute'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/command
/base.rb:116:in `block in with_target_vms'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/command
/base.rb:111:in `each'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/command
/base.rb:111:in `with_target_vms'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/command
/up.rb:24:in `execute'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/cli.rb:
42:in `execute'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/lib/vagrant/environ
ment.rb:167:in `cli'
from c:/Languages/Ruby/1.9.2/lib/ruby/gems/1.9.1/gems/vagrant-1.0.2/bin/vagrant:43:in `
<top (required)>'
from c:/Languages/Ruby/1.9.2/bin/vagrant:19:in `load'
from c:/Languages/Ruby/1.9.2/bin/vagrant:19:in `<main>'
On my most recent vagrant up
it went past that point and hung after this:
[www] Waiting for VM to boot. This can take a few minutes.
[www] VM booted and ready for use!
[www] Detected Virtualbox Guest Additions 4.1.18 --- OK.
[www] Configuring and enabling network interfaces...
When the vm is launched, I can't connected manually with ssh. It said ssh: Could not resolve hostname 127.0.0.1:2222: nodename nor servname provided, or not know
@laupiFrpar : I'm able to ssh in, so I don't think it's the same issue.
Despite discussing issues, would you mind me creating a wiki page for hints to workaround this (and relaed) issues?
There are already hints for workarounds distributed over a several similar issues. I would like to sum them up and add my own experience to give the "userland" side a place.
Ok?
I don't mind at all.
I have started a wiki page on this: https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes%22
Hi, I found the way to reproduce this issue. Default configuration of ssh.timeout is too short to make connection in some environments. I cannot boot centos 6.3 with default configuration but I set ssh.timeout to 20 then the vm can be started.
Also I made a patch to inspect ssh connection, you can get it from here. The following log is outputted by vagrant applied with my patch when I try to boot centos 6.3 with default config:
D, [2012-09-10T04:35:01.078074 #13346] DEBUG -- net.ssh.transport.session[3ff5de1c596c]: establishing connection to 127.0.0.1:2222
D, [2012-09-10T04:35:01.078531 #13346] DEBUG -- net.ssh.transport.session[3ff5de1c596c]: connection established
I, [2012-09-10T04:35:01.078695 #13346] INFO -- net.ssh.transport.server_version[3ff5de1b8820]: negotiating protocol version
D, [2012-09-10T04:35:01.094239 #13346] DEBUG -- net.ssh.transport.server_version[3ff5de1b8820]: remote is `SSH-2.0-OpenSSH_5.3'
D, [2012-09-10T04:35:01.094356 #13346] DEBUG -- net.ssh.transport.server_version[3ff5de1b8820]: local is `SSH-2.0-Ruby/Net::SSH_2.2.2 x86_64-darwin11.4.0'
D, [2012-09-10T04:35:01.101687 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: read 784 bytes
D, [2012-09-10T04:35:01.101954 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: received packet nr 0 type 20 len 780
I, [2012-09-10T04:35:01.102106 #13346] INFO -- net.ssh.transport.algorithms[3ff5de1a2944]: got KEXINIT from server
I, [2012-09-10T04:35:01.102372 #13346] INFO -- net.ssh.transport.algorithms[3ff5de1a2944]: sending KEXINIT
D, [2012-09-10T04:35:01.102639 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 0 type 20 len 556
D, [2012-09-10T04:35:01.102791 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 560 bytes
I, [2012-09-10T04:35:01.102859 #13346] INFO -- net.ssh.transport.algorithms[3ff5de1a2944]: negotiating algorithms
D, [2012-09-10T04:35:01.103326 #13346] DEBUG -- net.ssh.transport.algorithms[3ff5de1a2944]: negotiated:
* kex: diffie-hellman-group-exchange-sha1
* host_key: ssh-rsa
* encryption_server: aes128-cbc
* encryption_client: aes128-cbc
* hmac_client: hmac-sha1
* hmac_server: hmac-sha1
* compression_client: none
* compression_server: none
* language_client:
* language_server:
D, [2012-09-10T04:35:01.103398 #13346] DEBUG -- net.ssh.transport.algorithms[3ff5de1a2944]: exchanging keys
D, [2012-09-10T04:35:01.103873 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 1 type 34 len 20
D, [2012-09-10T04:35:01.103999 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 24 bytes
D, [2012-09-10T04:35:01.107799 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: read 152 bytes
D, [2012-09-10T04:35:01.108039 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: received packet nr 1 type 31 len 148
D, [2012-09-10T04:35:01.115223 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 2 type 32 len 140
D, [2012-09-10T04:35:01.115412 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 144 bytes
D, [2012-09-10T04:35:01.124867 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: read 720 bytes
D, [2012-09-10T04:35:01.125079 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: received packet nr 2 type 33 len 700
D, [2012-09-10T04:35:01.131097 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 3 type 21 len 20
D, [2012-09-10T04:35:01.131240 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 24 bytes
D, [2012-09-10T04:35:01.131374 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: received packet nr 3 type 21 len 12
D, [2012-09-10T04:35:01.131897 #13346] DEBUG -- net.ssh.authentication.session[3ff5de82c1c0]: beginning authentication of `vagrant'
D, [2012-09-10T04:35:01.132111 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 4 type 5 len 28
D, [2012-09-10T04:35:01.132205 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 52 bytes
D, [2012-09-10T04:35:01.132964 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: read 52 bytes
D, [2012-09-10T04:35:01.133118 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: received packet nr 4 type 6 len 28
D, [2012-09-10T04:35:01.133278 #13346] DEBUG -- net.ssh.authentication.session[3ff5de82c1c0]: trying publickey
D, [2012-09-10T04:35:01.133780 #13346] DEBUG -- net.ssh.authentication.agent[3ff5de83b184]: connecting to ssh-agent
D, [2012-09-10T04:35:01.133981 #13346] DEBUG -- net.ssh.authentication.agent[3ff5de83b184]: sending agent request 1 len 51
D, [2012-09-10T04:35:01.134156 #13346] DEBUG -- net.ssh.authentication.agent[3ff5de83b184]: received agent packet 2 len 5
D, [2012-09-10T04:35:01.134239 #13346] DEBUG -- net.ssh.authentication.agent[3ff5de83b184]: sending agent request 11 len 0
D, [2012-09-10T04:35:01.134397 #13346] DEBUG -- net.ssh.authentication.agent[3ff5de83b184]: received agent packet 12 len 315
D, [2012-09-10T04:35:01.134949 #13346] DEBUG -- net.ssh.authentication.methods.publickey[3ff5de838164]: trying publickey (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6)
D, [2012-09-10T04:35:01.135218 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: queueing packet nr 5 type 50 len 348
D, [2012-09-10T04:35:01.135337 #13346] DEBUG -- tcpsocket[3ff5de1c0958]: sent 372 bytes
D, [2012-09-10T04:35:11.081637 #13346] DEBUG -- net.ssh.transport.session[3ff5de04b5a0]: establishing connection to 127.0.0.1:2222
D, [2012-09-10T04:35:11.082464 #13346] DEBUG -- net.ssh.transport.session[3ff5de04b5a0]: connection established
I, [2012-09-10T04:35:11.082673 #13346] INFO -- net.ssh.transport.server_version[3ff5de0167b0]: negotiating protocol version
D, [2012-09-10T04:35:11.090738 #13346] DEBUG -- net.ssh.transport.server_version[3ff5de0167b0]: remote is `SSH-2.0-OpenSSH_5.3'
This is a dupe of #391. There is a LOT of info on this bug there. In short: its complicated.
You can see I'm working on various workarounds there. If you have any more to add please add it there. Sorry about this.
Actually, in my case it turned out to be caused by something in my vagrant user's .bashrc or .bash_profile. I didn't realize that the boot up process involved ssh'ing in as vagrant (though that should have probably been obvious!) and didn't figure the cause out for a while because of some red herrings. As background: my networking setup is complicated by the fact that I have to deal with a non-standard (Microsoft!) proxy server, and thus need run a local "child" proxy (Cntlm--I couldn't live without it!) on both host and guest operating systems, but everything blew up once when I switching between proxied and unproxied use and forgot to restart my guest OS and VB. It appeared that the problems I was having with Vagrant were related to the networking problems caused by this "blow up" but they were not--they just didn't show up until I had to restart the VM. For an example of the problems that confused matters, my Internet Options on Windows were corrupted, and had to be deleted and replaced before certain networking problems (logging into certain web sites failed even with correct credentials, and other things I can't remember) went away. (Even though the proxy settings I used after recreating the Internet Optoins were the same as those I was using before.) Though these problems were not related, they happened to coincide. So I spent lots of time digging through things that appeared to be related to the problem, but weren't. All of this threw me off the trail of the real problem, which was simply a matter of fixing my login scripts. (The problem with the login scripts didn't prevent interactive logins, making it even less obvious.)
So in short: in my case it _wasn't_ a bug in Vagrant. It would, however, be nice if Vagrant did something to detect the sort of problem I had, and give a message explaining to the user what's going on. That would be more helpful than a stacktrace. I can give more info if you're interested in adding that sort of error checking.
I would give it a try ... What are your plans to release the new version of Vagrant (current master)?
One thing I did that helped diagnose this issue was take a screengrab of the VM:
VBoxManage controlvm vagranttest_1348502727 screenshotpng foo.png
google-chrome foo.png
This brought up a screen on which Vagrant was complaining that I was using a 64 bit VM :
"This kernel requires an x86-64 CPI, but only detected an i686 CPI. Unable to boot - please use a kernel appropriate for your CPU"
Hope this helps someone
Found another way to reproduce this issue. And a way to workaround.
Would appreciate when adding your experiences there.
The suggested scenario to replicate worked for me, but the fix didn't. Changing my base box from Ubuntu 12.04 x86_64 to Lucid x86 did the trick.
I just got one of these hangs (first in a while) and found a workaround. When I started the VM using VBoxManage, I was asked to run fsck manually. After I did this, shutdown, then used vagrant up, everything appeared to work. This problem was not communicated back through vagrant though.
tl;dr - If it's not a network issue, ensure you can boot and log in to the box with VBoxManage.
The screenshot method mentioned by gavD gave met this... happens after a vagrant halt && vagrant up... not network related at all?
And I was under the impression that it didn’t happen with vagrant reload but, after 2 reloads, same picture :-(
Tried with precise32 and precise64 box, and with ubuntu-server-12042-x64-vbox4210, all the same results... stumped, and going to sleep...
This totally fixed it. Wow! That's some weirdness.
https://github.com/mitchellh/vagrant/issues/391#issuecomment-12264830
upgrade ps to higher version to fix the issue.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
The really odd thing is that sometimes it gets past this point and hangs at "Configuring and enabling network interfaces...". It doesn't exactly alternate between the two, but it seems random whether it will hang at one or the other. In the case where it doesn't get past "Waiting for VM to boot." it eventually ends in a stack trace. In the case of hanging on the other line, it just hangs there forever. (Well, at least it'll sit there overnight without dying with a stack trace.)
I was suspecting that the problem was with shared folders (since it never gets to that) but I disabled all the shared folders in my Vagrantfile and that made no difference.
Here are the results of attempting to do this with logging set at DEBUG.
I'm running on a Windows host with a CentOS 6.2 guest.