Vagrant: 1.9.7 no output whatsoever under cygwin/babun

[zartc]

Vagrant version

1.9.7

Host operating system

Windows 10
Babun (http://babun.github.io/)

Guest operating system

N/A

Vagrantfile

N/A

Debug output

N/A

Expected behavior

Vagrant should display its output

Actual behavior

No output whatsoever

Steps to reproduce

1. Open a Babun console
2. type: vagrant --version
   3.

References

N/A

[zartc]

This is really a 1.9.7 bug.
Uninstalled the 1.9.7 and re-installed the 1.9.6 => output back to normal

[rdrpenguin04]

I posted a similar bug a few days ago, #8757. It seems that I have the same problem you do.

[chrisroberts]

@zartc is your babun the latest version?

[syntacticvexation]

I can confirm this also occurs on Win10 with GitBash (MingGW) as per #8757

[zartc]

@chrisroberts
Babun is the latest version available on the official site:

babun --version
babun version 1.2.0
Created and maintained by Tom Bujok (@tombujok)
Copyright (c) 2014-2015.

Cygwin is not the latest version, this is the version that comes whith Babun:

uname -a
CYGWIN_NT-10.0-WOW Jupiter 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin

[svandragt]

This is also happening on Windows 7 with the regular command prompt.

[chrisroberts]

For those experiencing this issue, can you please run the following command, create a gist of the output, and paste the link here:

$ VAGRANT_DEBUG_LAUNCHER=1 vagrant --debug

And if you would provide information on where you are running this command (cmd, powershell, gitbash, cygwin, etc) and version of the environment if it is not builtin to Windows that would be great.

Thanks!

[mr120]

Using Babun 1.2.0 on windows 10 creators edition/update.

_link removed_ please email me at [email protected] for more info. Thanks!

[chrisroberts]

@mr120 Thanks! If you set the VAGRANT_DETECTED_OS environment variable to a dummy value, do you see the same behavior?

$ export VAGRANT_DETECTED_OS=dummy

[chrisroberts]

Confirmed this issue with latest version of babun installed. Underlying issue is that it is distributed as a 32bit version, and the winpty included within the Vagrant package is 64bit only.

[nitrocode]

Besides downgrading to 1.9.6, is there a workaround with 1.9.7?

[mmclin]

I also get empty output from any and all vagrant commands, including "vagrant --version", when using cmd.exe. I'm using Win7 64-bit, with 1.9.7 Vagrant installation.

If I use git bash, then "vagrant --version" works.

Mind boggled as to how 1.9.7 could have been released like this, considering it appears to affect all Windows OS's, or at least the 64-bit flavors.

[tanabarr]

any progress on this? is the only workable solution to downgrade to 1.9.6?

[smare]

I'm also curious about progress - is there a workaround?

[kolbma]

I'd like to run vagrant from cmd.exe

Here is the debug output:
https://gist.github.com/kolbma/d6f6827cdd5988cab246b5c62f2d647e

I've also installed some mingw/cygwin stuff with git and babun.

The vagrant installer always installs in the C:Program Files (x86) directory, although I've changed this to C:Program Files manually !!! It is the 64-bit vagrant installer!

[jrdmcgr]

I'm running into the same issue. I'm trying to set up a dev environment in an Amazon Workspace.

@chrisroberts Here is my debug output: https://gist.github.com/jrdmcgr/f15d4a7707444f9c93d13003a2a31105

Also, this seems to work if I first export VAGRANT_DETECTED_OS=dummy

[sumkincpp]

Relates not only to babun.

In my case, 1.9.7 bundles winpty.exe which comes from MSYS2 and have a dependency for msys-2.0.dll while I have only MSYS installed.

So the fix might be one of the following

1. Fix 1 for installed versions: Get msys-2.0.dll from MSYS2 and put in C:HashiCorpVagrantembeddedbinmsys (worked for me)
2. Fix 2 for installed versions: Get winpty 0.4.2 for MSYS and replace bundled winpty in C:HashiCorpVagrantembeddedbin to one you have downloaded.
3. Fix for vagrant: Decide whenever to use MSYS2 or MSYS and bundle proper dependencies altogether.

[mascarua]

I have the same problem in Windows 10, gitbash 2.3.2 and Vagrant 1.9.7.

When I define export VAGRANT_DETECTED_OS=dummy, then it works fine.

No problems in Powershell or CMD.exe.

[sbennouri]

I had the same issue as @mascarua and did the same fix in babun and it works. Thank you

[Gauss23]

Vagrant 1.9.8 was released. I can't see a bugfix mentioning this issue. Is it resolved? Didn't had the time to install it, yet.

[syntacticvexation]

I've installed it and I haven't had any issues as yet with MINGW64 in Git Bash.

[karlbunch]

Hey @syntacticvexation I used git bash but if you pipe the output to anything it ends up with no output just complains about not a tty.

See #8833 which was closed as a dupe of this but I don't agree. It's a different challenge.

[chrisroberts]

This should be resolved in the 1.9.8 release. If you still experience issues after upgrading, please open a new issue. Thanks!

[mcrocker]

Problem solved, but replaced with another.

I just installed 1.9.8 and I am able to type vagrant --version, vagrant up and vagrant status and get the appropriate results, but vagrant ssh does not login, and messes up the terminal so it does not show characters typed-in until after hitting return and then does not seem to honor carriage returns. Everything just continues on the next line down.

I'll look for a similar issue and report there or create another issue. I'll report back what I end up with.

[piotr-cz]

I'm having same issue in ConEmu and Vagrant 1.9.8.
Workaround set VAGRANT_DETECTED_OS=dummy did help.

[martinandersson]

@mcrocker Did you file an issue? I have the same problem. Upgraded to 1.9.8 but vagrant ssh yields no output.

[interludic]

I just copied C:HashiCorpVagrantembeddedbincygwin64 to C:HashiCorpVagrantembeddedbincygwin

now it seems to work

[martinandersson]

The problem is gone for me since version 2.0.1.

[vshih]

@mrocker, @martinanderssondotcom, ran into the same issue with 2.0.1. This solution worked for me - https://github.com/hashicorp/vagrant/issues/9143#issuecomment-343311263.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.