When I run vagrant up it goes ok, but after Booting VM... step it stops with error:
==> default: Waiting for machine to boot. This may take a few minutes...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.
I can run my image manually with VirtualBox GUI, it loads ok and shows me login:.
Is there any way to find what is wrong and how to fix it?
Here are more details:
CPU w/o virtualization
Vagrant 1.7.4
VirtualBox 5.0.8r103449
ruby 2.1.5p273 (2014-11-13 revision 48405) [i386-mingw32]
OS Name: Microsoft Windows 8.1 Pro
OS Version: 6.3.9600 N/A Build 9600
System Type: x64-based PC
Try running vagrant up --debug to help you debug.
For vagrant to boot up your virtual machine, it will have to ssh into it. If it cannot, it won't be able to carry out the command. This only happen when you create a complete new box. In case, it works in the past (meaning you already "vagrant up" before), and decides to be a jerk this time, then you may have to check the content of vagrantfile to see any misconfig.
Related
For many months I had been successfully using VirtualBox 5.xx.xx along with Vagrant 2.xx (don't remember the rest of the version numbers) on a Windows 10 host with Ubuntu 16 guest. At some point in the past six weeks, on vagrant up Guest Additions started being reported as different versions on the host and guest, and changes I would make to my synced files from the Windows side would not always be realized on Ubuntu. To try to fix this problem, I upgraded Vagrant to the latest version, and then tried upgrading and downgrading VirtualBox from as low as 5.0.18 (generates an error on vagrant up) to as high as the latest (6.0.4). Trying 5.2.24 and 5.2.26 yielded messages upon Vagrant startup stating that Guest Additions on the host were reported as 5.0.18 but on the guest were reported as 5.2.24 (or .26). Then a final startup message stated that the Virtualbox version was at 5.2 and the Guest Additions version was 5.1.30 - so at times I've gotten a total of three different versions of Guest Additions reported. I have the vagrant-vbguest plugin installed. I downloaded the matching Guest Additions ISO version for the VBox versions, and loaded the Guest Additions ISO into the virtual optical drive in VirtualBox (as well as specified config.vbguest.iso_path = "VBoxGuestAdditions_5.x.x.iso" in my Vagrantfile.
My Vagrant/VirtualBox setup had been working fine for probably at last a year, and I never wanted to "upgrade" because I've been through this mess before when "upgrading" to newer versions. From too-long searching online, I'm pretty sure this problem has been caused from doing dist-upgrade to Ubuntu (which I do regularly) because I've changed nothing in the Vagrant/VBox setup for a long time. I was hoping that the upgrade to the latest VirtualBox (6) would solve the problem but, sadly, this version is even worse - Ubuntu cranks SLOWLY through the boot process, and it's been taking so long that I haven't even let it finish after trying several times.
It would be great to see if this latest VirtualBox 6 would solve the problem, so maybe someone has an idea about why that would be so slow (I have an 8 core 16Gb machine, and I've assigned 4 cores and plenty of RAM to VBox - and it starts up fine under 5.2.xx).
The vagrant up output:
SSH username: vagrant
SSH auth method: private key
Warning: Connection reset. Retrying...
default: Machine booted and ready! Got different reports about
installed GuestAdditions version: Virtualbox on your host claims:
5.0.18 VBoxService inside the vm claims: 5.2.26 Going on, assuming VBoxService is correct...
GuestAdditions seems to be installed (5.2.26) correctly, but not
running. Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.0.18 VBoxService inside the vm
claims: 5.2.26
Going on, assuming VBoxService is correct...
Job for vboxadd-service.service failed because the control process
exited with error code. See "systemctl status vboxadd-service.service"
and "journalctl -xe" for details.
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 5.0.18 VBoxService inside the vm
claims: 5.2.26 Going on, assuming VBoxService is correct... bash: line
4: setup: command not found
Checking for guest additions in VM...
The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
prevent things such as shared folders from working properly. If you
see shared folder errors, please make sure the guest additions within
the virtual machine match the version of VirtualBox you have installed
on your host and reload your VM.
Guest Additions Version: 5.1.30
VirtualBox Version: 5.2 The following SSH command responded with a
non-zero exit status. Vagrant assumes that this means the command
failed!
After many hours of searching and trying different suggestions, the following is what solved the problem:
downloaded the latest unofficial release build of VirtualBox (in my case 5.2.27) and installed it
Placed the following in my Vagrantfile: config.vbguest.iso_path = "https://www.virtualbox.org/download/testcase/VBoxGuestAdditions_5.2.27-129578.iso"
Ran vagrant up
Ubuntu booted OK, but on the host side Vagrant was displaying an error message something like this:
Failed to mount folders in Linux guest. This is usually because the
"vboxsf" file system is not available.
So next, on the booted Ubuntu guest:
sudo apt autoremove to clean up the Linux headers
And then:
Run vagrant vbguest from the host
vbguest then went through a process of uninstalling the existing Guest Additions and installing VBoxGuestAdditions_5.2.27 from the config.vbguest.iso_path.
To verify that Guest Additions are installed properly, run vagrant vbguest --status (or just vagrant vbguest again). Both commands returned:
[default] GuestAdditions 5.2.27 running --- OK.
The above operations resulted in a folder named VBoxGuestAdditions-5.2.27 being placed within the /opt folder. This VBoxGuestAdditions-5.2.27 folder has seven subfolders, two files (uninstall.sh and routines.sh) and a LICENSE file. I can find no documentation about vagrant-vbguest placing the installed items into the /opt folder, but I did find a small mention here.
I suspect that this process would have worked for any of the 5.2.xx versions (available here), but I had already installed 5.2.27 so went ahead with that.
I had he same issue after updating laravel/homestead box to v7.2.1 . This blog post helped me solve it.
in summary, this is what you have to do:
navigate to the directory that contains your Vagrantfile and run vagrant plugin install vagrant-vbguest
The first time I executed the command, it disabled my WiFi adapter and the installation failed. If this happens, re-activate it back and rerun the command.
when it is done installing, run vagrant up to boot the VM. It will update the Guest Additions
I have scoured the internet up and down for this issue and always consider asking here a last resort. That being said if this has been asked and solved before please point me in the right direction.
I am using Virtualbox 5.1.22 on macOS Sierra 10.12.5 with vagrant version 1.9.6
Yesterday I upgraded my homestead box from version 2.0.0 to 2.1.0. I only upgraded after running vagrant up and it did its thing and was fine until I come in today and turn my machine one and try booting up the vagrant machine again. I get the following error at the end of the normal stuff:
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o uid=900,gid=900 vagrant /vagrant
The error output from the command was:
/sbin/mount.vboxsf: mounting failed with the error: No such device
I have tried vagrant reload, vagrant halt and then vagrant up, restarting the machine and re-running, vagrant reload --provision
Any help is greatly appreciated.
Thanks.
EDIT: Why the downvote? This seems like a perfectly reasonable question?
The box comes with VirtualBox Guest Addition for a given version of VirtualBox, which is not the one you're running on your host.
what you need to do is update the Guest Additions in your guest VM to the same version of VirtualBox that you run on your host machine.
The easy way as mentioned in my comments is to use the vagrant vbguest plugin, it will compare the version from your host and guest software and will automatically aligned if needed. I find it pretty convenient and there are options to disable the update if you need.
In case you do not want to run an additional plugin, you can make the update on the guest VM manually.
You will need to download the Guest Addition for the same version of your VirtualBox (5.1.22 in your case) and follow the instructions to install
So I found and installed this: https://github.com/dotless-de/vagrant-vbguest
I have no idea why I need a plugin now when it was working just fine before updating but hey...it works.
I was happily using Vagrant with VirtualBox for my laravel projects (Homestead) but after the Creators Update for Windows 10, VirtualBox stopped working - vagrant up was not throwing any errors and I was even able to vagrant ssh successfully but my web projects were unreachable from the browser.
Initially I was using VirtualBox v.5.1.14 but decided to update to the latest (which is v.5.1.22) - no luck whatsoever, so after reading the answers from this thread I've downgraded to v.5.0.38
Now when I try to vagrant up this error is shown:
vagrant up
Bringing machine 'homestead-7' up with 'virtualbox' provider...
==> homestead-7: Checking if box 'laravel/homestead' is up to date...
==> homestead-7: Resuming suspended VM...
==> homestead-7: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["startvm", "e5ac5ef8-07fa-412f-b59c-bfd745db047e", "--type", "headless"]
Stderr: VBoxManage.exe: error: Failed to load unit 'cpum' (VERR_INVALID_FLAGS)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole
p.s. I've already set Host-Only Network Adapter through preferences in VirtualBox
What I did to resolve the issue was to "plug off" my virtual machine's state using discard, hoping not to lose any information... Now I'm on VirtualBox v.5.1.14 and will stick with it until all things work.
I had to update to Virtualbox Version 5.2 to get my boxes running again.
and also need to reinstall git for windows 2.15.1.2-64 bit and select the option "use windows default console" (cmd.exe) instead of "MinTTY"
With MinTTY the command :
vagrant ssh
will not show the bash command line.
using windows default Console worked.
see more possibe workarounds to this piont also in this git issue
My Working env:
- Windows 10 - 1709 - Build 16299.125
- vagrant 2.0.1
- virtualbox 5.2.0
- git for windows 2.15.1.2. 64 bit
Turning off Hyper-V solved my problem.
Solution:
Control Panel -> Turn Windows Feature on or Off -> Uncheck Hyper-V
I had the same problem. My vagrant up stopped working after the Windows Fall Creators Update (1709). It worked after I turned off Hyper-V.
Current Working Environment:
- Windows 10 (1709)
- Vagrant 1.9.7
- VirtualBox 5.1.32
Problem
I am attempting to get Laravel Homestead working on my Mac Book Air. I have followed the instruction from http://laravel.com/docs/4.2/homestead but when I vagrant up I get stopped on: default: Warning: Connection timeout. Retrying... After I vagrant up fails because of connection timeout i can not vagrant provision or vagrant reload. I can however vagrant ssh into the machine and I can ping google from the machine. I can also spin up other vagrant boxes on my machine with no problem...
Information:
OS: OSX 10.10 (Yosemite)
Vagrant: 1.6.5
Virtual Box: 4.3.16
I have searched around on the internet and found a few “solutions” that has not worked for me:
Turn on “Hardware Virtualisation”. This is automatically turned on in ant instal based mac computer.
Start VM with v.gui = true. This start the VM with with the server terminal in view. Nothing is throwing any errors. and this did not solve the problem
More Debugging Steps:
Tried just booting up the vagrant box laravel/homestead by running vagrant init laravel/homestead then vagrant up. This still gives the same problem.
I have tried vagrant box laravel/homestead versions 0.1.7, 0.1.8 and 0.1.9(newest) All giving the same problem.
Did you let the vagrant output continue after "default: Warning: Connection timeout. Retrying..." Vagrant may actually be retrying the connection. Sounds like you're exiting out when you see that error instead of waiting for vagrant to finish with an actual exit error
A year old post and maybe you have solved it, but I was struggling with it recently and just managed to solve it.
I had the same problem everything was configured correctly but there was no way to ping 192.168.10.10.
In my case it seemed that net-tools package wasn't installed in my distro (Archlinux) by default so installing it allowed me to connect.
See the relevant section at Archlinux Wiki.
Hope that helps someone.
After learning for a couple of days I am happy to have successfully set-up my VM and run the Laravel start page. Very happy there :)
Can someone clarify "when" to use the vagrant functions. My questions:
If I'm planning to turn off my computer should you use halt or suspend? (I am guessing halt) What if I forgot to do any of these two, would it be a problem?
Right after I just turn on my computer should I use up or resume?
What if I am putting my computer to sleep mode by shutting the lid down, is it necessary to vagrant suspend?
In short
1. Shutting down
The "shutdown" methods differ in speed when you turn off/on the VM and in the amount of disk space the VM will take. From faster/more disk consumption to slower/less disk consumption, the comands are: vagrant suspend, vagrant halt and vagrant destroy.
2. Turning on
Just use vagrant up. The difference between the "startup" methods is that vagrant resume will just "wake up" the VM while vagrant up will make some config checks before this. For example, it will check if your vagrant box has a newer version and will notify you that you can update, by running vagrant box update.
Also you can use vagrant resume only on a VM that was previously suspended. Timewise, there is no noticeable difference between the two when used on a suspended machine.
For more details see the documentation references below.
3. Sleep/hibernation
Putting your computer to sleep or even hibernating it should cause no harm. The former is just a low power state while the latter saves the RAM to the storage drives and then restores it when you start your computer. This is OS level stuff, unless sleep failure or other problems occur it shouldn't influence anything.
Referencing the documentation
The Vagrant documentation has a section for what the different commands do:
Suspending the virtual machine by calling vagrant suspend will save the current running state of the machine and stop it. When you're ready to begin working again, just run vagrant up, and it will be resumed from where you left off. The main benefit of this method is that it is super fast, usually taking only 5 to 10 seconds to stop and start your work. The downside is that the virtual machine still eats up your disk space, and requires even more disk space to store all the state of the virtual machine RAM on disk.
Halting the virtual machine by calling vagrant halt will gracefully shut down the guest operating system and power down the guest machine. You can use vagrant up when you're ready to boot it again. The benefit of this method is that it will cleanly shut down your machine, preserving the contents of disk, and allowing it to be cleanly started again. The downside is that it'll take some extra time to start from a cold boot, and the guest machine still consumes disk space.
Destroying the virtual machine by calling vagrant destroy will remove all traces of the guest machine from your system. It'll stop the guest machine, power it down, and remove all of the guest hard disks. Again, when you're ready to work again, just issue a vagrant up. The benefit of this is that no cruft is left on your machine. The disk space and RAM consumed by the guest machine is reclaimed and your host machine is left clean. The downside is that vagrant up to get working again will take some extra time since it has to reimport the
Also regarding vagrant up and vagrant resume:
Command: vagrant up
This command creates and configures guest machines according to your Vagrantfile.
This is the single most important command in Vagrant, since it is how any Vagrant machine is created. Anyone using Vagrant must use this command on a day-to-day basis
Command: vagrant resume
This resumes a Vagrant managed machine that was previously suspended, perhaps with the suspend command.
Or just look at how the output of the two command differ in your terminal:
$ vagrant resume
==> default: Resuming suspended VM...
==> default: Booting VM...
...
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: Resuming suspended VM...
==> default: Booting VM...
...
During vagrant up you can see the the check in acton. If for example there is a newer version of your box, you will get a notification:
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: A newer version of the box 'laravel/homestead' is available! You currently
==> default: have version '0.3.3'. The latest is version '0.5.0'. Run
==> default: `vagrant box update` to update.
==> default: Resuming suspended VM...
==> default: Booting VM...
I usually use halt when I shut down my computer. When you suspend, I believe it stores the current stage image on disk. If you don't care about storage problem then you could use suspend.
If you suspended your VM then you should use resume so that last state is restored. If you just starting the VM, use "up"
I don't think it's necessary to suspend VM whenever when you hibernate your computer.
in short, if you use
$ vagrant suspend
then use
$ vagrant resume
but if you use
$ vagrant halt
then use
$ vagrant up