New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VM sometimes hangs in Grub (timeout -1) and waits forever #1792

Closed
acesuares opened this Issue Jun 3, 2013 · 8 comments

Comments

Projects
None yet
8 participants
@acesuares

acesuares commented Jun 3, 2013

There are many threads regarding 'vagrant up hangs at "Waiting for VM to boot. This can take a few minutes".

However, I discovered that my problem had nothing to do with networking.
For some reason, the VM waited forever in GRUB. See screen shot.

foo4

How to make a screen shot: https://github.com/gavD explains: #1066 (comment)

https://github.com/smoya explained how to fix tge grub-hanging problem it: #391 (comment)

So, would it be prudent to change the -1 timeout in grub to 10 in all packaged boxes?

Thanks a million to both gavD and smoya, or I would never have found the problem and being able to fix it!

@xiaohanyu

This comment has been minimized.

Show comment
Hide comment
@xiaohanyu

xiaohanyu Jun 4, 2013

Maybe this is problems of grub settings.

I've encounter this problem with ubuntu precise 64, grub2, and only delete one line in the default grub settings will solve the problem, But I forgot the details, maybe you can google it, or I'll ask my friends for details.

xiaohanyu commented Jun 4, 2013

Maybe this is problems of grub settings.

I've encounter this problem with ubuntu precise 64, grub2, and only delete one line in the default grub settings will solve the problem, But I forgot the details, maybe you can google it, or I'll ask my friends for details.

@acesuares

This comment has been minimized.

Show comment
Hide comment
@acesuares

acesuares Jun 4, 2013

The problem already solved in issue #391

acesuares commented Jun 4, 2013

The problem already solved in issue #391

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jun 9, 2013

Member

I'm unsure of a good way for Vagrant to detect this at the moment. I recommend fixing boxes (I realize its my own box, I need to fix), so that grub doesn't wait forever or grub doesn't show a menu ever.

Sorry about that!

Member

mitchellh commented Jun 9, 2013

I'm unsure of a good way for Vagrant to detect this at the moment. I recommend fixing boxes (I realize its my own box, I need to fix), so that grub doesn't wait forever or grub doesn't show a menu ever.

Sorry about that!

@chetan

This comment has been minimized.

Show comment
Hide comment
@chetan

chetan Aug 17, 2013

When packaging a box, before shutting down the running vm (if it is running) you could grep /boot/grub/grub.cfg for the timeout values and see if it is -1. If it is, perhaps prompt the user to fix it or just go ahead and fix it automatically.

If the vm is not running, then perhaps throw a warning asking if you want to boot & check the value?

chetan commented Aug 17, 2013

When packaging a box, before shutting down the running vm (if it is running) you could grep /boot/grub/grub.cfg for the timeout values and see if it is -1. If it is, perhaps prompt the user to fix it or just go ahead and fix it automatically.

If the vm is not running, then perhaps throw a warning asking if you want to boot & check the value?

@flaccid

This comment has been minimized.

Show comment
Hide comment
@flaccid

flaccid Oct 4, 2013

For the record, I ran into this too and because running headless I used to just think that the vm state had gone whack so would destroy it which is not good when you are working with something not backed up. I noticed it by looking at the preview in VirtualBox frontend.

@mitchellh will there be some kind of fix in the precise64.box soon for grub so -1 is not used?
Something like #391 (comment) I guess.

flaccid commented Oct 4, 2013

For the record, I ran into this too and because running headless I used to just think that the vm state had gone whack so would destroy it which is not good when you are working with something not backed up. I noticed it by looking at the preview in VirtualBox frontend.

@mitchellh will there be some kind of fix in the precise64.box soon for grub so -1 is not used?
Something like #391 (comment) I guess.

sguclu added a commit to alm-finaxys/spring-petclinic that referenced this issue Feb 4, 2014

@volkanunsal

This comment has been minimized.

Show comment
Hide comment
@volkanunsal

volkanunsal Jun 14, 2014

I am running into this issue too. It happens only when this line is in the Vagrantfile:

config.vm.network :forwarded_port, guest: 3000, host: 3000

volkanunsal commented Jun 14, 2014

I am running into this issue too. It happens only when this line is in the Vagrantfile:

config.vm.network :forwarded_port, guest: 3000, host: 3000
@insprintorob

This comment has been minimized.

Show comment
Hide comment
@insprintorob

insprintorob Aug 12, 2015

I followed the advice here: http://serverfault.com/questions/243343/headless-ubuntu-server-machine-sometimes-stuck-at-grub-menu and it worked. This has happened to several previous vms, sometimes the boot record is overwritten by a software update.

insprintorob commented Aug 12, 2015

I followed the advice here: http://serverfault.com/questions/243343/headless-ubuntu-server-machine-sometimes-stuck-at-grub-menu and it worked. This has happened to several previous vms, sometimes the boot record is overwritten by a software update.

@jay

This comment has been minimized.

Show comment
Hide comment
@jay

jay Jan 5, 2016

I followed the advice here: http://serverfault.com/questions/243343/headless-ubuntu-server-machine-sometimes-stuck-at-grub-menu and it worked. This has happened to several previous vms, sometimes the boot record is overwritten by a software update.

Thanks for this. I had data-science-toolbox/dst hang a few times when I brought it up because I didn't do a graceful shutdown prior. I used to start it in the GUI to fix it as a workaround. Since then I've followed the accepted answer in the link you provided and set GRUB_RECORDFAIL_TIMEOUT to a short timeout and I haven't had a hang since. While this may not strictly be vagrant's problem I think on a headless boot via up one would expect it not to hang at grub. Perhaps @mitchellh you could consider making this change for the boxes hosted by HashiCorp at least? Otherwise there will be situations where grub just hangs forever, waiting. Thanks

jay commented Jan 5, 2016

I followed the advice here: http://serverfault.com/questions/243343/headless-ubuntu-server-machine-sometimes-stuck-at-grub-menu and it worked. This has happened to several previous vms, sometimes the boot record is overwritten by a software update.

Thanks for this. I had data-science-toolbox/dst hang a few times when I brought it up because I didn't do a graceful shutdown prior. I used to start it in the GUI to fix it as a workaround. Since then I've followed the accepted answer in the link you provided and set GRUB_RECORDFAIL_TIMEOUT to a short timeout and I haven't had a hang since. While this may not strictly be vagrant's problem I think on a headless boot via up one would expect it not to hang at grub. Perhaps @mitchellh you could consider making this change for the boxes hosted by HashiCorp at least? Otherwise there will be situations where grub just hangs forever, waiting. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment