Any way of diagnosing a slow 'vagrant up'?

[JK Laiho]

(Apologies if this is a repost, but my original post to Google Groups two days ago seems to not have appeared here.)

I've got a misbehaving Vagrant box that takes forever to boot, and I'd like to be able to diagnose the reason.

vb.gui = True doesn't help. After the kernel part of booting is finished, the screen is not updated before the login prompt finally appears. vagrant up with debug mode is extremely verbose, yet seems to indicate nothing more than the fact that SSH isn't ready just yet.

Is there some way I could actually see what messages are printed during service startup? Failing that, any way to see after the fact any messages printed or timeouts hit during that period?

Googling for slow vagrant boots provides plenty of results, but there are seemingly endless different workarounds with inconsistent success rates. I'd like to narrow the possibilities before blindly trying dozens of different combinations.

Vagrant is 1.4.3. Virtualbox is at 4.3.7r91560. (The issue has been present with older versions of each, too.) The box is running 64-bit Ubuntu 13.10, the default cloud image off vagrantbox.es. The guest additions are up-to-date (I use vagrant-vbguest for that).

- JK Laiho

[Alvaro Miranda Aguilera]

vagrant won't be slowing down or speeding up your machine.

perhaps you download a machine that many things that you don't need at all.

my suggestion will be try a official box from vagrantup, or ubuntu, and add yourself what you need, in ubuntu is not hard, is pretty easy, in that way you will get way more control of what you need

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[JK Laiho]

vagrant won't be slowing down or speeding up your machine.

I should clarify: this particular box boots slower than some of my other boxes on the same hardware.

If indeed this particular machine is slower than some other machines would be, I still need a way to diagnose why that is, so my original question still stands.

[Alvaro Miranda Aguilera]

once the machine have been created, you can take over virtualbox or vmware, and check manually what is doing.

the chances that one particular machine is slow because of vagrant, are very low if any.

What you can test, is do a vagrant destroy, and comment out any script you have in the vagrant file..

--

[JK Laiho]

OK, solved it. The boot process was being hidden by Ubuntu. It added "console=tty1 console=tty0" to the kernel line of the Grub config. I booted the box directly with VirtualBox and entered the Grub menu to remove them prior to booting. Doing so displayed the entire boot process. It was waiting on network connectivity for more than three minutes in total.

Turns out the directives Vagrant had automatically inserted for eth1 into /etc/network/interfaces were causing this. eth1 was a bridged interface, bound to en0 (Airport) on my Mac. I removed the interface from Vagrantfile, but the delays persisted. The eth1 removal did not make Vagrant update /etc/network/interfaces, so I removed the section by hand.

This fixed it. The box now boots in under 20 seconds. I'm making do without the bridged interface with a host-only interface and some pfctl port forwards on the Mac side.