Homestead: Boot issue on Homestead VM

[luisdiaswiz]

Versions

• Vagrant: 2.2.7
• Provider: Virtualbox 6.0.16 r135674 (Qt5.6.3)
• Homestead: release.

Host operating system

MacOs High Sierra
10.13.6

Homestead.yaml

---
ip: "192.168.10.10"
memory: 4096
cpus: 2
provider: virtualbox

authorize: ~/.ssh/homestead.pub

keys:
    - ~/.ssh/homestead

folders:
    - map: ~/Documents/Repos
      to: /home/vagrant/code

sites:
    - map: roady.local
      to: /home/vagrant/code/roady/www/roady
      php: "5.6"
    - map: pepo.local
      to: /home/vagrant/code/pepo/www/pepo
      php: "5.6"
    - map: bricomarche.local
      to: /home/vagrant/code/bricomarche/www/bricomarche
      php: "5.6"
    - map: museu-do-dinheiro.local
      to: /home/vagrant/code/museu-do-dinheiro/www/museu-do-dinheiro
      php: "5.6"
    - map: edp-live-bands.local
      to: /home/vagrant/code/edp-live-bands/www/edp-live-bands
      type: apache
      php: "7.0"
    - map: boutique-dos-relogios.local
      to: /home/vagrant/code/boutique-dos-relogios/www/boutique-dos-relogios
      php: "7.1"
    - map: museu-do-fado.local
      to: /home/vagrant/code/museu-do-fado/public
      type: apache
    - map: frulact-presentations.local
      to: /home/vagrant/code/frulact-presentations/www/frulact-presentations
      php: "7.1"
    - map: frulact.local
      to: /home/vagrant/code/frulact
    - map: quinta-da-fonte.local
      to: /home/vagrant/code/quinta-da-fonte-wp
    - map: oasrs.local
      to: /home/vagrant/code/oasrs/www/oasrs
      php: "7.1"
    - map: imm.local
      to: /home/vagrant/code/imm
    - map: comte.local
      to: /home/vagrant/code/comte
    - map: sirp.local
      to: /home/vagrant/code/sirp/www/sirp
      php: "7.0"
    - map: sied.local
      to: /home/vagrant/code/sirp/www/sirp
      php: "7.0"
    - map: sis.local
      to: /home/vagrant/code/sirp/www/sirp
      php: "7.0"
    - map: turbotec.local
      to: /home/vagrant/code/turbotec
    - map: etic.local
      to: /home/vagrant/code/etic
    - map: tabernas.local
      to: /home/vagrant/code/tabernas
    - map: arquivo-sonoro.local
      to: /home/vagrant/code/arquivo-sonoro/public
      type: apache
    - map: roteiro-fado.local
      to: /home/vagrant/code/roteiro-do-fado/public
      type: apache
    - map: wiz.local
      to: /home/vagrant/code/wiz_2018_website/public
      type: apache
databases:
    - homestead

features:
    - mariadb: false
    - ohmyzsh: false
    - webdriver: false

backup: true


# ports:
#     - send: 50000
#       to: 5000
#     - send: 7777
#       to: 777
#       protocol: udp

Vagrant destroy & up output

https://gist.github.com/luisdiaswiz/3ad71e6b105600dd171d3b2694bcafa3

Expected behavior

Vagrant up, halt, reload operations should work

Actual behavior

I am using a Homestead vagrant VM and the strangest thing is happening. After working fine for a few months the VM just stopped working. I tried reinstalling everything and setting up again and what happened was that after installing everything and running the VM for the first time with vagrant up everything works fine. It takes some time to provision the VM but it runs for the first time.

