vagrant debian guest stuck after setting hostname

[asoki]

Vagrant version

Vagrant 2.0.4 (2.0.3, 2.1.0)
vagrant-vmware-fusion (5.0.4)

Host operating system

macOS 10.13.4 (17E199)
running VMWare Fusion Professional Version 10.1.1 (7520154)

Guest operating system

debian wheezy

Vagrantfile

Vagrant.configure(2) do |config|
  config.vm.define 'foodev' do |foo_config|
    foo_config.vm.box = 'foo'
    foo_config.vm.box_url = 'file:///redacted-path/debian-7.7-64bit.box'
    foo_config.vm.host_name = 'foodev'
    foo_config.vm.network "private_network", ip: "192.168.116.80"
    foo_config.vm.synced_folder "./","/foo-server/foo-code/foo-trunk", id:"foodev-code-sync", type:"nfs", mount_options: ["actimeo=2"]
    foo_config.vm.provision "shell", path: "vagrant_config/foodev_provisioner.sh"
    #foo_config.ssh.insert_key = false
    foo_config.ssh.private_key_path="~/.vagrant_pk/vagrant.foo.redacted.tld_id_rsa"
    foo_config.vm.provider "vmware_fusion" do |v|
      v.vmx['displayname'] = 'foo-Trunk foo (Linux)'
      v.vmx["memsize"] = "8192"
      v.vmx["numvcpus"] = "4"
      v.gui = true
    end
  end
end

Debug output

https://gist.github.com/asoki/c2d95a3fb243a4bb3d6cb149c62758cc#file-vagrant-debug-log

Expected behavior

the machine should boot

Actual behavior

Vagrant get stuck after setting the hostname. (btw, this machine did booted yesterday without any problems and was shut down with vagrant halt)
Inspecting the booted machine reveals, that none of the both network interfaces has an ip.
The last log entry in the syslog is:

May  3 08:55:57 foodev acpid: waiting for events: event logging is off
May  3 08:55:57 foodev dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May  3 08:55:57 foodev dhclient: DHCPOFFER from 192.168.116.254
May  3 08:55:57 foodev dhclient: DHCPACK from 192.168.116.254
May  3 08:55:57 foodev dhclient: bound to 192.168.116.181 -- renewal in 701 seconds.
May  3 08:55:57 foodev kernel: [    7.820405] NET: Registered protocol family 39
May  3 08:55:57 foodev ManagementAgentHost[2912]: Initializing ManagementAgentHost
May  3 08:56:01 foodev dhclient: DHCPRELEASE on eth0 to 192.168.116.254 port 67
May  3 08:56:01 foodev dhclient: DHCPRELEASE on eth1 to 192.168.116.254 port 67
May  3 08:56:01 foodev dhclient: No broadcast interfaces found - exiting.
May  3 08:56:07 foodev kernel: [   17.167601] eth0: no IPv6 routers present
May  3 08:56:07 foodev kernel: [   17.303035] eth1: no IPv6 routers present
May  3 09:07:38 foodev dhclient: DHCPREQUEST on eth0 to 192.168.116.254 port 67
May  3 09:07:38 foodev dhclient: send_packet: Network is unreachable
May  3 09:07:38 foodev dhclient: send_packet: please consult README file regarding broadcast address.
May  3 09:07:42 foodev dhclient: DHCPREQUEST on eth0 to 192.168.116.254 port 67
May  3 09:07:42 foodev dhclient: send_packet: Network is unreachable
May  3 09:07:42 foodev dhclient: send_packet: please consult README file regarding broadcast address.
May  3 09:07:53 foodev dhclient: DHCPREQUEST on eth0 to 192.168.116.254 port 67
May  3 09:07:53 foodev dhclient: send_packet: Network is unreachable
...

cat /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
auto eth1
iface eth1 inet static
      address 192.168.116.80
      netmask 255.255.255.0
#VAGRANT-END

executing the following three commands on the console, while vagrant is stuck and writing:

DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Sending SSH keep-alive...

brings the machine up after 10-30 seconds:

sudo ifdown eth0
sudo ifup eth0
sudo /etc/init.d/ssh restart

(eth0 gets immediately a new ip after ifup)

