当你被上面描述的方式困在你的流浪机器上时，不需要以gui模式启动(没有X服务器是不可能的)。

当您的虚拟机正在引导时，在一个单独的终端窗口中，只需找出正在运行的机器的id。

vboxmanage list runningvms

结果是这样的:

"projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx}

通常，VM只是等待您在引导加载程序中选择一个选项。您可以通过controlvm向虚拟机发送相应的keycode(在本例中为Enter):

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

就是这样。虚拟机将继续启动过程。

而不是ctrl-d-ing出虚拟框，因为我习惯做每当我ssh到任何东西，我相信流浪者更喜欢你进入另一个终端，并做一个:

流浪汉瘸腿

让盒子停下来。然后回到VB就没有问题了。

我也有同样的问题，但其他答案都不能完全解决我的问题。@Kiee的回答很有帮助，尽管我在GUI中看到的是一个黑屏(在左上角有下划线，虚拟盒子中的这个问题也在堆栈溢出中单独提出，同样没有帮助)。

最终，一个解决方案被证明非常简单:检查虚拟机的版本。

更准确地说，我从别人那里得到了一个64位Debian的盒子，但Virtual box坚持把它当作32位的，这一点我没有注意到。要更改它，请打开虚拟框，然后打开终端并运行

vagrant up

排队等候

default: SSH auth method: private key

现在您可以按ctrl+C(或等待超时)并运行

vagrant halt

你的虚拟机不会被摧毁，所以你可以在虚拟盒子的菜单中看到它，但它会被关闭，所以你可以更改设置。在菜单中选择您的机器，单击“设置”->“通用”，并选择适当的“版本”，对我来说是“Debian(64位)”。这种类型之后又流浪起来。

如果这是你的情况(或“设置”中的不同更改解决了你的问题)，你可以从修复的输入中创建新框

vagrant package --output mynew.box

更多细节:主机32位Ubuntu 12.04，客户64位Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

My solution turned out to be none of the above exactly. I'm running Ubuntu 14 as guest inside a Windows 7 host. I had been running this vagrant box fine, but I started it up again after not using it for a couple of months, and it kept coming up with the SSH connection timeout. It turned out that somehow the key pair didn't work - so I copied the Vagrant public key into Ubuntu according to the instructions on this page. But that wasn't all. I then discovered that the private key in my base box was different than the private key here. Putting this private key in as the vagrant_private_key file in C:\Users\your-user.vagrant.d\boxes\vagrant-box-name\nnnnnnnn\virtualbox after placing the public key into Ubuntu fixed the problem.

我对这个问题的解决方案是，我的旧笔记本电脑启动时间太长了。我打开虚拟盒子，连接到盒子，等待屏幕加载。花了大约8分钟。

然后它连接并安装了我的文件夹，继续运行。

有时候要有耐心!

我通过在/etc/fstab中添加一个新条目来测试我的vagrant VM中挂载的文件夹。后来我注销了，跑了个流浪汉，但当我跑了个流浪汉，我得到:

SSH auth method: private key
Warning: Remote connection disconnect. Retrying...

I read all these posts and tried all the ones that seemed relevant for my case (except for vagrant destroy, which would have certainly fixed my problem, but was a last resort in my case). The post by @Kiee gave me the idea to try to boot my VM directly from the VirtualBox GUI. During the boot process the VM halted itself and was asking me if I wanted to skip mounting the test folder that I had added earlier to /etc/fstab. (That's why vagrant couldn't boot the VM.) After answering 'NO' the VM booted no problem. I logged in, removed the naughty line from my fstab, and shutdown the VM.

在那之后，流浪汉就能很好地踢足球了。

外卖吗?如果突然间vagrant无法引导回您的VM，请尝试直接从提供商引导(在我的情况下是VirtualBox)。您的引导可能挂起了与SSH完全无关的东西。