Can anyone decode the following for me?
WSL was working perfectly on C++ a few weeks back.
Switched to try to run older Python under windows (not WSL) and it seems all twisted up now.
Can't get Win10 nor WSL to run. Keeps trying and failing to update. I re-ran the WSL and updated VSCode on the windows side. I AM behind a proxy but as far as I know, I've update all the files that google searches pointed me at. Pretty frustrated and would appreciate any help there is.
"
Request downloadRequest failed with message: getaddrinfo ENOTFOUND update.code.visualstudio.com. Will try to download on WSL side."
"
[2022-02-10 13:51:09.374] Setting up server environment: Looking for /home/ubuntu/.vscode-server/server-env-setup. Not found.
[2022-02-10 13:51:09.374] WSL version: 4.4.0-19041-Microsoft Ubuntu-20.04
[2022-02-10 13:51:09.374] Updating VS Code Server to version d6ee99e4c045a6716e5c653d7da8e9ae6f5a8b03
[2022-02-10 13:51:09.374] Removing previous installation...
[2022-02-10 13:51:09.674] Installing VS Code Server for x64 (d6ee99e4c045a6716e5c653d7da8e9ae6f5a8b03)
[2022-02-10 13:51:09.674] Downloading:
[2022-02-10 13:52:43.314] VS Code Server for WSL failed to start. No messages received for 90s
[2022-02-10 13:52:43.314] For help with startup problems, go to
[2022-02-10 13:52:43.314] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2022-02-10 13:52:43.328] WSL Daemon exited with code 0
"
I'm not 100% which step fixed it however I was able to proceed after.
Launching C++ project in wsl also tried to update and failed. The difference being that the install button did actually install the wsl server update w/o fail. So that error was gone.
I then launched another VSCode session with the Python project and the cmd terminal. I then had to use this help (https://github.com/pypa/pip/issues/9216#issuecomment-741836058) to adjust the proxy.
I could then proceed to reinstall ipykernel which is what had stopped working and was blocking me.
I'm pretty sure my environments are conflicting with each other. I'm afraid I don't understand VSCode environments well enough and very likely caused this problem for myself.
Related
I had Erlang 21.2 installed as I am using RabbitMQ (3.7.10), this is on Windows 10. I wanted to upgrade to a later version RabbitMQ (3.9.15), so I uninstalled 21.2 and installed 24.3.3. But after upgrading RabbitMQ I cant run RabbitMQ.
When trying to start I get the following error:
Unable to load emulator DLL
(C:\Program Files\erl-24.3.3\erts-12.3.1\bin\beam.smp.dll)
I thought this might be an issue with RabbitMQ and have uninstalled and reinstalled both Erlang and RabbitMQ multiple times now with no change.
I decided to try run Erlang manually from C:\Program Files\erl-24.3.3\erts-12.3.1\bin\ but when I run '.\erl.exe' I get the same error.
Taking Luke's advice we downloaded 24.3.4 and ran the installer. We also re-ticked the box to install windows binaries even though it said they were already present.
Not sure which of those two things actually fixed the issue but after that Erlang started successfully.
I am attempting to use ROS with the Gazebo GUI. I recently upgraded to Windows 11 for the WSL GUI support and have the gedit GUI working. However, when I run the command $ gazebo, the GUI does not open.
Running $ gazebo --verbose gives the following error messages
[Err] [RenderEngine.cc:749] Can't open display: :0
[Err] [GuiIface.cc:124] This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
After enabling the QT Debug environment variable using export export QT_DEBUG_PLUGINS=1 and rerunning the gazebo command with the verbose option set, It shows me
[Dbg] [GuiIface.cc:112] Got keys from plugin meta data ("xcb")
[Dbg] [GuiIface.cc:112] QFactoryLoader::QFactoryLoader() checking directory path "/usr/bin/platforms" ...
[Dbg] [GuiIface.cc:112] loaded library "/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so"
I believe that I have all of the necessary packages installed from this output, so I am wondering why gazebo is not showing up. I have tried uninstalling/reinstalling gazebo to no avail.
Thank you so much for your time. If I get this problem sorted out, I will post. Please let me know if any other system/output information is needed.
Other information:
I am not using X Server because the Windows 11 upgrade does not require it for graphical WSL applications (but did try it with X Server installed just in case)
I have tinkered around with the ~/.bashrc profile. DISPLAY=0:0 option was set, but I deleted this because Windows 11 did not need it (or so I think?)
Solution:
After reading up online, I found this answer to a similar question to mine.
https://superuser.com/questions/1681647/windows-11-wsl-not-opening-gui-in-my-ubuntu-shell
Getting ubuntu and re-installing gazebo on that worked. Now I can open up the Gazebo GUI.
WSL2 stopped working suddenly. If I do a new installation of linux distros. Then it throws the following error, when I click launch button for the linux distro from play store:
Installing, this may take a few minutes...
WslRegisterDistribution failed with error: 0x80070003
Error: 0x80070003 The system cannot find the path specified.
the wsl --help command works properly. All other wsl command hangs or throws error as shown below
like wsl -l command throws this error
The system cannot find the path specified.
I had the same thing happening to me after I moved the directory of my distro.
You have to unregister the distro from WSL;
wslconfig /u Ubuntu-20.04
and then just execute the installed exe and install the whole distro to WSL again.
I had to reinstall the windows to fix the issue. Something got corrupted in the OS. However, before reinstalling the OS as I had lot of work stored in the WSL2, I took the backup of the entire WSL2 image, the big .vhdx file. This file is the Virtual Hard Disk of WSL2 Linux. The files inside cannot be directly explored from Windows at the moment.
If one has not moved the file anywhere else, it is stored here: %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalState\ext4.vhdx
Before reinstalling the OS, after taking the backup, I wanted to test if this backup runs fine on new install of WSL2. For that, I tested it on another machine, by installing the same Ubuntu WSL2 distro and replacing the .vhdx file created with the backup file. It ran fine.
So, it felt safe to do entire OS reinstall and then reinstalling WSL2 Ubuntu and finally replacing the .vhdx file with the old backup .vhdx file. So, I did loose some time. But, my data and all the applications/programs on WSL2 were intact.
I know this is old but I had the same problem after deleting a driver associated with Hyper V and fixed it by uninstalling the virtual machine platform and Windows Hypervisor along with WSL, rebooted, reinstalled all 3 and then I could install Ubuntu again
This is my first answer on stack overflow and English is not my first language.
So, I will answer this question in images. My solution would not delete the date in any existing installed Linux distribution, at least for me.
Hope you can solve this problem successfully.
enter image description here
enter image description here
enter image description here
"Enable" Virtualization from your bios settings.
Settings may differ from bios to bios (search for your machine options)
I have installed Ubuntu 18.04 for windows subsystem for linux on windows 10, after enabling WSL in Powershell (instructions here: https://learn.microsoft.com/en-us/windows/wsl/install-win10).
I've done this before on a desktop but now I'm doing it on a laptop. I had no issues with the previous installation but this time around ubuntu will not launch. I get the ubuntu console popping up briefly before disappearing.
Also trying to run bash.exe from the command line fails silently (doesn't hang, just exits with no message), which may be related.
I'm struggling to figure this out as I have no idea where any error messages might be logged. Does anyone know how I can investigate further why this is happening?
Setup is a windows 10 Pro, os build 17134.376, everything up to date.
I'm struggling to figure this out as I have no idea where any error messages might be logged. Does anyone know how I can investigate further why this is happening?
Check with wslconfig.exe /l all registered distros, try to deregister the one you have problem with ( e.g. wslconfig.exe /u Ubuntu [^1]) and run the ubuntu.exe in your distro once again. Just a wild guess, it might be also a problem, if you have more than one copy of the linux distribution in you home directory.
[^1]: Warning: deregistering will delete all the associated files!
I've created an SVN repo on my Debian Wheezy build server following this tutorial.
svn --version gives 1.6.17.
Sadly, I can't commit anymore to the repo from my Windows 7 machine; it fails with the following error message:
Transmitting file data .svn: E730054: Commit failed (details follow):
svn: E730054: Error running context: An existing connection was forcibly closed
by the remote host.
I have had this error both with TortoiseSVN and the command line client.
These are the contents of /var/log/apache2/access.log on the server for the time of the failed commit: access.log.
There is no entry for the same time in the error log.
I'm still able to check out the contents of the repo and svn info http://myurl/svn/myrepo works also fine.
The Debian server with the repo is running inside a VM on a Windows Server 2008 R2 (Hyper-V-Manager 6.1). The connection from my Windows machine to the Windows Server is established using FortiClient 4.2.8.0307.
After I ran into this error yesterday, I purged svn from the server and setup the repo again. This made the repo accept commits for a couple of hours until it failed again with the same error.
Currently commits work again with TortoiseSVN but fail with the command line client.
What does E730054 mean and how can I fix it for good?
I have upgraded to Jessie in the meantime, but the situation did not improve. Commits with Tortoise stopped working again, meaning that it hangs at the "Sending Content" action for about five minutes and then prints the error that's in the title.
Checkouts still work without a hitch, though.
apache2 -v:
Server version: Apache/2.4.9 (Debian)
Server build: Mar 29 2014 21:52:01
svn --version:
svn, version 1.8.8 (r1568071)
compiled Apr 1 2014, 03:41:42 on i486-pc-Linux-GNU
Here's a thread that discusses the error, but I could not conclude a solution for my problem from it.
I noticed that the problem occurs when I want to commit the second modification of a file.
My fix
The issue went away permanently after using svnserve instead of apache2. This tutorial helped me set it up.
I had this problem with a single file while attempting to check in multiple files using Tortoise SVN on Windows 7 x64. Several attempts to commit the file using a variety of different versions of Tortoise SVN and the command-line version of SVN failed.
At the time, my laptop was using my home ISP internet connection. When I later went to work and attempted to commit the failing file from my employer's network, the file was committed without a problem.
I don't know why that was the case, but if you encounter this problem and find your way to this answer through a search engine query, you may want to try again – using a different internet connection. While not a solution to the problem, it may provide a temporary work-around.
As I was reading over the thread, it seems like some problems in the WEBDAV implementation on client site crashing the apache-thread. I had other issues with pre 1.8 repositories and I solved most of them by dump/reload the whole repository into a new one (using "svnadmin upgrade" is not sufficient!). Pre 1.8 repos have sometimes "corrupt/obsolete" data in revision files which is ignored by clients. It seems that this could cause the segfault.
You can dump/reload your repository like this:
svnadmin create newrepos
svnadmin dump oldrepos | svnadmin load newrepos
Note that it could take a tremendous amount of time to perform an update/reload cycle (approx. 1GB/h +- 50% depending mostly on disk speed).
If you have a different time, please post your time, I am doing a private research of dump/reload cycle performances.
I was getting this error.
Error running context: An existing connection was forcibly closed by the remote
I solved this issue by switching the proxy to Cntlm and it works perfectly fine.
I am using TortoiseSVN 1.9.3 version.
I was getting this error.
Error: An existing connection was forcibly closed by the remote
I am using the TortoiseSVN 1.11 version.
I am using checkpoint VPN, I simply restart my VPN connection
I too faced the similar issue.
SVN details: TortoiseSVN 1.12.0, Build 28568 - 64 Bit
Solution: Go to task manager and search for Tortoise SVN cache service, end this task and retry to update/commit the changes.
Hade same error.
My problem was with Avast antivirus, when i put the url of the svn server in the exclutions the problem was solved.
I met this problem after our svn server migrated from lan to internet. At last, I solve this problem by changing my IP Address.
For Example: from 192.168.0.60 to 192.168.0.71.
SVN Version: TortoiseSVN 1.9.7, Build 27907 - 64 Bit
OS Version: Windows 10, 1703
I too had this issue in SVN client. I cleared the temp folders in windows. Then cleared all data including auth details from "saved data" in SVN settings. Then retried in SVN, it asked for authentication and it opened fine without any error.
I had the same issue when using VPN with CollabNet's SubversionEdge.
I simply enabled Subversion Server should serve via https in Configuration -> Server Settings and this solved the issue for me.
I solved this for myself by using Eclipse to commit (I guess that's Subclipse then) instead of Tortoise 1.8.11
I didn't try too many of the other answers first but I did reboot, try diff internet connections, and I tried end tasking the TSVN Cache service. None of those worked and didn't get around to trying others. I also tried deleting the entire folder locally, did SVN checkout and applied the exact same changes (merged in a few commits from trunk) and tried committing... still wouldn't work with Tortoise SVN but then I tried Eclipse and it worked immediately.
My next commit worked perfectly fine with Tortoise SVN. Not sure what the cause was.