Vagrant up dies after "Setting hostname..."

[vcultharris]

Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Vagrant version

Vagrant 1.9.2

Host operating system

MacOS Sierra (10.12.3)

Guest operating system

RHEL7

Vagrantfile

Vagrant.configure("2") do |config|
config.vm.define "foo1" do |ast|
ast.vm.box = "bash_rh7"
ast.vm.hostname = "foo1.mydomain.edu"
ast.vm.network :private_network, ip: "192.168.56.33"
end
end

Debug output

Provide a link to a GitHub Gist containing the complete debug output:
https://www.vagrantup.com/docs/other/debugging.html. The debug output should
be very long. Do NOT paste the debug output in the issue, just paste the
link to the Gist.
It was too long to put in a single one, so there are several (probably the last two are most relevant):
https://gist.github.com/vcultharris/2ce661ef90b20bea8b0e7cefd20f75b9
https://gist.github.com/vcultharris/01366135beda0e79adfbd8b7f3924e66
https://gist.github.com/vcultharris/fc99a966b38983323bec71428987ef38
https://gist.github.com/vcultharris/79d075a62f611ccd9b3f364ef0cfb55e
https://gist.github.com/vcultharris/f91bbcb77833a32dde69507d0f3c8d5b
https://gist.github.com/vcultharris/0bed0a989365b4b0f9dc7ca6751e2674
https://gist.github.com/vcultharris/c034d6056bc413bfa77c76079d80b19f
https://gist.github.com/vcultharris/9afa15362780698342c73ef89ad6fcbd
https://gist.github.com/vcultharris/43fdda4bb5a9fc67734656fc87679f2b
https://gist.github.com/vcultharris/b01484722324e14223c0505d64a781a8
https://gist.github.com/vcultharris/8a410a967196de9143d7a805a4d1d136
https://gist.github.com/vcultharris/8f707bebfae7b84e117a722bd57689a1
https://gist.github.com/vcultharris/56d531304e92d2d535be82f9a3611786
https://gist.github.com/vcultharris/c0bf986580734ad4fbc33aab2c27cce0

Expected behavior

What should have happened?
No errors

Actual behavior

What actually happened?
It gave this horrible error:

==> foo1: Setting hostname...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

# Update sysconfig
sed -i 's/\(HOSTNAME=\).*/\1ceres.ws.vcu.edu/' /etc/sysconfig/network

# Update DNS
sed -i 's/\(DHCP_HOSTNAME=\).*/\1"ceres"/' /etc/sysconfig/network-scripts/ifcfg-*

# Set the hostname - use hostnamectl if available
echo 'foo1.mydomain.edu' > /etc/hostname
if command -v hostnamectl; then
  hostnamectl set-hostname --static 'foo1.mydomain.edu'
  hostnamectl set-hostname --transient 'foo1.mydomain.edu'
else
  hostname -F /etc/hostname
fi

# Remove comments and blank lines from /etc/hosts
sed -i'' -e 's/#.*$//' -e '/^$/d' /etc/hosts

# Prepend ourselves to /etc/hosts
grep -w 'foo1.mydomain.edu' /etc/hosts || {
  sed -i'' '1i 127.0.0.1\tfoo1.mydomain.edu\tceres' /etc/hosts
}

# Restart network
service network restart


Stdout from the command:

/bin/hostnamectl
Restarting network (via systemctl):  [FAILED]


Stderr from the command:

Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details.

Steps to reproduce

1. vagrant up

References

Are there any other GitHub issues (open or closed) that should be linked here?

Possibly related

• Revert "Fix service network restart on RHEL-7 / Fedora" #8148

[ErichHartmann]

Same. Worked in 1.9.1, now broken. My OS is Windows 10 Pro.

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

# Down the interface before munging the config file. This might
# fail if the interface is not actually set up yet so ignore
# errors.
/sbin/ifdown 'eth1'
# Move new config into place
mv -f '/tmp/vagrant-network-entry-eth1-1488479790-0' '/etc/sysconfig/network-scripts/ifcfg-eth1'
# attempt to force network manager to reload configurations
nmcli c reload || true

# Restart network
service network restart
Stdout from the command:
Restarting network (via systemctl):  [FAILED]
Stderr from the command:
Job for network.service failed because the control process exited with error code.
See "systemctl status network.service" and "journalctl -xe" for details.

Vagrantfile

#!/usr/bin/ruby

# To upgrade/patch Vagrant, re-download and install over current.
# Make sure Vagrant sticks to C:\Program Files (x86)\ and doesn't
# try to weasel itself somewhere else.

# Build a default CentOS 7 box to use as a test for errors
Vagrant.configure("2") do |config|

    # Base box
    config.vm.box = "centos/7"

    # VirtualBox defaults
    config.vm.provider "virtualbox" do |v|
        v.gui = false
        v.memory = "2048"
        v.cpus = "2"
    end

    # Port forwarding
    config.vm.network "forwarded_port", guest: 80, host: 8080 # HTTP
    config.vm.network "forwarded_port", guest: 443, host: 4443 # HTTPS

    # Private network
    config.vm.network "private_network", ip: "192.168.91.1"

    config.vm.provision :shell, path: "bootstrap.sh"

    # Synced folders
    config.vm.synced_folder ".", "/vagrant", disabled: true

end

[mikefaille]

@ErichHartmann By setting 192.168.91.1 as private ip, Virtualbox will use 192.168.91.1 on host to contact this network 192.168.91.0/24. As you can see, you get IP conflict between your VM and your host. Then, as I tried successfully, replace 192.168.91.1 by 192.168.91.2.

@vcultharris Try this Vagrantfile please :

Vagrant.configure("2") do |config|
  config.vm.box = "bash_rh7"
  config.vm.hostname = "foo1.mydomain.edu"
  config.vm.network :private_network, ip: "192.168.56.33"
end

If it don't work, try centos/7 as Vagrant box with my suggested Vagrantfile (it work for me). If you get trouble using bash_rh7 using my suggested Vagrantfile, can you send me your box (or any recipe to build it ?).

Thank you all.

[vcultharris]

After numerous trials and errors, we figured out that before packaging the base box, remove any reference to HWADDR in the ifcfg files. It seems to now work without any errors. I'm closing this issue.

[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.