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.
Related
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.
I've been using gitbash these past few days and it's working just fine. But a while ago, after install a pdf reader with patch file, when I opened my gitbash it gave me the error which says "Failed to run '/usr/bin/bash': No such file or directory". I don't know what happened and why, but I think the patch file of the application that I installed has something to do with it. My pc antivirus prompted a warning, and I took actions. Then the trouble in the gitbash happened. Please help me, I don't want to reinstall gitbash again coz I also have to install some things.
Had the same issue, searched for it, this is one of the first few results. So if you are looking why you got this message recently: check your antivirus and that the folder and the file actually exist. As previous answers mentioned, reinstall helps bring it back, but antivirus might break it again. So I would check your antivirus GUI and see if you can restore it and add an exception.
Mine was that Avast antivirus classified it as 'IDP.Generic' threat (weirdly only when I would close the shell with ctrl+c or ctrl+d on Windows 10).
to resolve this issue simply reinstall git.
I disabled Avast antivirus software
Then uninstalled and reinstalled git
It worked for me:)
Like jack this was caused by my virus scanner(avast). To resolve I opened the quarantine page restored and added exemption.
Try 'echo $PATH' in CygWin Terminal to get the PATH it must written something like
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/TortoiseHg:/home
Depending on the Chroot in you sshd_config it looks for the /bin/bash file
you will have three options
you might have to copy the files into the Chroot mentioned folder and give the permission.
You can update with you Chroot
Or bind mounting would also help
ref
To resolve this issue simply deactivate your antivirus while reinstalling git.
Installed Git for Windows 2.14.1. Pressing the 'Enter' button in the Git Bash terminal pastes the clipboard. All options are default. I've also tried options in many different configurations. But I can't figure out how to stop the pasting on pressing 'Enter'.
Could it be a Windows setting (Windows 7)?
My Windows home directory is a shared drive. Which has caused issues in the past, but this doesn't seem like it would be related.
Note, I tried on a different computer which did not display the same issue. This would seem to point to configuration or Windows environment issues. I've cleaned up all configuration I can find (.git*, .mintty*, old install location) and installed fresh, yet still run into the same issue.
Re-installing Git for Windows 2.10.1 (previous version used) is successful and does not have the pasting side effect.
I didn't see that effect on recent Git.
COPY and PASTE are still linked to Ctrl+Ins and Shift+Ins.
Check if the issue persists with the latest release 2.14.2 (PortableGit-2.14.2-64-bit.7z.exe)
I am taking a course on Udacity that requires me to set up a virtual machine on my system. I have already downloaded and installed Virtual Box and Vagrant. When I try to run the command vagrant up, I get this error:
Could anyone please explain what might be going wrong?
I am working on my office laptop so I cannot change the firewall settings. They are controlled by McAfee. Also, the firewall has been turned off by McAfee to the best of my knowledge. I tried searching a lot but couldn't come up with a solution to this.
Well, I researched more about this and was finally able to find something. This issue comes up when vagrant doesn't have folder permission. Sometimes Cygwin shell in Windows doesn't get permission to write or create a new folder.
I followed their github issue. This is what made it work for me:
Rename C:\HashiCorp\Vagrant\embedded\gnuwin32\bin\bsdtar.exe to
something like bsdtar_backup.exe (or temporarily move it)
In that same directory, create bsdtar.bat with this content:
#ECHO OFF
"%~dp0....\mingw\bin\bsdtar.exe" %*
This will result in Vagrant using the mingw binary, without you having to dive into some code. After these two steps, try adding a box.
Failed to load VMMR0.r0 (VERR_LDR_MISMATCH_NATIVE)
My VMs on Virtualbox 4.2 (on Windows 7 32-bit) were running absolutely fine until I started installing a new VM, which would not go beyond the Linux boot screen.
I deleted the VM and created new one, but it still didn't run.
So I installed the new version of VirtualBox (version 4.3.6.r91406) and rebooted the machine; but when I started any of my previously working VMs, I got the following error
Failed to open a session for the virtual machine m14
Failed to load VMMR0.r0
(VERR_LDR_MISMATCH_NATIVE
with the following details:
Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole
{8ab7c520-2442-4b66-8d74-4ff1e195d2b6}
On checking the forums, I saw few posts asking to check the .vbox files. In the directory of the VM, there are two, m14.vbox and m14.vbox-prev.
I removed the prev file and restarted the VM, again got same error, and the m14.vbox-prev file came again. So I then removed the original m14.vbox file and renamed the prev file to original and then started the VM: it still didn't work.
Any clues fixing this?
Hi I had the same problem in version 4.3
I disabled the floppy and the CD into the system configuration of the virtual machine and then the machine has started properly without realizing the error.
Add or update the extension pack.
If that doesn't solves the problem, then uninstall the Virtual Box, delete the following folder:
C:\USERS\<username>\AppData\Local\VirtualStore\Program Files\Oracle
then install Virtual Box again and run it as administrator. (In some cases running it as simple user may work too.)
Run as Administrator
I had the same problem after updating from 4.1 or 4.2, to 4.3.18.
I didn't reboot and the "Right click Virtualbox icon - Run as Administrator" technique worked for me (in Windows).
pls run the vbox-ssl-cacertificate.crt file. That may resolve above problem. This solution works for me.
FINALLY.
A while back I turned on ASLR for everything using EMET. Running EMET again and changing it back to the default of "Application OptIn" + reboot fixed it.
Like akshah123 I had driver verifier (verifier.exe) running because I was diagnosing random BSODs on my laptop. Running:
verifier.exe /reset
and then rebooting fixed this issue for me.
Launching VirtualBox as administrator got my VM running as normal.
Didn't need to try any other approach.