error after `vagrant halt; vagrant up`

135 views
Skip to first unread message

Arne Wolframm

unread,
Aug 5, 2015, 6:20:29 PM8/5/15
to Vagrant

I am setting up a Ubuntu 15.04 VM on Win7 using Vagrant 1.7.4 and VBox 5.0.0.


On the first vagrant up I can ssh into the machine using vagrant putty and everything is setup correctly and works. When I run vagrant halt, the VM shuts down gracefully without error messages.


However, when I try to restart the VM using vagrant up; vagrant putty, the machine is in a strange state. For example, the default synced folder /vagrant is empty, even though the second vagrant up call prints this message:


default: /vagrant => C:/Users/ArneUser/numecs/dev_env


Also, this vagrant up call prints the following message in PowerShell:


The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

/sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=

Stdout from the command:

Stderr from the command:

stdin: is not a tty
bash: line 2: /sbin/initctl: No such file or directory


I am running a really basic setup just to test for this error, so I don't think the mistake is in my provisioning script. Some pointers in the right direction would be appreciated.

Alvaro Miranda Aguilera

unread,
Aug 5, 2015, 6:23:02 PM8/5/15
to vagra...@googlegroups.com
Are you updating the OS?

If you upgrade the OS and Kernel, this probably is the cause.

You need to recompile the modules, or use a plugin that will do this for you.

If this is the problem, this plugin will help:

https://github.com/dotless-de/vagrant-vbguest

vagrant plugin install vagrant-vbguest
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/36ccd6b5-ff99-441f-bdd2-0d43e0b92b46%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Arne Wolframm

unread,
Aug 5, 2015, 6:30:05 PM8/5/15
to Vagrant
Dear Alvaro,

I am not upgrading the OS. I am using config.vm.box = "ubuntu/vivid64" from Atlas box repository.

Should I still check out the link for vbguest?

Regards,

Arne 

Arne Wolframm

unread,
Aug 5, 2015, 6:41:07 PM8/5/15
to Vagrant
Dear Alvaro,

I ran the vbguest plugin and it did update my guest additions from 4.X.X to 5.X.X.

However, this did not fix the issue.

I still get exactly the same errors as before.

Arne

Alvaro Miranda Aguilera

unread,
Aug 5, 2015, 6:56:06 PM8/5/15
to vagra...@googlegroups.com
On Thu, Aug 6, 2015 at 10:30 AM, Arne Wolframm <arne.w...@gmail.com> wrote:
> "ubuntu/vivid64"

Hello Arne,

I am testing this:

ubuntu/vivid64

$ mkdir vivid64
$ cd vivid64/
$ vagrant init -m ubuntu/vivid64
$ time vagrant up --provider=virtualbox

I do a vagrant reload, and it restart just fine.

I did test on OSX.

Can you share your provisioning script? the best will be take any
secret/password out and use gist (gist.github.com)

Arne Wolframm

unread,
Aug 5, 2015, 7:12:51 PM8/5/15
to Vagrant
Dear Alvaro,

Hmmm, so it runs on OSX...

Please find attached my Vagrantfile and the bootstrap.sh. They are both very basic, so I just attached them here. The .vimrc is also part of the startup.

Vagrantfile calls bootstrap.sh...


Arne

Arne Wolframm

unread,
Aug 5, 2015, 7:32:39 PM8/5/15
to Vagrant
I tried running the same Vagrantfile with Ubuntu 14.04 Trusty (ubuntu/trusty64) and I get the same problem.

Maybe it has to do with VBox 5?

Alvaro Miranda Aguilera

unread,
Aug 5, 2015, 7:42:14 PM8/5/15
to vagra...@googlegroups.com
hello

it's the boostrap script.

It's changing something in the login that breaks vagrant.

couple of suggestions

1. run the script a vagrant, since today is running as root:

config.vm.provision :shell, path: "bootstrap.sh", privileged: false

So what's clonning, is with root privileges


I think this is guilty:

echo "sudo vim +qall" >> /home/vagrant/.profile

Comment that out and test

vagrant destroy
vagrant up
vagrant reload
> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/mitchellh/vagrant/issues
> IRC: #vagrant on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vagrant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vagrant-up+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vagrant-up/a59d4b10-da5d-4b82-bf42-242b616df08e%40googlegroups.com.

Arne Wolframm

unread,
Aug 5, 2015, 9:15:34 PM8/5/15
to Vagrant
I tested it, but it is not the problem. 
Also, I cannot see how it should be a problem, since that script is only writing a line of code into a file.

Arne Wolframm

unread,
Aug 5, 2015, 9:25:28 PM8/5/15
to Vagrant
I am sorry, Alvaro.

That was actually correct. vagrant reload works now.

Still, it is very difficult to understand why changing a .profile file should cause any problems.

dragon788

unread,
Aug 6, 2015, 11:49:53 AM8/6/15
to Vagrant
Arne, since .profile is sourced upon login (and for every 'login' style shell), if you are changing it and it returns ANY error code, it can cause massive failures with the system when trying to login. The primary issues are bashisms or any command or call that exits with a non-zero exit code if you have set -e (i.e. /usr/bin/env bash -exl) can cause major failure. This is why /etc/profile.d/ scripts and .profile scripts should be carefully tested in a VM before deploying to a production system, because some errors can completely prevent login to the system.
Reply all
Reply to author
Forward
0 new messages