我的流浪汉昨晚工作得很好。我刚打开电脑,点击《流浪者》,这就是我得到的:

==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...

有人吃过这个吗?vagrant在网络上还没有被广泛报道,我也找不到发生这种情况的原因。


当前回答

FWIW—我的问题是由于使用了一个非常旧的配置文件而不是一个新的配置文件。使用新的配置文件(从而调整/改变DSL)立即解决了我的问题。

其他回答

就像有些人已经指出的那样,如果VirtualBox映像没有正确引导,就会出现错误。对我来说,在《Vagrant》中使用GUI模式并没有太大帮助,因为它只显示一个黑色窗口。在virtualbox GUI中,我检查了虚拟机的设置,发现操作系统设置不正确(Debian 32而不是64位)。

所以我只能建议手动检查虚拟机的VirtualBox设置,让虚拟机启动,而不是首先使用Vagrant。

我找到的解决方案是检查连接到NAT的适配器1中的电缆连接选项。我真的不知道,这是我的第四个流浪者盒子,但这是唯一一个没有选中电缆连接选项的盒子,检查它后,它工作了。

如果您正在使用包装层(如Kitchen CI),并且正在运行32b主机,则必须抢先安装Vagrant盒子。它们的默认提供程序是二进制文件的opscode“家族”。

所以在厨房创建default-ubuntu-1204之前,请确保您使用:

vagrant box add default-ubuntu-1204 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04-i386_chef-provisionerless.box

如果您的主机不支持字大小虚拟化,则使用32b映像

需要反复检查的一件事是,您的计算机BIOS中是否启用了硬件虚拟化。

我的问题是相同的超时字符串,但我只能在GUI中看到黑屏。

我刚刚安装的一台笔记本电脑一直显示同样的问题。经过几个小时的搜索,我终于找到了一个提示,看看BIOS是否启用了硬件虚拟化。

以下是我找到的帖子内容:

我发现仍然有一些用户遇到了这个问题。因此,我将尝试在下面总结一些可能的解决SSH超时问题的方法:

Make sure your firewall or antivirus is not blocking the program (which I doubt will happen often) Give your vagrant machine some time for timeouts to happen. If you dont have a very fast PC / Mac, the VM will take while to boot into an SSH ready state, so timeouts will happen. Therefore, first try to let vagrant timeout COMPLETELY before concluding that there is a fault. If vagrant times out completely then increase the timeout limit in the vagrant file to a few min and try again. If that still doesnt work, then try to clean boot your vagrant machine through the VirtualBox interface and enable the GUI of the machine beforehand. If the GUI doesn't show anything happening (ie. just blackscreen, no text) while it is booting, then your vagrant machine has got problems. Destroy the entire machine through the VB interface and reinstall. Delete the ubuntu image files in the Vagrant Images folder in the user folder and redownload and install. Do you even have an intel processor that supports 64bit hardware virtualisation? Google it. If you do, make sure there is no setting in your Bios disabling this feature. Disable hyper-v feature if you are running windows 7 or 8. Google how to disable. Make sure you are running through an SSH enabled client. Use Git bash. Download: http://git-scm.com/downloads Install a 32bit version of ubuntu like trusty32 or precise32. Just change the version in the vagrant file and reinstall vagrant in new directory. Make sure you are using the latest vagrant and virtualbox versions. Last resorts: Format your computer, reinstall windows and buy an intel core isomething processor.

希望这能有所帮助。

也许这是一个太简单的答案,以帮助许多人,但值得一试,如果你没有:做一个“流浪者暂停”,而不是“流浪者暂停”,然后重新启动VM与“流浪者up”。

我认为我的问题是由于一些“kworker”进程出现bug,并且在VM中不断超时,所以做硬重启似乎正确地重新加载进程,而保存和恢复只是在其破碎状态下恢复破碎的进程。