Timeout error during `vagrant up` #682

tpetchel · 2016-10-05T13:19:42Z

When I run vagrant up on bento/ubuntu-14.04 or bento/centos-7.2, I get a timeout error. Other boxes, such as ubuntu/trusty64, work fine.

I'm in an nested virtualization environment.

Host machine is Ubuntu 14.04 (bento/ubuntu-14.04) running on VMware Fusion.
Guest machines are running on VirtualBox.

My scenario used to work - I noticed the break when I upgraded to VMware Fusion 8.5. I'm not sure whether that's a factor or a coincidence. VT-x is enabled on the host.

Repro steps

Works as expected: ubuntu/trusty64

root@workstation:~# vagrant init ubuntu/trusty64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
root@workstation:~# vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Setting the name of the VM: root_default_1475671742463_5033
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 4.3.36
    default: VirtualBox Version: 5.0
==> default: Mounting shared folders...
    default: /vagrant => /root

SSH timeout: bento/ubuntu-14.04

root@workstation:~# vagrant init bento/ubuntu-14.04
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
root@workstation:~# vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/ubuntu-14.04'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-14.04' is up to date...
==> default: Setting the name of the VM: root_default_1475671874908_72192
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

SSH timeout: bento/centos-7.2

root@workstation:~# vagrant init bento/centos-7.2
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
root@workstation:~# vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/centos-7.2'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/centos-7.2' is up to date...
==> default: Setting the name of the VM: root_default_1475672366835_73211
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Versions

root@workstation:~# vagrant --version
Vagrant 1.8.4
root@workstation:~# VBoxManage --version
5.0.26r108824
root@workstation:~# vagrant box list
bento/centos-7.2   (virtualbox, 2.3.0)
bento/ubuntu-14.04 (virtualbox, 2.3.0)
ubuntu/trusty64    (virtualbox, 20160928.0.0)

The text was updated successfully, but these errors were encountered:

tpetchel · 2016-10-05T13:56:24Z

Couple updates:

So far it appears that version 2.2.9 of the bento boxes work in my nested environment.
I can bring up 2.3.0 just fine on Fusion on my Mac. This leads me to believe the issue is specific to bringing up 2.3.0 in a nested environment.

$ vagrant up --provider vmware_fusion
Bringing machine 'default' up with 'vmware_fusion' provider...
==> default: Cloning VMware VM: 'bento/ubuntu-14.04'. This can take some time...
==> default: Checking if box 'bento/ubuntu-14.04' is up to date...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Starting the VMware VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.145.131:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Forwarding ports...
    default: -- 22 => 2200
==> default: Configuring network adapters within the VM...
==> default: Waiting for HGFS to become available...
==> default: Enabling and configuring shared folders...
    default: -- /Users/thomaspetchel: /vagrant

alex-miro · 2016-10-05T23:15:25Z

Have exactly the same problem with bento/centos-7.2 and bento/ubuntu-14.04, ubuntu/trusty64 is Ok) ( all on VirtualBox MacOS)

It seems that the problem is that for whatever reason the network interfaces inside the VMs interfaces are not configured when VM is booted, so the ssh connection from the host times out after the default 5 mins.

have not looked at it further yet, will revisit when have more time.

rhoot · 2016-10-06T00:39:32Z

Same thing with bento/fedora-24, on a Windows 10 host with VirtualBox 5.0.12.

Terrabits · 2016-10-06T04:38:35Z

I had these same issues with migrating to bento/ubuntu-16.04 version 2.30 (2.29 worked for me). I am using virtualbox. Looking at the version 2.30 virtual machine, I noticed that network Adapter 1 cable connected was unchecked. Sure enough, I compared the box.ovf files for version 2.29 and 2.30 and the cable="true" setting was missing in 2.30.

I was able to get my vagrant ups to work by changing the following in (mac host) ~/.vagrant.d/boxes/bento-VAGRANTSLASH-ubuntu-16.04/2.30/virtualbox/box.ovf:

Change:
<Adapter slot="0" enabled="true" MACAddress="080027B55B5E" type="82540EM">

to:
<Adapter slot="0" enabled="true" MACAddress="080027B55B5E" cable="true" type="82540EM">

