Vagrant up takes a long time after "Waiting for machine to boot. This may take a few minutes..." to finish booting
Asked Answered
V

11

16

I have an ubuntu virtualbox. Everything works fine, except that on boot, it takes about 5 or more minutes after the message

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

before it finishes booting:

➜  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

This box used to be much quicker (about 30s to boot). So I think it is a network config that causes a timeout or something like that.

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

but without success. (I tried the fix Resolve it and the workaround 2.).

I also tried removing any 127.0.0.1 entries in my /etc/hosts files. Without success.

Any hint ?

OS / Versions:

Host: OSX 10.8.5
Guest: Ubuntu 12.05
Virtualbox: 4.2
Veery answered 8/1, 2014 at 18:16 Comment(2)
It's hard to diagnose from just this. Have you tried enabling the virtualbox gui in your Vagrantfile, so you can watch the console as it boots?Pius
it does say "this may take a few minutes", so I'm not sure there's really a problem.Marianamariand
Y
13

You are using a box which has virtualbox guest additions 4.3.x , yet your host is running 4.2.x

Because of this discrepancy, Virtualbox is unable to execute some command that is part of the create process.

Either getting a new box running guest additions 4.2.x, or upgrading your virtualbox to 4.3.x will likely solve this issue.

Update

Try setting the following in your vagrant file

config.vm.boot_timeout = 300

Also try turning on debuging

vagrant up --debug

Update 2

Some vm's just don't play nicely with incompatible versions of guest additions. For example, a centos and debian box from the same company. The centos will timout, while the debian will work fine.

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

Yerga answered 15/1, 2014 at 0:13 Comment(1)
I use a similar arrangement and experience no odd startup display. As the warning says, this mismatch is mostly harmless.Pius
B
8

This can also occur if vagrant isn't able to make an SSH connection.

It seems to not report any error for why it hangs in this case.

Se the GUI to show:

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

You may see the "dev login:" or other prompt like everything is just fine.

Then you may remember you changed the SSH keyset on the guest last night...

Solution: Tell vagrant where the private key is on the host.

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

Public Key Needs to be on guest too.

This will only work if you have already put the matching public key in the authorized_keys file on the guest.

This varies by OS, but on the common Precise64 box, it looks something like this from a terminal:

Linux Host with openssh-client

ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Mac Host

cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

There is also a port of ssh-copy-id for mac. https://github.com/beautifulcode/ssh-copy-id-for-OSX

This SO post has a simple inline shell provisioner to swap out the authorized_keys when provisioning a machine to make it automatic. Vagrant insecure by default?

Bunt answered 6/3, 2014 at 18:59 Comment(0)
S
2

I have had this occasionally: the VM takes a long time to boot up, and subsequently there's something wrong with its networking (the site I'm running on it becomes inaccessible).

For me, this was fixed by the following:

  1. vagrant ssh into the VM
  2. In the VM, run sudo /etc/init.d/networking restart
Soaring answered 30/7, 2014 at 8:49 Comment(0)
M
2

@spuder's suggestion of vagrant up --debug fixed this problem for me. It seemed that the VirtualBox GUI ran more smoothly and popped up a window sooner in the process. I had turned that on the way others suggested:

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

and had set config.vm.boot_timeout = 600.

This was in relation to the setup for the Udacity course Full Stack Foundations.

Moulmein answered 2/8, 2015 at 11:3 Comment(1)
This worked for me! Host: Windows Server 12, VM:ubuntu/precise32, VirtualBox 5.1Discotheque
F
1

Not sure if you already got this solved, but I had same error and to fix it I removed issued dhcp leases on vagrant prior to restart it.

@ your local you may poweroff the VM using

VBoxManage controlvm <vmname> poweroff

Then on VirtualBox you must to remove the dhcp

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

You will find additional information to guide you throu

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

Flournoy answered 14/2, 2014 at 13:17 Comment(0)
V
0

Fixed the issue. What I did:

  • updated virtualbox to 4.3.0
  • updated Vagrant to 1.4.2 (I think 1.4.3 would have worked the same)
  • followed this fix (for updating vBoxAdditions): https://gist.github.com/zbal/7800423

Notes:

  • Upgrading virtualbox is needed because virtualbox and vboxGuestAdditions are compatible. (my vBoxGuestAdditions was too recent)
  • Upgrading vagrant is needed because vagrant 1.3 doesn't work with virtualbox 4.3 (vagrant 1.4 does).
  • The fixed I did is an updated version of this one: https://gist.github.com/fernandoaleman/5083680

Other notes:

  • Changing config.vm.boot_timeout = 300 didn't help

Edit: Also try running remove /etc/udev/rules.d/70-persistent-net.rules in your guest machine.

Veery answered 15/1, 2014 at 10:1 Comment(0)
C
0

Try generating insecure_private_key

I solved this by removing the insecure_private_key, located under ~/.vagrant.d

maybe the reason is insecure_private_key file is old

Cherisecherish answered 24/10, 2014 at 9:43 Comment(0)
D
0

I solved this problem:

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

Some also can do like this:

Warning: Authentication failure. Retrying...
Dwarf answered 29/10, 2015 at 13:25 Comment(0)
L
0

Try to uncomment the line:

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

inside the VagrantFile

Latterll answered 5/12, 2016 at 19:45 Comment(0)
G
0

For the benefit of others who stumble across this symptom, I have (recently) seen this, and ultimately discovered that the cause in my case was that the underlying box didn't have AMD-V turned on in the BIOS, and so the guest wasn't booting. Even knowing this, I couldn't find it in the Logs, but discovered it by trying to boot the underlying VirtualBox in full UI mode.

Gottschalk answered 23/10, 2019 at 18:10 Comment(0)
O
-1

In Virtualbox Manager, choose the right VM, then right-click Settings → Network. Enable Adapter 1 → Cable connected. Finally, execute

$vagrant reload
Overscore answered 23/12, 2015 at 16:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.