Vagrant requires TTY

[aspyatkin]

Hello! I would like to report about a weird problem.
I have a virtual machine managed by Vagrant 1.7.4 with Virtualbox 5.0 on Windows 8.1 x64 host. I am trying to destroy it after shutting it down (Cygwin terminal).

› vagrant destroy
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.

I don't get this error while using another Vagrant commands, such as up, package, suspend, halt etc. It reproduces only with destroy.
Previously, I was using Vagrant 1.7.2 with VirtualBox 4.3.x (from 4.3.20 to 4.3.30) on the same host and I didn't run into the problem described.
I have found issue #1616 reporting the same problem, and the workaround suggested worked for me - vagrant destroy --force.
If it helps,

› uname -s
CYGWIN_NT-6.3-WOW

[tcqwerty]

Of note is issue #1430, which makes this look like a regression. I'm running into the same issue, BTW. Vagrant 1.7.4, CYGWIN_NT-6.3-WOW

[rmitchellnet]

Just upgraded to Windows 10, had 1.7.2 and VB 4.3.30, but no network adapters would show. Upgraded to 1.7.4 and VB 5.0.0. and now I get this same error about the TTY when it asks to choose a network adapter after running vagrant up.

I can fix it by just hardcoding the bridge in the Vagrantfile, but yeah, seems to be an issue with 1.7.4.

uname -s : CYGWIN_NT-10.0-WOW

[d13r]

Same here - worked fine in Vagrant 1.7.2, doesn't work as soon as I upgraded to Vagrant 1.7.4 (nothing else changed - Windows 7, VirtualBox 4.3.28, CYGWIN_NT-6.1 2.0.2(0.287/5/3) 2015-05-08 17:00 x86_64).

$ vagrant login
In a moment we will ask for your username and password to HashiCorp's
Atlas. After authenticating, we will store an access token locally on
disk. Your login details will be transmitted over a secure connection, and
are never stored on disk locally.

If you do not have an Atlas account, sign up at
https://atlas.hashicorp.com.
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.

[d13r]

Some further information - looks like the Cygwin platform check is broken:

Vagrant::Util::Platform.cygwin?  # => false
Vagrant::Util::Platform.platform # => "mingw32"
RbConfig::CONFIG["host_os"]      # => "mingw32"

[d13r]

Temporary workaround for anyone with the same problem:

VAGRANT_DETECTED_OS=cygwin vagrant login

Or add this to ~/.bashrc:

export VAGRANT_DETECTED_OS=cygwin

Or a more cross-platform version may be:

export VAGRANT_DETECTED_OS="$(uname)"

[runephilosof]

I don't know if this is related enough, but I get 28 of these errors when running the unit test suite on master (8045869).

For instance the last of the errors show this.

  28) Vagrant::Environment ui should be a silent UI by default
     Failure/Error: expect(described_class.new.ui).to be_kind_of(Vagrant::UI::Silent)
     Vagrant::Errors::UIExpectsTTY:
       Vagrant is attempting to interface with the UI in a way that requires
       a TTY. Most actions in Vagrant that require a TTY have configuration
       switches to disable this requirement. Please do that or run Vagrant
       with TTY.
     # ./lib/vagrant/ui.rb:86:in `ask'
     # ./lib/vagrant/environment.rb:861:in `upgrade_home_path_v1_1'
     # ./lib/vagrant/environment.rb:755:in `setup_home_path'
     # ./lib/vagrant/environment.rb:128:in `initialize'
     # ./test/unit/vagrant/environment_test.rb:1169:in `new'
     # ./test/unit/vagrant/environment_test.rb:1169:in `block (3 levels) in <top (required)>'

I am running on Ubuntu 14.04.2 using rbenv with ruby 2.1.6.

[a-p-o]

I am getting the same message by running vagrant box add <box>.

I can run vagrant version (1.7.4).

Here are my debug logs for vagrant box add laravel/homestead.

When I use @davejamesmiller's fix, I am able to answer the provider question. I get a 500 error afterwards (perhaps unrelated?) from vagrant box add laravel/homestead with that "fix".

[dmarcbriers]

I am getting the same error using CYGWIN_NT-6.3. I am using a fresh install of Vagrant 1.7.4, and I am following the tutorial on vagrantup.com. vagrant destroy --force does the trick though.

[Vas-ko]

