Shell Provisioner on Windows (WS2K8R2x64) "hangs" during file transfer

[dgdonovan]

Having an issue with the Shell provisioner hanging in the scp command on the box (precise32). The command prompt debug output is:

INFO interface: info: Running provisioner: Vagrant::Provisioners::Shell...
[default] Running provisioner: Vagrant::Provisioners::Shell...
DEBUG ssh: Uploading: C:/Users/ADMINI~1/AppData/Local/Temp/1/vagrant-shell201207
07-6596-661omi to /tmp/vagrant-shell
DEBUG ssh: Re-using SSH connection.

I have confirmed that the files on the Windows side contain the appropriate assignments.

Via PuTTY, I confirmed that /tmp/vagrant-shell file is empty. The "scp -t /tmp/vagrant-shell" process is sleeping. I have tried both:

config.vm.provision :shell, :inline => "echo foo > /vagrant/test"

and

config.vm.provision :shell do |shell|
shell.inline = "echo $1 > /vagrant/test"
shell.args = "'write this to a file'"
end

with the same outcome. Invoking a script from the shared file system via:

config.vm.provision :shell, :path => "test.sh"

does work. Please let me know how to obtain additional debug output.

Vagrant for Windows v1.0.3
VirtualBox for Windows v4.1.18

[update]

Been looking through the closed issues. Could be this case is the same or similar to 924 and/or 968. Am building an environment from scratch using the master branch. Will close if I can confirm the issue is resolved.

[AndersRasmussen]

I have the same problem. Did you come any future?

[dgdonovan]

Still trying to build a Vagrant Windows Installer with the 1.1.0 (master) branch. Not as simple as building Vagrant.

The workaround for now is to add all script lines to a file in the mounted/shared file system, and use the directive:
config.vm.provision :shell, :path => ""
in the Vagrantfile.

A simple example of the script contents would be:

#!/bin/bash
apt-get -y update

Line separators must be *NIX compatible. If the CTRL-M (carriage return) is present, bash will flag it as an invalid character, and the script will fail. If you are going to create the script file from Windows, use something like Notepad++, not Notepad. Either that or "apt-get -y install dos2unix" to install the *NIX package in an instantiated VM. Use this command to strip invalid characters from the script file on the shared file system. For example:

$ dos2unix /vagrant/myscriptfile.sh
or
$ sudo dos2unix /vagrant/myscriptfile.sh

[obscurerichard]

This may be a duplicate issue with #1036

I have an open pull request #1039 that fixes it, and a minimal test case with documentation on the fix here https://github.com/obscurerichard/vagrant-windows-shell-test

[mitchellh]

I think this is fixed by #1182 as well.

[axelson]

Is this fixed in 1.0.5? If not is there an easy way to install a version of vagrant that fixes this issue?

[obscurerichard]

It is not fixed in 1.0.5 but you can manually fix the two files that the
patch addresses and it will work.

Richard Bullington-McGuire
+1 571 236 0938

On Dec 18, 2012, at 8:18 PM, Jason Axelson notifications@github.com wrote:

Is this fixed in 1.0.5? If not is there an easy way to install a version of
vagrant that fixes this issue?

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1007#issuecomment-11513525.

[axelson]

Ok, thanks. This is what I'm using to work around two vagrant bugs (FILE2 is for this bug).

FILE=/c/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/ssh.rb
FILE2=/c/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/communication/ssh.rb

sed -i '/^\s+if Util::Platform.windows/ {
a
which = Util::Platform.windows? ? "where ssh >NUL 2>&1" : "which ssh >/dev/null 2>&1"
raise Errors::SSHUnavailable if !Kernel.system(which)
d
}' $FILE
sed -i '/raise Errors::SSHUnavailableWindows/,/raise Errors::SSHUnavailable if !Kernel.system/d' $FILE
sed -i '/^\s+scp.upload!(from, to)/ {
a
# Open file read only to fix issue [GH-1036]
scp.upload!(File.open(from, "r"), to)
d
}' $FILE2

Also here's a direct link to the commit that fixes this bug: obscurerichard@cced762

[mitchellh]

I'll be releasing 1.0.6 shortly, which will include the fix.