【问题标题】:Vagrant up takes a long time after "Waiting for machine to boot. This may take a few minutes..." to finish bootingVagrant up 在“等待机器启动。这可能需要几分钟......”之后需要很长时间才能完成启动
【发布时间】:2014-01-08 18:16:59
【问题描述】:

我有一个 ubuntu 虚拟机。一切正常,除了在启动时,消息后大约需要 5 分钟或更长时间

Waiting for machine to boot. This may take a few minutes...

在它完成启动之前:

➜  my_box  vagrant reload
/Users/pinouchon/.vagrant.d/boxes/my_box/virtualbox/include/_Vagrantfile:5: warning: already initialized constant VAGRANTFILE_API_VERSION
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
# More port forwards 
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
# waits about 5 minutes at this point, then:

[default] Machine booted and ready!
[default] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
cause things such as shared folders to not work properly. If you see
shared folder errors, please update the guest additions within the
virtual machine and reload your VM.

Guest Additions Version: 4.3.0
VirtualBox Version: 4.2
[default] Configuring and enabling network interfaces...
[default] Mounting shared folders...
[default] -- /vagrant

这个盒子过去要快得多(大约 30 秒才能启动)。所以我认为这是一个导致超时或类似情况的网络配置。

它尝试了这里提出的修复: https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes%22

但没有成功。 (我尝试了修复 Resolve itworkaround 2.)。

我还尝试删除我的 /etc/hosts 文件中的任何 127.0.0.1 条目。没有成功。

有什么提示吗?

操作系统/版本:

Host: OSX 10.8.5
Guest: Ubuntu 12.05
Virtualbox: 4.2

【问题讨论】:

  • 仅凭此很难诊断。您是否在您的Vagrantfile 中尝试过enabling the virtualbox gui,这样您就可以在控制台启动时观看它?
  • 它确实说“这可能需要几分钟”,所以我不确定是否真的有问题。

标签: ubuntu-12.04 osx-mountain-lion vagrant


【解决方案1】:

您正在使用一个带有 virtualbox 来宾添加 4.3.x 的盒子,但您的主机正在运行 4.2.x

由于这种差异,Virtualbox 无法执行创建过程中的某些命令。

无论是获得一个运行guest added 4.2.x 的新机器,还是将您的virtualbox 升级到4.3.x 都可能会解决这个问题。

更新

尝试在您的 vagrant 文件中设置以下内容

config.vm.boot_timeout = 300

同时尝试开启调试

vagrant up --debug

更新 2

有些虚拟机不能很好地处理不兼容的来宾添加版本。例如,来自同一家公司的 centos 和 debian 盒子。 centos 会超时,而 debian 会正常工作。

http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box
http://puppet-vagrant-boxes.puppetlabs.com/debian-70rc1-x64-vbox4210.box

【讨论】:

  • 我使用了类似的安排,没有遇到奇怪的启动显示。正如警告所说,这种不匹配基本上是无害的。
【解决方案2】:

如果 vagrant 无法建立 SSH 连接,也会发生这种情况。

在这种情况下它为什么挂起似乎没有报告任何错误。

Se 显示的 GUI:

 # Show GUI or not.
config.vm.provider "virtualbox" do |v|
  v.gui = true
end

您可能会看到“开发登录:”或其他提示,一切都很好。

那么你可能还记得你昨晚更改了访客的 SSH 密钥集...

解决方案:告诉 vagrant 私钥在主机上的什么位置。

 # Use a new keyset
config.ssh.private_key_path = "~/.ssh/id_rsa"

公钥也需要在访客身上。

这仅在您已将匹配的公钥放入来宾的 authorized_keys 文件时才有效。

这因操作系统而异,但在常见的 Precise64 机器上,从终端看是这样的:

带有 openssh-client 的 Linux 主机

ssh-copy-id -i .ssh/id_rsa.pub user@hostname.example.com

Mac 主机

cat ~/.ssh/id_rsa.pub | ssh user@hostname.example.com "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

还有一个用于 mac 的 ssh-copy-id 端口。 https://github.com/beautifulcode/ssh-copy-id-for-OSX

这篇 SO 帖子有一个简单的内联 shell 配置程序,用于在配置机器时换出 authorized_keys 以使其自动化。 Vagrant insecure by default?