I had the same issue running "git bash" trying to pull homestead on windows 10, I then tried it on windows command prompt and it works.

I'm running windows 10 fresh install, I kept getting this error using "git bash" program:
"Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY."

Hope that helps

[turb]

I had vagrant on Windows 10 with git-MinGW (1.9), everything working fine. After git-MinGW was updated to the brand new 2.5.0, the same problem appeared - the VAGRANT_DETECTED_OS workaround does work.

uname: MINGW64_NT-10.0

[badcom]

export VAGRANT_DETECTED_OS=cygwin solved the problem on Windows 10 Vagrant 2.7.4. I added that manually to the environment variables.

[CMCDragonkai]

export VAGRANT_DETECTED_OS=cygwin worked great.

[kirtixs]

export VAGRANT_DETECTED_OS=cygwin doesn't fix the problem completely.
When mounting a smb shared folder and vagrant asks for the password, the password isn't hidden as it should be.

[Swader]

+1, getting this also on Win 10, 1.7.4 vagrant, 5.0.2 VirtualBox. Manual export helped, thanks @davejamesmiller

[davinderpalrehal]

I managed to get it working by adding the --provider virtualbox option at the end of the command and all worked.

[CynanX]

I'm getting this on Windows 7 (version 6.1.7601), with Git 2.5.2.windows.2, VirtualBox 4.3.12-93733 and Vagrant 1.7.4.

uname MINGW64_NT-6.1

[BryanDollery]

Same problem with git shell on windows 10 64-bit, with vagrant 1.7.4. The cygwin fix works even though I'm not using cygwin.

[ghost]

@davinderpalrehal It worked for me. Thank you!

[drbrounsuga]

@davinderpalrehal adding --provider virtualbox worked for me as well. Thanks

[maoueh]

The --provider virtualbox works because it does not ask for the provider anymore and simply use virtualbox. That may not be desired in every case. You could also workaround the problem for vagrant destroy by doing vagrant destroy -f which force the destroy and hence, does not ask for user confirmation (which requires a TTY).

The correct workaround until broken auto-detection is solved is to define environment variable export VAGRANT_DETECTED_OS=cygwin which force Vagrant to detect platform as cygwin which will enable correct coloring as well a seeing you terminal as having TTY capabilities.

@sethvargo Where is generated the bin/vagrant.exe file exactly? I would like to investigate this issue and suspect a problem with the executable. Indeed, auto-detect code is using RbConfig::CONFIG["host_os"] which when called from Vagrant embedded Ruby should always return mingw32. Hence, if it ever worked, is probably because vagrant.exe does some magic (unless my previous assumption is wrong).

Another question I have is that bin/vagrant shebang is #!/usr/bin/env ruby. From the vagrant.exe (which I guess call ruby bin/vagrant script), does shebang always resolve to /path/to/vagrant/embedded/bin/ruby or it takes user environment in consideration? If the latter is true, it might explain things.

P.S.

For those interested in the details. Vagrant tries to determine if current standard input is connected to a console (@stdin.tty?). In Cygwin, which uses mintty by default, this always return false because mintty is a pseudo-console acting more like a file and hence, programs sees it as such and assume it's not a console (no tty). This is also true for those who use MSYS2 (a cygwin fork) which also uses mintty as the default console. Moreover, color enabling is also conditional to being on Cygwin on windows (and some other conditions).

Using ConEmu or plain old cmd.exe solves the auto-detection problem

[jpvilla30]

@davinderpalrehal WOW, just when i had given up hope. Thank you!!!!

[dcrystalj]

@redshark1802 thanks, it worked for me using hyper-v

[russellvt]

Hard-setting VAGRANT_DETECTED_OS=cygwin works just fine for me.

[XedinUnknown]

+1 for VAGRANT_DETECTED_OS

[Junya]

+1
thank you!!

[the-noob]

+1

~/.bashrc
export VAGRANT_DETECTED_OS=cygwin

(vagrant destroy)

[mitchellh]

Fixed

[iscjiha]

Dont work for me!!

[kirtixs]

@iscjiha is this the same issue I described here: #6026 (comment)

[markushausammann]

Doesn't seem fixed to me. Problem still appears with latest Vagrant on Windows 10 with git bash.

[maoueh]

