Closed incognico closed 4 years ago
Have you tried with distributions in WSL1?
Sounds like #246. Please check.
Yes now it seems to work, but something is still fishy:
PS C:\WSL\Alpine> .\Alpine.exe get --lxguid
{32d5d826-a51f-4ad8-ad42-e2cf8116bbb8}
When I open Windows Terminal it registers:
"guid": "{1777cdf0-b2c4-5a63-a204-eb60f349ea7c}",
Which is an old installation that was unregistered, it should be the first GUID, nothing else is installed.
And wsl/mintty does not seem to reference any GUID.
Aside from the scuffed GUID it just happened again out of the blue. This time several boots/shutdowns were in between. wsltty not working (closing after launch) while wt works. wsl.exe --shutdown
fixed it. I wonder why this only affects wsltty. I also have the feeling that the problem is connected to having \\wsl$
mapped as a network drive.
And wsl/mintty does not seem to reference any GUID.
The GUID is an undocumented Windows registry thing. Though wslbridge2 uses undocumented COM interface, the usage of WSL related registries are strictly prohibited by MS devs.
the problem is connected to having \wsl$ mapped as a network drive.
Suspicious 🤔 wsltty/wslbridge only opens a pseudo-terminal which may not be related to file system mounts.
usage of WSL related registries are strictly prohibited by MS devs
Oh really? Do you have a reference? While mintty uses the distro name for invocation with wslbridge2, it uses some other information from the registry. I don't see how everything would work without (entries BasePath and Flags in the first place to recognise V1 vs V2...).
Do you have a reference?
Search in the WSL issues with my user name, I've a reputation of suggesting registry as a workaround and each time MS devs warned me. Maybe WSL related registries will be obsolete in future. So I focused not to use registry in wslbridge2 in any manner.
This seems to be problematic, when disabled it works fine. Maybe still related to the mount.
Where is that option and what does it do?
powercfg.cpl -> Choose what the power buttons do. Fast startup is enabled by default in W10.
Found some WSL issues related with fast startup microsoft/WSL#4636
and microsoft/WSL#5298
.
Released 3.1.8.
It seems fixed with 3.1.8, at least it has not happened yet :)
I get this behavior with a converted WSL1 installation and with a freshly WSL2 installation (Alpine WSL, Windows 10 2004):
I've installed a new WSL2 distro, all is working fine until the PC is rebooted, after that wsltty does not launch anymore, it just closes itself after opening while Windows Terminal is still working fine.