【讨论】:

    【解决方案3】:

    我偶尔会遇到这种情况:VM 需要很长时间才能启动,随后它的网络出现问题(我在其上运行的站点变得无法访问)。

    对我来说,这是通过以下方式解决的:

    1. vagrant ssh 进入虚拟机
    2. 在虚拟机中,运行sudo /etc/init.d/networking restart

    【讨论】:

      【解决方案4】:

      不确定你是否已经解决了这个问题,但我遇到了同样的错误,为了修复它,我在重新启动之前删除了 vagrant 上发布的 dhcp 租约。

      @你的本地你可以使用关闭虚拟机

      VBoxManage controlvm <vmname> poweroff
      

      然后在 VirtualBox 上你必须删除 dhcp

      sudo rm -Rf /var/lib/dhcp/*
      

      您将找到更多信息来指导您完成

      https://github.com/mitchellh/vagrant/wiki/%60vagrant-up%60-hangs-at-%22Waiting-for-VM-to-boot.-This-can-take-a-few-minutes%22

      【讨论】:

        【解决方案5】:

        @spuder 对vagrant up --debug 的建议为我解决了这个问题。似乎VirtualBox GUI运行得更顺畅,并且在此过程中更快地弹出了一个窗口。我已经按照其他人建议的方式打开了它:

        config.vm.provider :virtualbox do |vb|
          vb.gui = true
        end
        

        并设置了config.vm.boot_timeout = 600

        这与 Udacity 全栈基础课程的 setup 有关。

        【讨论】:

        • 这对我有用!主机:Windows Server 12,虚拟机:ubuntu/precise32,VirtualBox 5.1
        【解决方案6】:

        解决了这个问题。我做了什么:

        • 将 virtualbox 更新到 4.3.0
        • 已将 Vagrant 更新到 1.4.2(我认为 1.4.3 也会如此)
        • 遵循此修复(用于更新 vBoxAdditions):https://gist.github.com/zbal/7800423

        注意事项:

        • 需要升级 virtualbox,因为 virtualbox 和 vboxGuestAdditions 是兼容的。 (我的 vBoxGuestAdditions 太新了)
        • 需要升级 vagrant,因为 vagrant 1.3 不适用于 virtualbox 4.3(vagrant 1.4 可以)。
        • 我所做的修复是此版本的更新版本:https://gist.github.com/fernandoaleman/5083680

        其他说明:

        • 更改 config.vm.boot_timeout = 300 没有帮助

        编辑:同时尝试在您的客户机上运行remove /etc/udev/rules.d/70-persistent-net.rules

        【讨论】:

          【解决方案7】:

          尝试生成insecure_private_key

          我通过删除位于~/.vagrant.d 下的insecure_private_key 解决了这个问题

          可能原因是insecure_private_key 文件旧

          【讨论】:

            【解决方案8】:

            我解决了这个问题:

            wget https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub -O .ssh/authorized_keys
            chmod 700 .ssh
            chmod 600 .ssh/authorized_keys
            chown -R vagrant:vagrant .ssh
            

            有些人也可以这样做:

            Warning: Authentication failure. Retrying...
            

            【讨论】:

              【解决方案9】:

              尝试取消注释该行:

              config.vm.network "private_network", ip: "192.168.33.11"

              在 VagrantFile 中

              【讨论】:

                【解决方案10】:

                为了其他偶然发现此症状的人的利益,我(最近)看到了这一点,并最终发现我的情况的原因是底层盒子没有在 BIOS 中打开 AMD-V,并且所以客人没有启动。即使知道这一点,我也无法在日志中找到它,但通过尝试以完整 UI 模式启动底层 VirtualBox 时发现了它。

                【讨论】:

                  【解决方案11】:

                  在 Virtualbox Manager 中,选择正确的虚拟机,然后右键单击设置 → 网络。启用适配器 1 → 已连接电缆。最后,执行

                  $vagrant reload
                  

                  【讨论】:

                    猜你喜欢
                    • 2013-11-15
                    • 2014-02-23
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 2021-02-28
                    • 1970-01-01
                    • 1970-01-01
                    相关资源
                    最近更新 更多