9

I had a fully functional vagrant for three months now, but for the last three days, I am getting errors whenever I try to run vagrant up or vagrant reload.

This is the error I get when running vagrant reload

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: 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: Adapter 2: hostonly
default: Forwarding ports...
default: 80 => 8080 (adapter 1)
default: 22 => 2222 (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: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying... 
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 am using Elementary OS Luna and updated the latest versions of vagrant as well as virtualbox as some answers suggested. But the problems persist.

I have tried most of the popular solutions including enabling the GUI and this. I also tried the solution given here but could not since my virtual box doesn't login.

However, the GUI presented me with this:

 keys: press S to skip mounting or M for manual recovery

I tried both the keys one by one but the problem still remains.

Has anyone had this before who could offer a solution, vagrant isn't widely covered on the web yet and I cant find a reason why this is occurring.

Community
  • 1
  • 1
ankita
  • 405
  • 1
  • 3
  • 13
  • 2
    Looks like you have a corrupt filesystem in your vm. Did you perhaps shut down your pc while the vagrant machine was still running? Does the GUI show more than the `keys:... ` line? – Sebastian Stigler Jan 29 '15 at 10:56
  • @SebastianStigler: I had a bad habit of directly shutting down my laptop without closing the vm first. Here are the screenshots of the three cases: when I [entered M](http://i.imgur.com/M0evsWb.png), [entered S](http://i.imgur.com/piRPZrE.png) followed by [another S](http://i.imgur.com/HqzUDFP.png) Please let me know if you need any further information. – ankita Jan 29 '15 at 15:17
  • Did you get a console or where you ask for the root password after hitting 'S' each times it is ask for? – Sebastian Stigler Jan 29 '15 at 15:52
  • @SebastianStigler: No, entering M leads to the same screen again, and entering S gets [stuck](http://i.imgur.com/HqzUDFP.png) in `keys: _` – ankita Jan 29 '15 at 16:41
  • You could try to boot in the recovery mode, type the root password (probably `vagrant`). Then run `fsck /dev/sda1` and allow to repair error. If that don't work you will most likely rebuild your vm. – Sebastian Stigler Jan 29 '15 at 16:59
  • @SebastianStigler: Thanks! I fixed the issue. :) I had to rebuild using a `vagrant destroy`. A more detailed answer below. :) – ankita Jan 31 '15 at 06:30
  • 1
    The situation could be because of VirtualBox failed to redirect ports, despite saying '**==> default: Forwarding ports... default: 22 => 2222 (adapter 1)**' You may have a look at full description in my question here [link](http://stackoverflow.com/questions/36529651/virtualbox-nat-failed-to-redirect-tcp-127-0-0-12222-10-0-2-1522). I still have no idea how to fix redirection fail( Please drop a note in my post, if and how you succeed! – WebComer Apr 13 '16 at 17:39

2 Answers2

19

After struggling with all the various options available on different questions, I was still facing the same problem. Finally, I did a 

vagrant destroy

followed by

vagrant up

And I have my system working again.

Note: If you too have the habit to directly switch off your computer, you might face this problem soon! In your vagrant terminal (vagrant ssh), always go for a: 

sudo shutdown -h now

or you can just type

vagrant halt

after you logout from your ssh.

PS: For those of you who might be afraid to lose your data/code/anything during vagrant destroy, you might relax! I was hesitant using the command, but as per the documentation, all it does is:

This command stops the running machine Vagrant is managing and destroys all resources that were created during the machine creation process. After running this command, your computer should be left at a clean state, as if you never created the guest machine in the first place.

This implies that your code will remain intact, and the next vagrant up would lead you to the same state as you left, only with the problem solved now. :)

ankita
  • 405
  • 1
  • 3
  • 13
  • Instead of `sudo shutdown -h now` you can just type `vagrant halt` after you logout from your ssh session. – Sebastian Stigler Jan 31 '15 at 06:38
  • 13
    `vagrant destroy` literally destroys the virtual machine. Therefore you lose any data which is **within** the virtual machine and not on the host machine! – Sebastian Stigler Jan 31 '15 at 06:40
  • @SebastianStigler: I have updated about the halt feature. Regarding the data loss, I meant the code I had written. I am writing an extension for mediawiki and that still remained, IMHO, only the virtual machine's own setup data was destroyed and recreated. Please correct me if I am wrong. – ankita Jan 31 '15 at 10:15
  • 3
    @ankita, I know this is old, but hopefully it'll help someone. I'm not too sure what you meant by your code still remained, but your opinion is very wrong. `vagrant destroy` deleted my entire VM and everything that was on it. Definitely not what I wanted! Ofc, I backed up the vdkm first, but now I'm starting from scratch again. – jferina Sep 13 '19 at 23:47
3

Instead of destroying the image. I was able to fix the issue by first adding the following lines/uncomment inside Vagrantfile to turn the virtualbox gui on. 

config.vm.provider "virtualbox" do |vb|
 vb.gui = true
 vb.memory = "1024"
end

Then I did vagrant up to reboot it. It started both command line and virtualbox gui. Gui asked me for SSH passphrase (which I set up when I was playing with ssh last time I was logged into the machine) and I was able to login. Later I powered off the image. Later I removed above lines for gui from Vagrantfile and it was still booting fine.

Ahmed
  • 83
  • 1
  • 1
  • 5