Destroyed Troubleshooting (markdown)
Seth Vargo
parent
3ed97ae4ad
commit
2b229e3464
|
|
@ -1,91 +0,0 @@
|
|||
As long as the issues regarding this topic are not resolved, I intend to sum up some workarounds working for me.
|
||||
|
||||
## UPDATE: Now found a reproducible workflow:
|
||||
|
||||
- Host: Mac OS X Mountain Lion
|
||||
- Guest: Ubuntu 12.04 Server
|
||||
|
||||
### Reproduce the issue
|
||||
- Power up a machine with one NAT and one Host-Only Network defined
|
||||
- Suspend the host machine (no matter if guest is suspended, haltet or even running)
|
||||
- Power up the host machine in another network environment
|
||||
- Now this issue occurs (vagrant up hangs on waiting for vm to boot ...)
|
||||
|
||||
### Another way to reproduce issue
|
||||
- `config.ssh.private_key_path = "~/.ssh/id_rsa"`
|
||||
|
||||
### Resolve it
|
||||
- Power down the guest.
|
||||
- Depending on the state of the guest, you probably will have to stop it by VBoxManage
|
||||
|
||||
$ VBoxManage controlvm <vmname> poweroff
|
||||
|
||||
- Edit the machine through the VBox gui and disable all network interfaces, but the first (NAT) one
|
||||
- Now start the guest through VBox gui
|
||||
- The boot process will take a long time, because it hangs on "Waiting for network interfaces (...)"
|
||||
- Login to the machine (My default pw/username was vagrant/vagrant)
|
||||
- Remove issued dhcp leases
|
||||
|
||||
$ sudo rm -Rf /var/lib/dhcp/*
|
||||
|
||||
- Halt the machine
|
||||
|
||||
$ sudo halt
|
||||
|
||||
- Reactivate previously disabled network interfaces
|
||||
- Power up the guest by vagrant
|
||||
|
||||
## This is a list of issues related to this topic:
|
||||
|
||||
- [#391](https://github.com/mitchellh/vagrant/issues/391)
|
||||
- [#455](http://github.com/mitchellh/vagrant/issues/455)
|
||||
- [#1064](https://github.com/mitchellh/vagrant/issues/1064)
|
||||
- [#1066](https://github.com/mitchellh/vagrant/issues/1066)
|
||||
|
||||
## Workarounds
|
||||
|
||||
1. Reboot using GUI mode and fix network issues manually
|
||||
|
||||
After rebooting in GUI mode, and issuing
|
||||
|
||||
$ sudo rm -Rf /var/lib/dhcp/*
|
||||
$ sudo /etc/init.d/networking restart
|
||||
|
||||
will SOMETIMES solve the problem.
|
||||
|
||||
|
||||
Some people also proposed to add the above line to /etc/r.local or similar. But in my experience, this will not finally solve the problem.
|
||||
|
||||
Here I found that why this problem appear. It case that you started the Firewall when booting, and SSH can't not connect to the box. So you should disabled the Firewall and try again.
|
||||
|
||||
$ sudo ufw disable
|
||||
|
||||
This will disable ufw from you vagrant machine. Otherwise, you can just allow the port form the Firewall, not disable the Firewall.
|
||||
|
||||
1. Reboot using shell provisioner to fix network issues
|
||||
|
||||
Instead of booting in GUI mode and fix networking issues manually, some people propose to doing this via shell provisioner:
|
||||
|
||||
config.vm.provision :shell, :inline => "/etc/init.d/networking restart"
|
||||
|
||||
I tried this several times, but it failed most often.
|
||||
|
||||
1. Recover VM state using VBoxManage
|
||||
|
||||
When changing the environment (Office, Home Office, Coop) which also means the network, the issue occurs everytime. The solution is to simply poweroff the machine by
|
||||
|
||||
VBoxManage controlvm <vm-id> poweroff
|
||||
|
||||
You can get the VM id by executing
|
||||
|
||||
VBoxManage list runningvms
|
||||
|
||||
and finding the name the VM you want to power down in the resulting list.
|
||||
|
||||
After this the vm can be started again by entering
|
||||
|
||||
vagrant up
|
||||
|
||||
1. Set a publicly accessible DNS server permanently in your Host Machine's Network Settings, such as 8.8.8.8, 8.8.4.4, 4.2.2.2, etc. One variant of this problem seen with CentOS guests is that they would hang while attempting to resolve things in DNS after suspend. That particular problem is caused by a stale resolv.conf having DNS servers from the previous bootup, and will not refresh until DHCP is renewed. By having permanent DNS servers passed down to the Guest OS, it should work regardless of where the Host machine is when restarted.
|
||||
|
||||
1. If you get stuck, press Control + C and try to log in with "vagrant ssh". If you're presented with a password prompt, the creator of the base box did not set up the authorized_keys file properly. Make sure the file contains the insecured key from vagrant repo in github, and check that the file permissions are set correctly (600).
|
||||
Loading…
Reference in New Issue