@markushausammann Are you using Git for Windows 2.x? Did you installed with the default mintty console? If yes, the reason is that only Cygwin is auto-detected and not MSYS2 (a Cygwin fork used as the base system in Git for Windows 2.x). You have two workaround:

• Install Git for Windows using the cmd console (which advertise itself as supporting tty, where mintty is not)
• Using the export VAGRANT_DETECTED_OS=cygwin trick (I use it).

[markushausammann]

Yeah, the export trick works for me too but it should work without the trick, shouldn't it?

[maoueh]

Sure!

The point I wanted to convey is that the bug is really fixed (for Cygwin users). For MSYS2 users (via MSYS2 or Git for Windows 2.x), it was not working before the fix, so it should probably be another different ticket (and fix).

[Illydth]

I MIGHT disagree here that this is fixed.

Just installed Virtual Box (5.0.10) and Vagrant (1.7.4)

Working through Cygwin (uname - a reports "CYGWIN_NT-6.1" This could be an exceptionally old instance of Cygwin that is causing the issue, but I'm getting the same problem (destroy prompting for TTY) and I'm NOT using MSYS2 / GIT's installation of Cygwin...this is full fledged Cygwin 64 bit and it's throwing the error.

Yes, the export command above does fix the problem...but unless it's the old version of Cygwin that's throwing things, I disagree that this is fixed in the most recent version.

[maoueh]

@Illydth Indeed, if it's still not working under Cygwin directly, we could say it is not fixed. However, note that the fix will probably be part of next release of Vagrant and that Vagrant 1.7.4 that you are running currently does not contain the fix. Hence why you are seeing the problem currently.

Test and report once the new version is out.

Regards,
Matt

[darkn3rd]

Verified still broken with MSYS on Win10 w/ Vagrant 1.7.4 on VirtualBox 5.0.10. Thus have to do vagrant destroy -f as mentioned above to workaround.

Is there an active bug for this, or this issue not going to get fixed?

$ vagrant destroy
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
$ uname -s
MINGW64_NT-10.0
$ vagrant --version
Vagrant 1.7.4
$ '/c/Program Files/Oracle/VirtualBox/VBoxManage.exe' --version
5.0.10r104061
$ cmd /c ver
Microsoft Windows [Version 10.0.10240]
(c) 2015 Microsoft Corporation. All rights reserved.

I tried it from CygWin (CYGWIN_NT-10.0) and it also has the same issue, where vagrant destroy doesn't work. Thus if this was fixed before, it's broken. Naturally it works in either PowerShell or Command Shell cmd.exe.

[maoueh]

@darkn3rd From my understanding, fix is not released yet. Please try again when next version of Vagrant is released (I guess next version will be 1.8.0).

[oliver-dungey]

A slight variation on the workaround - you can add this to the top of your Vagrantfile:

ENV['VAGRANT_DETECTED_OS'] = 'cygwin'

or slightly more sophisticated:

require 'rbconfig'
include RbConfig
if RbConfig::CONFIG['arch'] == 'i386-mingw32' then
    ENV['VAGRANT_DETECTED_OS'] = 'cygwin'
    puts 'Cygwin terminal detected'
else
    puts 'Windows or Linux terminal detected'
end

[jlahijani]

If you are using Babun (instead of plain cygwin), then you must add:

export VAGRANT_DETECTED_OS=cygwin

to ~/.babunrc instead of ~/.bashrc

[levanlom96]

@oliver-dungey thank you! Worked for me

[smekal15]

vagrant destroy --force does the trick though for me on vagrant 1.7.4.

[GrayedFox]

I have an interesting take on this bug....

When I tried to destroy images using an alias which launches a simple script to execute the vagrant destroy command I was piping "y" input (no longer since reading about --force).

# Destroy local aphrodite
alias aphroDown="echo -e yes\nyes | . ~/Scripts/localAphroditeKill.bash"

This resulted in the error message reported here. Now that I'm using force I took out the echo pipe and just run the script directly. Just thought I'd leave this here in case it helps anyone.

[pharazon]

I tried to use remove-old-versions -plugin, but on my Ubuntu 14.04 none of the above worked, or yes N | vagrant remove-old-versions. But then I installed apt-get install expect and made the following script (this answers N(o) to the question do you want to remove the box):

#!/usr/bin/expect
spawn /usr/bin/vagrant remove-old-versions
expect "Are you sure you want to remove this box?"
send "N"

[ghost]

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.