the debug protocol of the manually fixed run is here:
https://gist.github.com/asoki/ea953f25df939bf2825c6b9dad5012f8#file-vagrant-debug-manually-fixed-log

Steps to reproduce

1. vagrant up foodev

References

• GH-1974

[mauromorales]

I was experiencing the same issue on a freshly installed computer. I downgraded the vagrant version and still had the problem.

I'm using:

• vagrant: 2.0.4
• virtualbox: 5.2.10,122088
• host: macOS 10.13.4 (17E199)
• guest: Ubuntu 12.04

[asoki]

thanks @mauromorales, downgrading to vagrant 2.0.2 solved the problem
i tried:
vagrant 2.1.0, same problem
vagrant 2.0.4, same problem
vagrant 2.0.3, same problem

so, this seems to be a regression

[mauromorales]

Thanks @asoki, as you mention 2.0.2 is working.

[VinceMacBuche]

I have the same issue, also on a debian 8 box, but not at first vagrant up, only at second boot.

It hangs on setting the vm hostname

 ==> dev_agent1: Setting hostname... 

debug log says ([full log](https://gist.github.com/VinceMacBuche/6dcb136534e89ac13e24ba594262758c)):

DEBUG ssh: stderr: 41e57d38-b4f7-4e46-9c38-13873d338b86-vagrant-ssh
DEBUG ssh: Sending SSH keep-alive...

infinitely repeating "DEBUG ssh: Sending SSH keep-alive..." every 5 seconds

To be complete, I tried disabling ssh keep alive in vagrant configuration, but it changed nothing apart that the line is not repeated every 5 seconds (Ok i expected it changed nothing but still worth noting it)

Vagrant config I use are defined here (we use it to setup our dev environment, need to install all dependencies, run "rtf platform setup dev" which configure Vagrant setup for dev, then run vagrant up. first run is ok, but if i reboot or halt the the vm, next vagrant up hangs.

Downgrading to 2.0.2 fixes the issue

My environment:

• Vagrant: 2.1.1
• Virtualbox: 5.2.12 r122591
• Host: Fedora 28
• Guest: Debian 8

[asmagin]

Have the same issue on Windows.

Killing VirtualBox and Vagrant processes fixes the issue.

Get-Process | Where {$_.ProcessName -like "VBox*" -OR $_.ProcessName -like "ruby" } | foreach {Write-Host $_.ProcessName;  $_.Kill()};
vagrant up

My environment:

• Vagrant: 2.1.1
• Virtualbox: 5.2.12 r122591
• Host: Windows 10 Pro
• Guest: Windows 2016 Server

[chrisroberts]

Hi there. I have been trying to reproduce this behavior locally and have so far been unsuccessful. Are you still encountering this issue with the latest release of Vagrant?

Thanks!

[asmagin]

On v2.1.1 quite often. Usually after a restart. Is there any debug info you that might help you?

[mauromorales]

Still happening on:

Vagrant Version: 2.1.2
Guest Additions Version: 4.2.0
VirtualBox Version: 5.2
host: macOS 10.13.4 (17E199)
guest: Ubuntu 12.04

[briancain]

It would be great to know specifically what Vagrant box you are using to get this behavior. I've tried the major Debian boxes on Vagrant Cloud myself and cannot reproduce this behavior:

Vagrant Version: 2.1.1, 2.1.2, 2.1.3.dev
VirtualBox: 5.2.16r123759
Host: macOS 10.13.6
Guests:

• bento/debian-7.8 (virtualbox, 2.2.1)
• bento/debian-8.6 (virtualbox, 2.3.1)
• bento/debian-8.6 (vmware_desktop, 2.3.1)
• bento/ubuntu-16.04 (vmware_desktop, 201807.12.0)
• bento/ubuntu-18.04 (virtualbox, 201806.08.0)
• normation/debian-8-64 (virtualbox, 1.0) _(from this issue thread)_

[asoki]

i can repeat it with:
Vagrant 2.1.2
Host: MacOS 10.13.6 (17G65)
Guest: debian 7.7 (an older private box, i can't give you the box, but i can give you eg. a packagelist with version numbers, or some other details)
VMWare Fusion Professional Version 10.1.2

important to say that the first vagrant up works, it clones and creates the vm and sets the hostname.
then you halt the vm with vagrant halt, it shuts down normal
then the all subsequent vagrant up gets stuck

[sruffell]

I'm hitting this same issue which I believe this is a result of commit 3fa3e995a97d8a which was first released in 2.0.3

I'm guessing the intent of that commit was to allow local DNS to know about the new hostname but the version of Ubuntu I'm using in the guest (14.04.2 LTS) seems to have a bug in dhclient where dhclient -nw just errors out without getting a new IP address.

If I undo the commit above, I do not have this problem.

[luitzifa]

can reproduce with box debian/contrib-jessie64 and vagrant reload

Reverting https://github.com/hashicorp/vagrant/commit/3fa3e995a97d8a2d9705a5b483338009315bfeb0 also fixed it for me.
Thanks @sruffell

[bmorg]

I am having the same problem on an initial vagrant up with a custom built Debian Jessie box.

Reverting 3fa3e99 also fixed it for me.

Thank you @luitzifa! This also fixes the problem for me, although I have not investigated why.

[wazzageek]

I've been encountering this with a Debian 7 / Wheezy instance for quite some time now. I have "solved" the problem by removing isc-dhcp-client and installing dhcpcd5 instead. This removes /sbin/dhclient from the system - vagrant now sees the script is missing and ignores it.

[MartinMystikJonas]

Same problem here.

Vagrant: 2.1.2
provider: vagrant-lxc
Box: https://snowflakehosting.ch/vagrant/lxc-jessie-amd64.box

It seem like script for setting hostname is executed (debug output shows it is executing) but at some point it freezes. Last relevant log message is stderr output of somethink looking like hash. Then only SSH keepalive is logged.

Interesting thing is that hostname is indeed set and if I ssh into running VM and run exactly the same sctipt shown in debug output then it runs just fine.

Reverting to Vagrant 2.0.2 solved the issue.

[jonahbohlmann]

I have the same problem.

Vagrant Version (Working): 2.0.2
Vagrant Version (Not Working): > 2.0.2
Provider: VirtualBox
Host OS: macOS Sierra (10.12.6)
Vagrant-Box: https://vagrantcloud.com/hashicorp/boxes/precise64

[marina-mosti]

Same problem here

Vagrant 2.1.5
Provider: Virtualbox
MacOs Mojave
Box: hashicorp/precise64

Steps to reproduce:
Set up vagrant config
config.vm.box = "hashicorp/precise64"
config.vm.network :forwarded_port, guest: 80, host: 1234
config.vm.hostname = "test.test"

[briancain]

Hi all! Thanks for the feedback. I wanted to update the issue since I've been able to reproduce it thanks to your help.

This is happening with old versions of dhclient as @sruffell mentioned. dhclient -r attempts to reload and renew its DHCP lease which ends up in an error and the guest is left without any networking. This is not the case if you use newer versions of Debian however, but all Debian guests use the same script to update the hostname. I recommend trying to use a newer version until we can figure out the right way to go about renewing its DHCP lease. One way is to restart networking on the guest, however that used to cause issues in the past https://github.com/hashicorp/vagrant/issues/7533

[MartinMystikJonas]

@briancain Thanks for progress on this issue. What version of dhclient would be ok? We are locked to use Debian Jessie at the moment but we can upgrade just dhclient to newer version from Stretch but it would be good to know which version is ok and which is not. Thanks.

[attachmentgenie]

Same problem here

Vagrant 2.1.5
Provider: Virtualbox
Ubuntu 18.04
Box: bento/centos-7.5

[briancain]

@MartinMystikJonas - I was able to successfully get past this with this version of dhclient:

vagrant@test:~$ /sbin/dhclient --version
isc-dhclient-4.3.1

Version 4.1 seemed to be causing the problem on older versions, but I haven't checked if 4.2 solves it or not.

[sruffell]

I just submitted pull request #10298. I believe it'll allow current properly functioning installs to work unchanged, but for versions of DHCP that fail, this provides a workaround that allows the network to come up for my current installations.

[briancain]

Hey all -

I've made a pull request https://github.com/hashicorp/vagrant/pull/10301 which should fix this issue. Instead of using dhclient, it will restart networking services (depending on which tools are available). This is what happens with redhat guests, so it makes sense to include it here for debian. It solves the problem for me on older guests like hashicorp/precise64 Thanks!

[hashibot[bot]]

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.