Can someone else confirm this change from 2.29 to 2.30?

greew · 2016-10-06T11:57:04Z

@Terrabits Yup, I can confirm this. After adding cable="true" to the line you mentioned, I was able to successfully boot up the machine.

Setup:

13:54 $ vagrant --version
Vagrant 1.8.5
13:55 $ VBoxManage --version
5.0.24_Ubuntur108355
13:55 $ vagrant box list
bento/ubuntu-16.04 (virtualbox, 2.2.9)
bento/ubuntu-16.04 (virtualbox, 2.3.0)
laravel/homestead  (virtualbox, 0.5.0)

rickard-von-essen · 2016-10-06T20:11:43Z

See my comment on #681 (comment) and follow the link to packer.

Terrabits · 2016-10-06T20:51:23Z

@rickard-von-essen, the suggestion in the link of upgrading virtualbox worked. I was running 5.1.6r108xxx, and am now upgraded to 5.1.6r110634. Maybe the default network settings were screwed up in one of the r- releases?

In any event, I wonder if there is value in explicitly setting cable="true" to avoid this issue? Said another way: is there a reason why cable="true" was removed from bento/ubuntu after version 2.2.9?

For those also having this issue:
It is worth noting that VirtualBox does not indicate that you need to upgrade. i.e., "Check for updates..." does not apparently recognize an incremented r-value as warranting an update. I had to manually download and install the very latest version of VirtualBox

Edit: Misquoted VirtualBox versions as 5.0.6 instead of the correct 5.1.6.

shuhaowu · 2016-10-07T03:51:36Z

Can also confirm that adding the cable=true fixes the issue for me.

See chef/bento#682

admirabilis · 2016-10-07T14:41:24Z

Since I use Vagrant with "virtualbox.gui = true", I could see the boot message that was stuck, and it was systemd saying: "[ *** ] A start job is running for Raise network interfaces".

I have managed to workaround this (before finding this thread) by switching from the ubuntu-16.04 box to ubuntu-16.04-i386, so I guess it is a commit that didn't affect the 32 bits builds yet!

rickard-von-essen · 2016-10-07T14:54:30Z

@teresaejunior @shuhaowu try to upgrade to latest VB 5.1

admirabilis · 2016-10-07T15:07:18Z

OK, thanks! I'll upgrade VBox together with Ubuntu, when Ubuntu 16.10 is released in the next few days!

WolfFlight · 2016-10-07T18:08:20Z

Have seen the exact same issues here trying to use the bento/centos6-8 box, version 2.2.9 works fine, however box version 2.3.0 fails with timeout.

shuhaowu · 2016-10-07T23:04:59Z

Also if you want to solve this issue via just Tue Vagrantfile: vb.customize ["modifyvm", :id, "--cableconnected1", "on"].

rickard-von-essen · 2016-10-08T06:41:15Z

Closing this as a duplicates #688 since that one is cleaner and with a straight answer.

MarkCWirt · 2016-11-03T13:29:39Z

I can confirm that shuhaowu's Vagrantfile fix:

vb.customize ["modifyvm", :id, "--cableconnected1", "on"]

works for bento/ubuntu-16.04 (latest Vagrant, latest VB, MacOS 10.11.6).

fiphedawg · 2016-12-18T11:45:16Z

actually figure ran into this issue trying to us kitchen. I was able to edit my .kitchen.yml file to force the cable connection:

driver:
name: vagrant
customize:
cableconnected1: "on"

markdingemanse · 2017-01-24T14:07:24Z

@Terrabits Thank you.

