Vagrant up takes long time after installing guest additions manually in centos box

[StalkAlex]

Not sure how to describe issue correctly whether this is bug or not. So I initialized centos/7 box, also I have vbguest plugin and it tried to install guest additions as usual during vagrant up command executing. Installation of one of the modules failed. I installed guest additions manually but before it yum update command was executed to fix building failed module. After these actions plugin showed GuestAdditions 5.0.12 running --- OK. But I get problem: vagrant up command executing time instead of seconds becomes almost 5-10 minutes. Sometimes it doesn't execute at all. It started to hangs on booting machine, checking guest additions, mounting folders. I tried debug option and as I understand vagrant was not able to define version of virtual machine. There was long time loop before each command during "up" trying to sort out different versions of Linux(ubuntu, debian, arch, funtoo etc.) and also I saw error "failed connecting to ssh agent" something like that. Not sure if it is bug of vagrant or this plugin.

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'centos/7' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 (guest) => 8080 (host) (adapter 1)
    default: 5432 (guest) => 54320 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => F:/***/*******/app
An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

timeout during server version negotiating

[gocanto]

same error here, any clue?

I have been throughout this since last 3 days :/

[sethvargo]

Hi @akaSStalkALEX

Can you please share your complete Vagrantfile and the output of the command in debug mode as a github gist?

[StalkAlex]

My up log https://gist.github.com/akaSStalkALEX/6315b40683fc7c9d64cc.
My Vagranfile https://gist.github.com/akaSStalkALEX/83812b7f43a053cd228b

I replaced some personal info in directory pathes mainly and also I recreated box again, timeout error has gone, but it still executes quite long and ssh connecting problems present as I understand from log.

[tlartaud]

@sethvargo @akaSStalkALEX

Same issue here on my personal laptop.

On my professional computer which is really faster, I dont get the error. The project is the same, and all versions tools are the same, execpt I run Windows 10 on this one vs windows 7 on my personal laptop.

I think that the answer for this is in the question.
Vagrant up and my personal laptop looks reaaaaaaally slow compared to my professional computer. I think there are some timeouts set when vagrant attempt to connect via ssh to the VM, but the VM doesnt get fully started yet.

I randomly get the same issue as you, or sometimes this one

==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
Guest-specific operations were attempted on a machine that is not
ready for guest communication. This should not happen and a bug
should be reported.

Upgrading Vagrant config to use 4 CPUs and 2048 Gb RAM (like what I use on my professional computer) doesn't solve the problem, and the process still looks really slow...

Windows 7 Home x64
VirtualBox 5.0.12
Vagrant 1.8.1
Ruby 1.9.3
Box puphpet/ubuntu-x64

Just ask if you want some more logs.

[tlartaud]

Wow, so strange ...

As a windows user, I'm using Pageant as ssh-agent with my key loaded into it. I've try to close it, then I re-opened a new terminal and I loaded my key manually using

eval `ssh-agent -s`
ssh-add

And it worked, Vagrant Up successfull .... Wuuuuut ? oO
(sorry if my problem is finally not completely related to this issue)

Additional note : I use Git for windows linked to plink.exe during installation.

@akaSStalkALEX By chance, are you running Vagrant on Windows ?

[StalkAlex]

@tlartaud I'm using Vagrant on Win 10 and ssh agent from Git's latest version. PC configuration has nothing to do with current problem. Error came out after updating Vagrant from 1.7.4 to 1.8.0 on the same PC. I was a bit wrong at the beginning doing my assumptions. Here's some lines from my up log.

DEBUG ssh: == Net-SSH connection debug-level log END ==
 INFO ssh: Execute: cat /etc/issue | grep 'Debian' (sudo=false)
DEBUG ssh: Sending SSH keep-alive...
DEBUG ssh: Exit status: 1
DEBUG guest: Trying: funtoo
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: grep Funtoo /etc/gentoo-release (sudo=false)
DEBUG ssh: stderr: grep: /etc/gentoo-release: No such file or directory

DEBUG ssh: Exit status: 2
DEBUG guest: Trying: gentoo
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: grep Gentoo /etc/gentoo-release (sudo=false)
DEBUG ssh: stderr: grep: /etc/gentoo-release: No such file or directory

