Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows Terminal installed to Windows Server 2022 via Windows Package Manager (winget) cannot open Windows Subsystem for Linux #15603

Closed
branpurn opened this issue Jun 26, 2023 · 8 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity.

Comments

@branpurn
Copy link

Windows Terminal version

1.17.11461.0

Windows build number

10.0.20348.0

Other Software

Name   Id            Version  Source
--------------------------------------
Debian Debian.Debian 1.12.2.0 winget

Steps to reproduce

  1. Fresh install Windows Server 2022
  2. Install Windows Package Manager (winget)
  3. Install Windows Terminal
  4. Install WSL and Debian; setup Debian and ensure working independently
  5. Attempt to launch Debian in new Windows Terminal tab

Expected Behavior

Debian would launch with immediate access to bash prompt

Actual Behavior

The following error appears:

The system cannot find the file specified.

[process exited with code 4294967295 (0xffffffff)]
You can now close this terminal with Ctrl+D, or press Enter to restart.
@branpurn branpurn added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jun 26, 2023
@lhecker
Copy link
Member

lhecker commented Jun 26, 2023

@lhecker lhecker added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jun 26, 2023
@branpurn
Copy link
Author

branpurn commented Jun 26, 2023

There are multiple other issues with the same failure code. See here:

Do the comments in any of these solve your issue?

Thanks-- will report back


Edit: Unfortunately, none of this appeared to resolve.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jun 26, 2023
@carlos-zamora
Copy link
Member

This bug from the WSL repo seems like it might be related (same error code and version of windows server).

@carlos-zamora carlos-zamora added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Jun 28, 2023
@branpurn
Copy link
Author

This bug from the WSL repo seems like it might be related (same error code and version of windows server).

Could be related. FWIW, WSL works fine outside of Windows Terminal from default shell launcher.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jun 28, 2023
@DHowett
Copy link
Member

DHowett commented Jun 28, 2023

WSL works fine outside of Windows Terminal from default shell launcher.

Really!

Okay, this is going to sound crazy... but can you change the commandline of your WSL profile from wsl -d Whatever to wsl ~ -d Whatever and see if it is still broken?

@DHowett DHowett added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Attention The core contributors need to come back around and look at this ASAP. labels Jun 28, 2023
@DHowett
Copy link
Member

DHowett commented Jun 29, 2023

@branpurn got back to me over e-mail, as they were unable to comment here due to our interaction limits.

Below, for posterity:

Forcing to home directory in the commandline does appear to resolve the issue. So perhaps a WSL issue?

...and my reply:

a-ha! That’s both WSL’s and Terminal’s fault. I’ll write up a response on the issue explaining why and what we can do about it! Thanks for testing with me.


So, this is an unexpected interplay between WT's automatic starting directory promotion and WSL's relative outdatedness on Windows Server 2022.

As a bit of stage-setting: WT wants to support starting directories that are not Windows paths when you're launching a WSL profile, so that you can set one to start in /home/dustin/projects or /foo or wherever.

To do that, WT takes your starting directory and yeets it into the command line directly. This moves the responsibility for parsing it over into WSL, so CreateProcess() (a Win32 API call) doesn't try and fail to find ~ or /foo.

In effect, we transform a profile that looks like this:

"commandline": "wsl",
"startingDirectory": "/foo"

into this:

"commandline": "wsl --cd /foo",
"startingDirectory": null

It just so happens that the version of WSL that was inbox with Server 2022 does not support --cd.

Adding ~ is a permanent workaround. We will not try to mangle the starting directory if we can tell that the user has done so intentionally themselves. wsl ~ is a (supported) legacy way to make WSL start in ~, so its existence counts as intention.


Fixes

  1. Upgrade to the version of WSL available in the Windows Store (sorry)
  2. Live with wsl ~ -d bar

Number 2 precludes you from having profiles that start in /foo, but so does the lack of --cd support. Number 1 might have its own problems, but we are not yet aware of what they are.

@microsoft-github-policy-service microsoft-github-policy-service bot added the No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity. label Jul 3, 2023
@microsoft-github-policy-service
Copy link
Contributor

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

1 similar comment
@microsoft-github-policy-service
Copy link
Contributor

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting No-Recent-Activity This issue/PR is going stale and may be auto-closed without further activity.
Projects
None yet
Development

No branches or pull requests

4 participants