On VirtualBox 5.0 the initial vagrant up would fail due to a timeout error. This was because in the VM, the network adapter was not set to cable, resulting in a exhaustive search for a DHCP server. This search was longer than the timeout set in the Vagrantfile. This commit fixes that issue, by setting the connection to cable. This is also fixed by upgrading to VirtualBox 5.1 or above. For further information take a look at [this thread on github](chef/bento#682).

contactavishek · 2017-09-14T15:57:57Z

My OS is Windows Ubuntu 16.04 and I have installed Oracle VM VirtualBox Manager 5.1.26 and vagrant 1.8.5
Even I am getting this with 'vagrant up':

Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well.

If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value.

I even tried adding the following to the Vagrantfile
config.vm.boot_timeout = 600

But still getting the same timeout error. Please suggest.

spuder · 2017-09-14T16:02:51Z

@contactavishek It would be best to move this to its own github issue as this one is closed. You can then link back to this one. If you are on windows, check if you have the cable connected issue hashicorp/vagrant#7648

cheeseplus · 2017-09-25T19:56:36Z

I'm locking to prevent further asking in a dead issue.

shuhaowu added a commit to shuhaowu/rospi that referenced this issue Oct 7, 2016

Worked around a bug in bento's vagrant box

79e47ac

See chef/bento#682

rickard-von-essen closed this as completed Oct 8, 2016

rickard-von-essen added the Duplicate label Oct 8, 2016

1000miles mentioned this issue Nov 2, 2016

Switch to ssh connection via cable to fix timeouts Asquera/wheelmap-devenv#8

Merged

svpernova09 mentioned this issue Dec 1, 2016

Not able to connect to VM on Windows 7 laravel/homestead#370

Closed

sebastiaanluca mentioned this issue Dec 19, 2016

Virtualbox doesn't connect the network adapter cable laravel/homestead#383

Closed

ianmiell mentioned this issue Jan 9, 2017

Added kitchen inspec integration tests IshentRas/cookbook-openshift3#42

Merged

richard-scott mentioned this issue Feb 6, 2017

Timed out while waiting for the machine to boot fgrehm/vagrant-lxc#388

Closed

tedivm mentioned this issue Apr 19, 2017

ubuntu 16.04 network timeout on virtualbox #790

Closed

chef locked and limited conversation to collaborators Sep 25, 2017

tas50 added Triage: Duplicate Indicates an issue is a duplicate of other open issue. and removed Duplicate labels Jan 2, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Timeout error during `vagrant up` #682

Timeout error during `vagrant up` #682

tpetchel commented Oct 5, 2016 •

edited

Loading

tpetchel commented Oct 5, 2016

alex-miro commented Oct 5, 2016

rhoot commented Oct 6, 2016

Terrabits commented Oct 6, 2016

greew commented Oct 6, 2016

rickard-von-essen commented Oct 6, 2016

Terrabits commented Oct 6, 2016 •

edited

Loading

shuhaowu commented Oct 7, 2016

admirabilis commented Oct 7, 2016

rickard-von-essen commented Oct 7, 2016

admirabilis commented Oct 7, 2016

WolfFlight commented Oct 7, 2016

shuhaowu commented Oct 7, 2016

rickard-von-essen commented Oct 8, 2016

MarkCWirt commented Nov 3, 2016

fiphedawg commented Dec 18, 2016

markdingemanse commented Jan 24, 2017

contactavishek commented Sep 14, 2017

spuder commented Sep 14, 2017

cheeseplus commented Sep 25, 2017

Timeout error during vagrant up #682

Timeout error during vagrant up #682

Comments

tpetchel commented Oct 5, 2016 • edited Loading

Repro steps

Versions

tpetchel commented Oct 5, 2016

alex-miro commented Oct 5, 2016

rhoot commented Oct 6, 2016

Terrabits commented Oct 6, 2016

greew commented Oct 6, 2016

rickard-von-essen commented Oct 6, 2016

Terrabits commented Oct 6, 2016 • edited Loading

shuhaowu commented Oct 7, 2016

admirabilis commented Oct 7, 2016

rickard-von-essen commented Oct 7, 2016

admirabilis commented Oct 7, 2016

WolfFlight commented Oct 7, 2016

shuhaowu commented Oct 7, 2016

rickard-von-essen commented Oct 8, 2016

MarkCWirt commented Nov 3, 2016

fiphedawg commented Dec 18, 2016

markdingemanse commented Jan 24, 2017

contactavishek commented Sep 14, 2017

spuder commented Sep 14, 2017

cheeseplus commented Sep 25, 2017

Timeout error during `vagrant up` #682

Timeout error during `vagrant up` #682

tpetchel commented Oct 5, 2016 •

edited

Loading

Terrabits commented Oct 6, 2016 •

edited

Loading