DEBUG ssh: Exit status: 2
DEBUG guest: Trying: nixos
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: test -f /run/current-system/nixos-version (sudo=false)
DEBUG ssh: Exit status: 1
DEBUG guest: Trying: omnios
 INFO ssh: Connection errored, not re-using. Will reconnect.
DEBUG ssh: #<Timeout::Error: execution expired>
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "29161d7b-f392-46c8-9893-166f468dcd65", "--machinereadable"]
 ...
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_5_0:   - [1, "ssh", 2222, 22]
DEBUG virtualbox_5_0:   - [1, "tcp54320", 54320, 5432]
DEBUG virtualbox_5_0:   - [1, "tcp8080", 8080, 80]
INFO ssh: Attempting SSH connection...
...

As I understand Vagrant using ssh-agent makes one connection at the beginning and then for all (or maybe not and I'm mistaken?) commands uses the same connection: DEBUG ssh: Re-using SSH connection. In this case everything is going fast as usual. No errors at all. But sometimes I don't understand what affects this it gives INFO ssh: Connection errored, not re-using. Will reconnect. And Vagrant is reconnecting from scratch, sometimes literally before each command in negotiating loop, for example. This takes a lot of time. Amount of errors is random.

[tlartaud]

yeah, I had the same output and I cannot figure out if this happens randomly or in some specific cases.

But apparently, this is not related to pageant ^^ I think it just randomly fail.

[tlartaud]

@akaSStalkALEX

And Vagrant is reconnecting from scratch, sometimes literally before each command in negotiating loop

Hey, you are giving me an idea !

In your Vagrantfile, try to turn off natdnshostresolver1 ?

config.vm.provider :virtualbox do |v|
    v.customize ['modifyvm', :id, "--natdnshostresolver1", "off"]
end

[gocanto]

I fixed my problem uninstalling the whole vagrant, including it (users/system) files. Here what I did

https://laracasts.com/discuss/channels/laravel/homestead-up-problemas?page=0#reply-130684

hope it can help a little bit

[yoannfleurydev]

Same here. I didn't have this problem on the 1.7.x version of Vagrant, and this issue is happening since I update Vagrant with the latest version 1.8.1.
I'm using Vagrant on Windows 10 and VirtualBox 5.0.12.

Hope it can help, and we'll find a solution soon.

[victorbaraonunes-zz]

Same problem here using vccw. But some times it works '-'.

I'm on OS X 10.11.3 (El Capitan) using Vagrant 1.8.1 and VirtualBox 5.0.14.

debug mode log: https://gist.github.com/victorbaraonunes/3f34ada42f1cd4823a92
Vagrant file: https://github.com/vccw-team/vccw/blob/master/Vagrantfile

[AhmedSamy]

same here
OS X 10.11.3 (El Capitan) using Vagrant 1.8.1 and VirtualBox 5.0.14.

[joshuaadickerson]

I installed vbguest plugin and it seems to have fixed the issue.
vagrant plugin install vagrant-vbguest

[StalkAlex]

@joshuaadickerson "...also I have vbguest plugin..."

[Spea]

Are there any updates on this? I have the same issue

OS: OS X 10.11.3
Vagrant: 1.8.1
Virtualbox: 5.0.14 (tried a downgrade to 5.0.12 too)

[Spea]

Setting natdnshostresolver1 to off solved this issue for me, thx to @tlartaud

[Spea]

I have to revise that. It only temporarily fixes this issue, but when I turn natdnshostresolver1 on again (after provisioning), the same error appears again.

[Spea]

After hours and hours of not be able to fix this issue, I reinstalled OSX and it is working again

[sethvargo]

Hi all,

Thank you for opening an issue. I spent a lot of time with redhat and centos guests and I was unable to reproduce this issue on Vagrant 1.8.3. Is this still occurring?

[sorvis]

I'm seeing this issue:
Vagrant Version: 1.8.5
VirtualBox Version: 5.1.2r108956
Ubuntu Version: Ubuntu 16.04.1 LTS

==> default: Attempting graceful shutdown of VM...
    default: Guest communication could not be established! This is usually because
    default: SSH is not running, the authentication information was changed,
    default: or some other networking issue. Vagrant will force halt, if
    default: capable.
==> default: Forcing shutdown of VM...
==> default: Checking if box 'bento/centos-6.7' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 11521 (guest) => 21521 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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
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.

[toroc]

@sethvargo This is still happening as of today.
Vagrant Version: 1.8.5
VirtualBox Version 5.1.2 r108956
OS: Windows 10

This is my vagrant file:

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.provision "shell", path: "pg_config.sh"
  # config.vm.box = "hashicorp/precise32"
  config.vm.box = "ubuntu/trusty32"
  config.vm.network "forwarded_port", guest: 8000, host: 8000
  config.vm.network "forwarded_port", guest: 8080, host: 8080
  config.vm.network "forwarded_port", guest: 5000, host: 5000
  config.vm.boot_timeout = 2000 

end

[Buri]

Still an issue
Vagrant Version: 1.8.6
VirtualBox Version: 5.0.24_Ubuntu r108355
OS: Ubuntu 16.04 kernel 4.4.0-45-generic

[chrisroberts]

Hi there,

Thanks for reporting this bug. I'm sure this was a real issue when originally reported (our fault for not looking sooner!) but there have been multiple Vagrant releases since the original report. I'm going to close this issue now and request you reopen the issue if you're still experiencing this problem. I'm sorry this wasn't looked at earlier ☹️

Cheers!

[CybMeta]

Still having the issue on Windows 10 and fresh install from today with latest versions of Vagrant 1.9.2 and
VirtualBox 5.1.18.

[StalkAlex]

After all updates I had all the same problems as on the moment I reported this issue. So I just recreated vm, now it works as it should be. I think it somehow connected with yum updates inside vm, I regularly updated my vm and after one of the updates it started working with bugs. But I'm not sure.

[mvolz]

Same issue after upgrading from 1.8.5 to 1.9.3;

vagrant config natdnshostresolver1 off

did not work. I have destroyed the machine and tried recreating it several times. On Ubuntu Trusty (14.04).

vagrant up --debug output:

DEBUG virtualbox_5_1:   - [1, "ssh", 2222, 22, "127.0.0.1"]
DEBUG ssh: Checking key permissions: /home/marielle/.vagrant.d/insecure_private_key
 INFO ssh: Attempting SSH connection...
 INFO ssh: Attempting to connect to SSH...
 INFO ssh:   - Host: 127.0.0.1
 INFO ssh:   - Port: 2222
 INFO ssh:   - Username: vagrant
 INFO ssh:   - Password? false
 INFO ssh:   - Key Path: ["/home/marielle/.vagrant.d/insecure_private_key"]
DEBUG ssh:   - connect_opts: {:auth_methods=>["none", "hostbased", "publickey"], :config=>false, :forward_agent=>false, :send_env=>false, :keys_only=>true, :paranoid=>false, :password=>nil, :port=>2222, :timeout=>15, :user_known_hosts_file=>[], :verbose=>:debug, :logger=>#<Logger:0x00000003072a58 @progname=nil, @level=0, @default_formatter=#<Logger::Formatter:0x00000003072a08 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x000000030729b8 @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<StringIO:0x00000003072aa8>, @mutex=#<Logger::LogDevice::LogDeviceMutex:0x00000003072990 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x00000003072940>>>>, :keys=>["/home/marielle/.vagrant.d/insecure_private_key"]}
DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2017-04-10T18:24:47.510951 #27041] DEBUG -- net.ssh.transport.session[1838690]: establishing connection to 127.0.0.1:2222
D, [2017-04-10T18:24:47.511347 #27041] DEBUG -- net.ssh.transport.session[1838690]: connection established
I, [2017-04-10T18:24:47.511420 #27041]  INFO -- net.ssh.transport.server_version[1837d6c]: negotiating protocol version

DEBUG ssh: == Net-SSH connection debug-level log END ==
ERROR warden: Error occurred: An error occurred in the underlying SSH library that Vagrant uses.
The error message is shown below. In many cases, errors from this
library are caused by ssh-agent issues. Try disabling your SSH
agent or removing some keys and try again.

If the problem persists, please report a bug to the net-ssh project.

Out of ideas for today. It looks like a connection is established but that the error happens during/after negotiating protocol? Any ideas on what that could be?

[pinocchiochang]

So, do you think updating the vm and vagrant version is a good solution ?

[naoisegolden]

Same here with a fresh VCCW install.

UPDATE: uninstalling and installing Vagrant seemed to work.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.