The subsequent times after halting the VM for the first time, the VM stops booting, entering emergency mode.
I am attaching a recording of the VM's boot sequence with the errors.
[homestead.webm.zip]
(https://github.com/laravel/homestead/files/4166131/homestead.webm.zip)

I have tried removing the box twice and reinstalling VirtualBox and Vagrant but the same keeps happening.

Can anyone provide some help?

Thanks in advance.

Luis Dias

Steps to reproduce

1. vagrant up or vagrant reload.

[svpernova09]

Vagrant destroy & up output

Provide a link to a GitHub Gist containing the complete output of vagrant destroy && vagrant up.

_complete output_

If I can't see the box destroyed and the full vagrant up log, I can't (and you make it impossibly difficult to) help you.

[luisdiaswiz]

Hello,

I am unable to destroy the Vm since i have the backup option set to true. When the system tries to backup the databases it can't connect to the VM.

Please take a look at the attached video (https://github.com/laravel/homestead/files/4166131/homestead.webm.zip) that shows the VM booting process in it's GUI.

It seems that the problem is there.

[svpernova09]

The video won't help me. If you can't destroy the box, I can't help you because something has happened that Vagrant can't recover from.

Here are my suggestions (These are destructive changes)

Open Virtualbox's GUI:

• Right click on Homestead VM
• Turn off the VM / Shutdown
• Right click on Homestead VM
• Select Remove
• Click "Delete All Files"
• Close Virtualbox

In terminal from your Homestead folder:

• rm -rf .vagrant

Reboot your machine

In terminal from your Homestead folder:

• vagrant global-status --prune

Reboot your machine (yes, again)

In terminal from your Homestead folder:

• vagrant up

[ethanclevenger91]

I've run into the same thing recently, though I'm on Win 10. Same versions of Homestead/Vagrant/VB.

vagrant reload --provision: (let me know if you'd like it with DEBUG info)

moved to gist

Destroy is certainly destructive and I hate to lose the data that I can't take a backup of after ending up in this state, but I can give it a go. I have a sneaking feeling that it'll all end up functional after I do so...

FWIW, it seemed like this started after following the instructions for symbolic links on Windows here. I ultimately removed that line from my Vagrantfile, but it hasn't fixed anything, so maybe not.

[svpernova09]

Destroy is certainly destructive and I hate to lose the data that I can't take a backup of after ending up in this state, but I can give it a go. I have a sneaking feeling that it'll all end up functional after I do so...

If destroying your Vagrant machine causes data loss you're using the tools incorrectly. nothing should go into a VM which isn't automated. This is the entire reason for after.sh.

Vagrant machines aren't designed to be long-running machines. They're meant to be disposable environments you can easily recreate and get to a known state. You're responsible for maintaining that known state after you clone the repo.

Treat your servers like cattle, not pets.

vagrant reload --provision: (let me know if you'd like it with DEBUG info)

moved to gist

The SSH connection failures and the VM not booting properly are not errors Homestead can help with. These issues are due to misconfigurations on your host machine which could be for a variety of different reasons. Homestead can't do anything if the VM isn't being booted by the provider properly.

[ethanclevenger91]

Yeah, I'm specifically talking about databases, which I can get from production envs/seeders depending on the app, it's just not convenient. Believe it or not, there aren't particularly mature seeding options for WP that aren't mired in the core development repository. But anyway...

That's why I offered information with debug, and also the straight output from the box itself on startup. I'm not running any commands directly on the box, so something about the Homestead configuration ultimately would have led to it being in whatever state it's in.

I'm destroying/rebuilding and will let you know if it turns up again. Worth noting that if it does, I won't be able to run vagrant destroy because the box can't start, so you'll never be able to use that output to debug.

[svpernova09]

Yeah, I'm specifically talking about databases, which I can get from production envs/seeders depending on the app, it's just not convenient

You have looked into https://laravel.com/docs/6.x/homestead#database-backups ? Might be helpful.

I'm destroying/rebuilding and will let you know if it turns up again. Worth noting that if it does, I won't be able to run vagrant destroy because the box can't start, so you'll never be able to use that output to debug.

I appreciate it, based on your Gist the issue isn't within Homestead, the problem is with the state the provider (Hyper-V, Virtualbox, VMware, Parallels) and the VM itself. Often a reboot or vagrant destroy can fix this, in more severe issues you'll see as above I instruct people to manually remove the VM.

==> homestead: Checking if box 'laravel/homestead' version '9.2.2-alpha1' is up to date...

You shouldn't be getting this anymore as I've removed that alpha version and tagged a new release since. (Also this wouldn't have caused your issues)

[ethanclevenger91]

Might be helpful

Yep, configured, but can't run if I can't destroy the box via Vagrant. Only set it up in the last couple weeks so don't have old backups to go off. Fortunately that shouldn't be a problem in the future.

removed the alpha

Hm, how do I ensure I'm getting the latest, non-alpha version again? After destroying I still got the alpha. I seem to recall configuring it somewhere but now I don't remember where.

[svpernova09]

Hm, how do I ensure I'm getting the latest, non-alpha version again? After destroying I still got the alpha. I seem to recall configuring it somewhere but now I don't remember where.

You shouldn't have to do anything. When you run vagrant up Vagrant will look at Vagrant Cloud and find the latest version and alert you if you're not running it. It will not automatically download that box for you unless you run vagrant box update.

The trick with Alpha's / Beta's is Vagrant will show you those versions even if they're not available for the provider you're using which is frustrating on my end because I only build pre-release versions for Virtualbox (due the time investment).

The safest way is to keep the Homestead repo/dependency up to date. Where we have backward-incompatible changes I always bump the minimum box version so it's really hard for you to run a version of the repo with an incompatible base box.

[ethanclevenger91]

Just pulled, still getting alpha, no alert about a newer box.

==> homestead: Matching MAC address for NAT networking...
==> homestead: Checking if box 'laravel/homestead' version '9.2.2-alpha1' is up to date...
==> homestead: Setting the name of the VM: homestead
==> homestead: Clearing any previously set network interfaces...
==> homestead: Preparing network interfaces based on configuration...

FWIW, 9.2.2-alpha1 _is_ newer than anything on the Vagrant website.

[svpernova09]

Just pulled, still getting alpha.

Make sure you check out the release branch as sometimes master is broken. (release is always merged from master when I tag a stable release)

FWIW, 9.2.2-alpha1 is newer than anything on the Vagrant website.

Yeah, I typo'ed the version number and Vagrant won't let me live down this disgrace :D

That's so weird because I deleted the version over a week ago: https://app.vagrantup.com/laravel/boxes/homestead (the alpha isn't listed)

oh wait... I missed it earlier, you're RUNNING 9.2.2-alpha1 which means yes you can't update. Ugh sorry.

When you're ready to get off that version run vagrant box remove laravel/homestead --box-version 9.2.2-alpha1 then vagrant box update to ensure you have the real latest/greatest.

[luisdiaswiz]

Hello,

I have followed the suggested steps and, as the other previous times, the first VM boot occurred normally. It just takes some time when installing all the required PHP versions.

I am quite delayed on my work so I'll have to wait until the end of the day to halt and re-up the VM to see if the situation is still occurring.

[luisdiaswiz]

Hello,

After halting the VM on friday, today when starting the vagrant VM with vagrant up, the boot process ran OK and the VM seems to be working fine.

It is strange though how this happened without no apparent cause and even after 2 full reinstall the problem persisted.
Is there any reason as to why this may have happened?

[ethanclevenger91]

Ran into this again, though letting it run long enough, NFS does time out (now realizing I didn't even verify if @luisdiaswiz's error showed up during the NFS process).

mount -o vers=3,udp,actimeo=1,nolock 192.168.7.1:/C/Users/ethan/dev/sterner-stuff-wordpress-core /home/vagrant/dev/sterner-stuff-wordpress-core

Stdout from the command:



Stderr from the command:

mount.nfs: Connection timed out

Removing that directory from Homestead.yaml let me boot up fine the next go around. Nothing particularly odd in the directory, though I was trying to reference it from another project as a path-based composer package at one time, so could be a stray symlink somewhere causing issues.