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

branpurn commented 1 year ago

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

Fresh install Windows Server 2022
Install Windows Package Manager (winget)
Install Windows Terminal
Install WSL and Debian; setup Debian and ensure working independently
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.

lhecker commented 1 year ago

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

12474
12754
15072

Do the comments in any of these solve your issue?

branpurn commented 1 year ago

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

Unable to launch WSL Ubuntu - The system cannot find the file specified. #12474

fail to launch WSL (both 1 and 2) from terminal after update to win 11 Build 22581.ni_release.220318-1623 #12754

Error 0xffffffff starting WSL from WT #15072

Do the comments in any of these solve your issue?

Thanks-- will report back

12474, source is winget vs Microsoft Store but will try
12754, hex is same but error string is different, will fall-back to trying this
15072, DISM repair, will try this lastly

Edit: Unfortunately, none of this appeared to resolve.

carlos-zamora commented 1 year ago

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

branpurn commented 1 year ago

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.

DHowett commented 1 year ago

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 commented 1 year ago

@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

Upgrade to the version of WSL available in the Windows Store (sorry)
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[bot] commented 1 year ago

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.

microsoft-github-policy-service[bot] commented 1 year ago

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.

microsoft / terminal