Closed gostalj closed 3 years ago
Your log file looks strange. It show the installation process first and one invocation attempt appended, right?
C:\Users\gostal\AppData\Local\wsltty\bin\mintty.exe
Are you trying to run the terminal directly from its installation directory? That is not supposed to work. The installation creates a couple of desktop shortcuts and start menu entries which provide a few extra parameters that mintty needs to run WSL.
No, running mintty by itself was just something I tried after having tried the various shortcuts in the start menu and on the desktop. In particular this is what I get if I run the desktop shortcut WSL in win8 compatibility mode:
C:\Users\gostal\AppData\Local\wsltty\bin\wslbridge2.exe
run in Command Prompt?Microsoft Windows [Version 10.0.21364.1]
.A little warning: I don't know if my program is too secure to be used in an enterprise.
The program ran before just fine ... and I just can't cope with 3rd button paste and wsltty came to rescue.
Sorry about the font. I don't know what I did
[Version 10.0.17763.1935]. Menu: OS build 17763.1935
Is that 1809? What does the Options - About popup of wsltty say?
I've just installed openSUSE Leap 15.2, reconfigured wsltty and it runs well. Perhaps you should upgrade your Windows?
The thing is that I cannot do that as it is a company laptop and the only Windows 10 provided is Enterprice LTSC version 1809. But perhaps I can downgrade wsltty?
Från: "mintty" @.**@.>> Datum: fredag 28 maj 2021 21:04:56 Till: "mintty/wsltty" @.**@.>> Cc: "Gösta Ljungdahl" @.**@.>>, "Author" @.**@.>> Ämne: Re: [mintty/wsltty] wsltty-3.5.0.2 closes immediately (#287)
I've just installed openSUSE Leap 15.2, reconfigured wsltty and it runs well. Perhaps you should upgrade your Windows?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mintty/wsltty/issues/287#issuecomment-850610376, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APYCLEC5VLT5BIPSLJDCA5DTP7SNPANCNFSM45WXMJJQ.
The wsltty project page says Requirement Since release 3.0.5, WSLtty requires Windows version 1809 (the November 2018 release).
So you may fetch an earlier version from the release area. Unfortunately, older versions do have their own respective quirks.
Not a good idea answering the notification mail directly, eh! @Biswa96 There is no problem running Leap 15.2 using cmd or powershell. @mintty Is there any guess as to when 1809 became insufficient? Releasewise, I mean.
Relating the problem to your Windows version is just speculation. Another guess is some misconfiguration, esp as you error screenshot looks weird, as if mintty would be asked to run /bin/bash. What is the command line ("Target") of the shortcut you used?
Hope this works. I am on mobile now. No, internet available at the moment.
The full line please, not just a visible part. Copy/paste, no picture needed.
My mistake. I thought it was the entire line since it started with C: Turns out it was only the configdir spec etc. Here is the entire line (now that I installed AppleMobileDeviceSupport to get internet access through my iPhone):
C:\Users\gostal\AppData\Local\wsltty\bin\mintty.exe --WSL= --configdir="C:\Users\gostal\AppData\Roaming\wsltty" -~ -
That does not seem quite an original shortcut as installed by wsltty as it contains user directories expanded, but that should not matter. Also, it is not the distribution-specific shortcut which would specify the distribution explicitly but rather the generic shortcut to run the WSL default distribution, maybe something is weirdly configured there; what does the Windows tool wsl -l
say?
For reference, the specific shortcut "openSUSE-Leap-15.2 Terminal" in the start menu should look like this:
%LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL="openSUSE-Leap-15.2" --configdir="%APPDATA%\wsltty" -~ -
This is the distribution-specific shortcut which shares the disappointing behaviour:
C:\Users\gostal\AppData\Local\wsltty\bin\mintty.exe --WSL="openSUSE-Leap-15.2" --configdir="C:\Users\gostal\AppData\Roaming\wsltty" -~ -
This is what I get if I do wsl -l:
M:\>wsl -l
Invalid command line option: -l
Usage: wsl.exe [option] ...
Options:
-d, --distribution <DistributionName>
Launch the specified distribition.
-e, --exec <CommandLine>
Execute the specified Linux command. The remainder of the arguments are
used as the command line to execute.
-u, --user <UserName>
Run as the specified user.
--help
Display this usage information.
--
Stop parsing arguments and pass the remainder to the Linux process.
This is, however, strange as wsl -l according to MS docs should give me a list of wsl apps. To get that I must do:
M:\>wslconfig /l
Windows Subsystem for Linux Distributions:
openSUSE-Leap-15.2 (Default)
which I wrote earlier. I tried the line with the variabels in CMD and it yields the same behaviour i e the wsl window shuts down right away. Could there be something amiss with the wsl command itself?
No, probably an incompatibility of wslbridge2 with the older Windows version; @Biswa96, are your aware of any changed requirement of your recent changes around WSL V2 mode?
Let me spin up a VM.
Uninstalled 3.5.0.2 and tried 3.5.0 which runs stable out of the box. Seems like mintty was right regarding wslbridge2.
So, here it goes. wslbridge2 uses an undocumented* interface to get the VM ID of WSL2. As that Windows is LTSC version, that undocumented interface is similar with the normal Windows version before 1809 (build 17763). If I has to support it, the logic to get VM ID has to be re-written from history.
I don't know how 3.5.0 wsltty works in your case but if it works you could use it.
* but well-known among many programmers :)
3.5.0.2 was the update to wslbridge2 0.8, in order to fix #281. Any chance to get #281 tamed without using an undocumented API?
Nope. There is no documented way to get WSL2 VM ID without Admin access.
OK, and (to refresh my memory) wasn't there a previous way to access WSL2 without VM ID?
Or, as the reporter runs WSL1, could wslbridge2 distinguish between the versions (as requested per parameter by mintty) and use the VM ID method only for WSL 2?
OK, and (to refresh my memory) wasn't there a previous way to access WSL2 without VM ID?
There is a way but it requires Administrative access and the program (wslbridge2) has to parse a json file. Here is my left-up project https://github.com/Biswa96/hvtool.
could wslbridge2 distinguish between the versions (as requested per parameter by mintty) and use the VM ID method only for WSL 2?
VM ID is only required for WSL1. wslbridge2 already distinguish between WSL1 and WSL2 (IsWslTwo()
in wslbridge2.cpp).
OK, thanks for catching up my memory. But then, what's the difference in wslbridge 0.8 that breaks the case described here?
Not sure about the cause but I can provide a separate wslbridge2 binary for LTSC (adopting the MS idea). In my humble opinion, LTSC isn't used by many users and isn't worth supporting like normal Win10.
I had a look at #281 and there is talk about the Insiders Program. Now, before the reinstallation of windows I had to join the Insiders Program in order to get openSuse Leap 15.2 as it was not available via Microsoft at that time (late 2019/early 2020). It is now so joining the Insiders Program was not necessary. I doubt there is any significance to it but I thought I should mention it, just in case.
@Biswa96 Am I to understand that LTSC version 1809 is somewhat behind so that the undocumented interface is not fully compatible with normal win10 version 1809? Of course I would appreciate if you did not leave me hanging out to dry but I can see your point.
I have a question regarding 3.5.0 and that concerns the line editing. I seems that deleting a typo doesn't go all the way. Example: ~>whiäch #example typo line editing gives me: ~> which joe If 'whi▒ch' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf whi▒ch
I don't exactly remember which typo gave me the error so the above is constructed (and not very likely to happen) but it gives the same error.
@gostalj, this looks like a locale setup problem on WSL side and is not a terminal issue.
@gostalj Just to make sure, does wsltty 3.5.0 work with both WSL1 and WSL2? Wait, does that LTSC even have WSL2? I am asking this because the evaluation LTSC ISO provided by MS does not have WSL2.
@Biswa96 And you think that I am the one to ask?! The main reason that I have a windows laptop at all is that 90%, perhaps more, of my colleagues have windows on their computers and the only work-at-home-solution provided requires windows. Any serious work I do on a CentOS 7 desktop which I can run from home but the VPN client is windows only. WSL gives me a familiar interface to manage the connection once the VPN is established.
To your question. I don't know if there are upgrades to the latest LTSC release. AFAIK the next LTSC release is due some time during second half of this year. According to this page the latest available release have up to and including version 1809 features but I also get the impression that the focus is on security and minimizing vulnerability so I doubt that any upgrades/updates will enhance the available features e.g. support WSL2. But I hope the next LTSC release will. So I can't tell if 3.5.0 works with WSL2 in LTSC as I don't believe it's supported yet,
As gostalj does not have the wsl
utility but only the older wslconfig
, I assume that Windows version does not support V2.
@mintty Thanks! exporting LC_ALL=enUS.utf8 fixed the line editing. I wonder why most LC* were set to POSIX. Edit: Apparently it is better to export LANG=en_US.utf8
Closing under the assumption the issue was resolved.
@mintty the exact same issue happens to me on Windows 20 20H2 [Version 10.0.19043.1151]
Standard wsl terminal works fine.
Output of wslbridge2.exe -x
(no window, hangs):
Backend CommandLine: "C:\Windows\System32\wsl.exe" /bin/sh -c 'exec "$(wslpath -u '\''C:\Users\user\AppData\Local\wsltty\bin\wslbridge2-backend'\'')" --xmod --cols 120 --rows 30 --port 58666 --'
Output of wslbridge2.exe
:
note: backend error output: wslpath: C:\Users\user\AppData\Local\wsltty\bin\wslbridge2-backend
/bin/sh: line 1: exec: : not found
Output of C:\Users\user\AppData\Local\wsltty\bin\mintty.exe --WSL="Arch" --configdir="C:\Users\user\AppData\Roaming\wsltty" -~ -
:
/bin/bash: Exit 126.
Failed to run '/bin/bash': No such file or directory
Output of wsl -l -v
:
NAME STATE VERSION
* Arch Stopped 2
@Biswa96
Yes, same issue
Yes, there was a recent update (I'm at 21H1, not 20H2 as reported earlier). In particular, these ones applied recently: KB5004237 , KB5004296 and a WSL kernel update to 5.10.16.
Yes
Yes and yes
I have however fixed my problem by rsyncing my data in WSL2 remotely, removing WSL2, Hyper-V, and then performing the reverse operation. It seems to work now.
Just installed openSUSE Leap 15.2 wslapp and then tried installing 3.5.0.2. Win10 enterprice LTSC version 1809. There are some errors, the significance of which I don't know. See the attached installation log in which I appended the startup error message at the end:
Failed to run '/bin/bash': No such file or directory /bin/bash: Exit 126.
I can stop the window from dying by temporarily running in compatibility mode for win8. Indeed, there is no /bin/bash in the wsltty installation directory. I have narrowed it down to mintty by running
C:\Users\gostal\AppData\Local\wsltty\bin\mintty.exe
in a powershell window which gives the same error.
Copying the existing /bin/dash and renaming it fixes the dying problem but that's as far as it gets. The openSUSE doesn't start.
I had an earlier version installled before but my laptop got smitten by some virus and was just reinstalled and I forget which version I used. This problem can also perhaps be down to some update packages that weren't installed before but I can't tell now.
A similar issue was around a couple of years back and I tried some of the tips but got nowhere.
wsltty-3.5.0.2.txt