I've been running WSL2 on Windows 10 for several months now and just recently lost these abilities. I can still open a WSL2 terminal and interact with my Ubuntu installation there.
Accessing WSL2 files from explorer
I could previously go to \\wsl$\Ubuntu and see all my WSL2 files. I can still see the Ubuntu folder at \\wsl$, but when I try to open it I get a loading bar and nothing happens (even after waiting for a long time):
Also in Powershell:
Opening Windows program from WSL2
Previously I could open Windows programs like explorer and VSCode from a WSL2 terminal with explorer.exe and code respectively. Now when I try this the terminal just hangs and nothing opens.
Note that I can still navigate to /mnt/ and see all my Windows files from the WSL2 terminal.
I'm running Windows 10 Version 1909 (OS Build 18363.1379) and Ubuntu 20.04.1.
I'm not sure I have an answer for you, but some general troubleshooting steps to try:
Exit your instances and try a wsl --shutdown.
If that works, try turning off Windows Fast Startup. Also avoid hibernation. These are known to interfere with some WSL network functionality.
Try adding the following section to your /etc/wsl.conf:
[interop]
enabled = true
This should be the default, but it wouldn't be the first time we've seen WSL not following the defaults for some reason.
Make sure your Windows temp directory is not compressed
Make sure your distribution folder under %userprofile%/Local/AppData/Packages is not compressed, especially the LocalState subdirectory where the ext4.vhdx lives.
If enabled, try turning off Windows Ransomware Protection
I had the same issue (although on Windows 11). It was very annoying. I noticed that after a restart it was ok, but after a few minutes and almost always after running VSCode, it was breaking again. Here's what worked for me:
exporting my distro (wsl --export <Distro> <FileName>)
unregistering it from WSL (wsl --unregister <Distro>)
uninstalling all WSL-related stuff, like the optional Windows feature, the WSL app from the store (I had them both). I also removed WSLg but I'm not sure if that was necessary
restarting
installing again the app from the store (no need to turn on the optional Windows feature anymore in case you are on build 22000 or higher)
finally just reimporting the distro (wsl --import <Distro> <InstallLocation> <FileName>)
After going through the above steps the issue was resolved and now my WSL2 works like a charm.
Related
I have a very strange problem with Cygwin sshd and changing the PATH environment variable through the Windows control panel. This is with Windows 10 64 running in a Parallels VM
After a reboot ssh sessions into the Windows machine will still use the old path. Local Cygwin sessions have no such problem: they will use the new path.
Note the bold text: I am aware that without the reboot this is expected to happen (because sshd got started with the old environment). But the After the reboot has got me baffled. If I ssh into the machine I see the old PATH. If I then reboot the VM again and ssh in again I finally see the new path.
Incidentally (fodder for future people googling this) I had the problem while using gitlab-runner to run CI/CD jobs on Windows using Parallels VMs on my Mac. So I would prepare the VM to have all the right tools installed and everything set correctly, then shut it down. gitlab-runner will then clone the VM and run the CI/CD jobs on it. Works now, as long as I reboot the original VM twice with an ssh session in between before having it cloned by gitlab-runner:-)
I never posted the answer I found: the problem was that hibernate was enabled on Windows. Actually the first "restart" was usually a shutdown followed by a startup.
But, by default Win10 has hibernate enabled, and if that is the case a shutdown and startup don't actually reboot the OS.
Disabling hibernate fixed it.
Double-check your Cygwin sshd installation, as described in "Installing Cygwin and Starting the SSH Daemon"
it makes sure the %PATH% does not reference other SSH, like W10 OpenSSH.
it stops any other SSH service.
it defines a Cygwin SSH Windows service, using a local account, which then should pick up the same account new path after a single reboot (or even with restarting the service, without reboot)
I am not sure why you need two reboots in your case, but see if that Cygwin sshd setup works better.
Today I got this error message:
"WSL not found at: C:\Users\Nick\AppData\Local\Microsoft\WindowsApps\debian.exe"
Before this message today, everything worked fine (I start Debian through start menu, restart the ssh service, then start CLion and it linked up just fine.).
The executable is there, just 0kb. The strange thing is that the Linux environment can be opened from windows as always (debian), I can ssh into it just fine (looks like CLion can as well, see picture).
This happened after an update tot CLion 2018.2.2 from 2018.2.1. Rolling back did not fix the issue.
What could be going wrong here?
I've found a fix for the issue. In Windows config select the apps list, find Debian and press advanced settings. Then end the service and recover it (the mild recovery was enough for my case). Although I'm not certain it aided in fixing the issue I've also removed the Jetbrains folder in the LocalCache/Local folder of the Debian folder in my AppData\Local\Packages.
I'm using the Linux Subsystem for Windows (or whatever that new, fancy Ubuntu/Bash terminal is called in Windows 10). I'm using it in my Windows VM, which I am using to test an application developed and stored in Subversion.
I should point out that using the regular Windows command line, everything works perfectly with absolutely 0 issues. I just prefer Bash.
Anyway, svn is properly installed, and I can do commands like "svn status", "svn add", etc, in the Bash terminal no problem. However, if I try doing an "svn update" or "svn commit", that's when the problem happens.
I get the following error message:
myname#DESKTOP-VF4GBEA:~/Documents/Project$ svn update .
Updating '.':
svn: E000011: Unable to connect to a repository at URL 'https://some-url.com/trunk/Project'
svn: E000011: Error running context: Resource temporarily unavailable
I'm unsure why this is happening from the Bash terminal and not the Windows command line. I have Windows Defender disabled, no firewall there. I'm running Windows 10 Creators Edition (the latest version) in a virtual machine using VMWare Fusion on Mac OS Sierra. I do have Norton/Symantec protection running on the Mac, but it doesn't show anything having blocked a connection.
Regardless, doing these commands from the Windows command line, as I said, work perfectly fine.
Ok, I figured out the answer. The svn URL I was hitting was actually configured via my hosts file in the windows vm:
123.45.6.789 some-url.com
This was done in the windows file: C:\Windows\System32\drivers\etc\hosts. However, to get it to work in the Windows Bash Terminal, it needed to also be configured in /etc/hosts. That was the issue.
Ok, this is good to know. I guess the Bash/Windows thing uses all of its own configurations.
I downloaded and ran setup, and it seemed to completed normally, but after it completed I didn't have cygwin in my startup menu or a shortcut on my desktop, both of which I selected. The C:\cygwin does exist, with subdirectories under it. I execute c:\cygwin\bin\xterm. It flashed on the screen with an error message, but it was too quick to read. I have run cygwin before on XP without problems, but this is the first time with Win 7.
Is there some background process that needs to be running for cygwin to work? I am wondering if the installation is OK, but I am just missing the startup menu entry or desktop icon which starts a background process, or is there some path or registry entry I need to make.
The problem was I didn't install as administrator. When I went back and re-installed as administrator, everything worked fine.
All,
Am trying to get Node.js to work on Vista machine.
I installed Cygwin (as per the Github instructions) which appears to have been installed correctly. However, none of the commands are executing.
Are there any tutorials for the stages after the Cygwin installation?
PROBLEM: When any command is executed, I get 'Bash: command not found' error.
Not even command like 'c:\cygwin\bin' is executing.
When I type 'user' in cygwin command prompt, I get 'ntvdm has encountered an system error. Parameter incorrect'.
I thought the above error may be due to the firewall, disabling the firewall did not have any effect, running the program with admin rights also did not change the results...
Am confused and would love to get some guidance on what steps to go with next on getting Node.js up and running on a Windows Vista machine.
Many thanks,
UPDATE1:
We managed to make a bit more progress. It appears that we had not installed all the relevant files related to Cygwin. Upon re-download and reinstalled, it ran well, however, we have driven into another error. Error we get:
How to compile/install node.js(could not configure a cxx compiler!) (Ubuntu).
We followed the instructions as per the above thread (3rd post from top for Windows machines), however, we are still stuck at the same error.
Any guidance please?
Have you tried just using the Windows self contained binaries? http://node-js.prcn.co.cc/ This way you actually don't need to bother with Cygwin.
At first, i tried it your way too, using Cygwin. After smashing my head for the 10th time against a wall i just stopped trying and found a much cleaner solution.
I'm using VirtualBox running a Debain guest system to locally develop on my Windows 7 machine. Using VirtualBox, you can easily set up shared folders or port forwarding for node apps between your Windows machine and your Debian guest system.
Since you are using a plain Linux-system, all the compiling-pain is blown away.
If you plan to run node.js in production on a windows system: don't. I hardly believe node.js will be ever stable enough on windows-based systems using MINGW/Cygwin...
People seem to run into problems with Cygwin because they think that they are using a Windows machine.
If you install Cygwin, and open a bash shell prompt using the Cygwin icon, you are now in a UNIX environment and everything works the same as it would on UNIX. That includes building node.js.
I think you added some info to the question and I can see your problem. Yes, normally on Cygwin it has been possible to build node.js just as you would on any UNIX system, but that is no longer possible on Windows 7. Before running ./configure you have to:
Close all cygwin apps.
Double-click on C:\Cygwin\bin\ash.exe
Run ./rebaseall and when it completes, run ./perlrebase.
exit from the ash shell window.
At this point Cygwin will be back to normal and you can ./configure and make install.