Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL won't start after Windows Update 18950 #4371

Open
kodeclan opened this issue Aug 2, 2019 · 39 comments

Comments

@kodeclan
Copy link

commented Aug 2, 2019

  • Your Windows build number: Microsoft Windows [Version 10.0.18950.1000]

  • What you're doing and what's happening:

  • I try to start WSL2 via wsl ~ -d DistroName
  • I get A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
  • I shutdown WSL using wsl --shutdown
  • I try to start the distro again using wsl ~ -d DistroName
  • I still get A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
  • I shutdown WSL again
  • I install a fresh copy via wsl --import DistroName2 <install-location> <rootfs.tar.gz> --version 2
  • I try to start WSL in the new install via wsl -d DistroName2
  • Again, I get A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

This happened after Windows Updated to 18950, (from 18945)

Also, the processes vmwp.exe and vmmem show up in the task manager and do not go away till wsl --shutdown is executed.

  • What's wrong / what should be happening instead: WSL console should appear.

  • For WSL launch issues, please collect detailed logs.

wsl-logs.zip

@xtremeperf

This comment has been minimized.

Copy link

commented Aug 3, 2019

Same here. My default WSL2 instance and sole WSL1 instance both work fine, but the other WSL2 instances have this problem and I haven't found a cause yet. It doesn't seem to be related to networking config or the new .wslconfig file. I may try rolling back to 18945.

@xtremeperf

This comment has been minimized.

Copy link

commented Aug 3, 2019

Alright, looks like we may have a bug in init...
here's the messages from the kernel ring buffer (using my one working WSL2 instance to check messages created when trying to launch a non-working instance):

init: (1) ERROR: UtilMkdir:1035: chmod(/bin, 40755) failed 2
init: (1) ERROR: ConfigInitializeEntry:903: Failed to create /bin 2

Annotation 2019-08-02 210149

@xtremeperf

This comment has been minimized.

Copy link

commented Aug 3, 2019

Alright, I just figured this one out...
init fails to create "/bin" because it already exists as a sym-link to "/usr/bin"!!!

So this issue only occurs with a rootfs that is /usr-merged... which includes Kali-linux in the Microsoft Store. Not really sure why init is trying to create a /bin directory anyways, but this is going to need to be fixed by someone at Microsoft since init is closed-source code.

@benhillis

This comment has been minimized.

Copy link
Member

commented Aug 3, 2019

This has been fixed and will be in an Insider build soon.

@kodeclan

This comment has been minimized.

Copy link
Author

commented Aug 4, 2019

Glad to know I'm not the only one having this issue. I've reverted to Windows 18945 for the time being.

@jugg3rn4ut

This comment has been minimized.

Copy link

commented Aug 5, 2019

Hi, any idea when the Insider build will be released please ?

@craigloewen-msft

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

The time from us checking in the bug fix to the change being available inside of an Insiders build can vary, and is dependent on many different factors. In general, it's around 3 to 6 weeks.

@jugg3rn4ut

This comment has been minimized.

Copy link

commented Aug 7, 2019

Hi @mscraigloewen, thanks for the answer. Keep up the good :)

@Chakratos

This comment has been minimized.

Copy link

commented Aug 7, 2019

Glad to know I'm not the only one having this issue. I've reverted to Windows 18945 for the time being.

Could you tell me how you downgraded? Can't wait the 3-6 Weeks and would love to use WSL2 :)

@RedBeard0531

This comment has been minimized.

Copy link

commented Aug 7, 2019

Now that the problem has been identified, is it possible to share a workaround. This build is completely unusable with this. I've downgraded, but Windows update keeps trying to reupgrade me. I was hoping that it would get fixed in this week's patch, but since it sounds like that won't be happening, do you have any suggestions?

@buwailee

This comment has been minimized.

Copy link

commented Aug 8, 2019

Same here on build 18956.

@jdamian

This comment has been minimized.

Copy link

commented Aug 8, 2019

It is possible to convert it to wsl 1 to keep it running

@Uberck

This comment has been minimized.

Copy link

commented Aug 8, 2019

"This has been fixed and will be in an Insider build soon."
As of 18956.1000 which I just installed, this is still not fixed...
edition
error

@Biswa96

This comment has been minimized.

Copy link

commented Aug 8, 2019

@Uberck From the screenshot, it looks like your distribution is installed, am I right? If yes, then you can create a user by loggin in as root with wsl.exe --distribution Ubuntu --user root and then create the user with useradd Uberck. Change the distribution name as you need.

@cerebrate

This comment has been minimized.

Copy link

commented Aug 8, 2019

I'm also getting this now on 18956.

Oh, for a functioning workaround.

@amechoul

This comment has been minimized.

Copy link

commented Aug 9, 2019

Hi!
Also running 18956.
For it seems that problem is only with Kali distribution.
My original kali didn't start.
Exported and imported but same issue.
Install a fresh Ubuntu and runs without problems.
Intall a fresh kali and also didn't start.

@Uberck

This comment has been minimized.

Copy link

commented Aug 9, 2019

Biswa yes it is installed, the only time I experience this issue is with the WSL2 Kali distribution.

@XLWZ

This comment has been minimized.

Copy link

commented Aug 9, 2019

I run a Arch distribution on 18956, also caught bugs
This bug is not yet fixing

@benhillis

This comment has been minimized.

Copy link
Member

commented Aug 9, 2019

I would suggest rolling back to the previous build until an Insider Fast build with the fix is released.

@AjawadMahmoud

This comment has been minimized.

Copy link

commented Aug 12, 2019

@benhillis, For those who aren't in a hurry. When is the next build going to be available? Since this is a serious bug for many, could this be elaborated for faster release for next build, even if it's a bugfix for this WSL issue?

@y103kim

This comment has been minimized.

Copy link

commented Aug 12, 2019

I'm also getting this on 18956 with Arch LInux.
Only Ubuntu 18.04 is working correctly

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\Users\illne> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-18.04    Running         2
@kzmuhia

This comment has been minimized.

Copy link

commented Aug 14, 2019

Not resolved for me I am already on 18956 and get the same error using Fedoraremix

@chadrien

This comment has been minimized.

Copy link

commented Aug 14, 2019

Workaround that ended up working for me (use at your own risk, but no issues so far):

  • start from a wsl 1 container (change version if needed with wsl --set-version $yourdistro 1)
  • wsl -d $yourdistro -u root
  • from inside the distro:
    • cd /
    • ls -Alh: take a look at bin and sbin
    • if bin is a symlink, remove it: rm bin. Same for sbin
  • get out of the distro and convert it to v2 (wsl --set-version $yourdistro 2)
  • wsl -d $yourdistro -u root -e /usr/bin/bash
  • from inside the distro:
    • cd /
    • if /bin was a symlink:
      • mv bin/wslpath usr/bin/
      • rmdir bin
      • mv usr/bin bin
      • ln -s /bin usr/bin
    • if /sbin was a symlink:
      • mv sbin/mount.drvfs usr/sbin/
      • rmdir sbin
      • mv usr/sbin sbin
      • ln -s /sbin usr/sbin
  • get out of the distro
  • make sure it works:
    • wsl -t $yourdistro
    • wsl -d $yourdistro: hopefully this should work
    • get out of the distro, run wsl -l -v and make sure the version is indeed 2 for your distro
    • open explorer.exe and go to \\wsl$ to make sure the network mount point is there

Hope this will be useful to others :)

@chenong

This comment has been minimized.

Copy link

commented Aug 14, 2019

@chadrien thanks, this work good for me.

@citruspress

This comment has been minimized.

Copy link

commented Aug 14, 2019

@chadrien Thanks! Working fine for me as well.

But I believe you may have this backwards: ln -s /bin usr/bin

It's ln [OPTION]... [-T] TARGET LINK_NAME.

Or maybe it was intentional so that swapping back and forth between v1 and v2 would work? Either way on arch I had to create it as it was originally like 'ln -s usr/bin /bin' otherwise I got some error when I tried to install packages using pacman.

@chadrien

This comment has been minimized.

Copy link

commented Aug 14, 2019

@citruspress it was intentional. I had to make /bin the actual directory and /usr/bin the symlink, otherwise if the wsl container is shut down, then I'd get the error reported here again. The only persistent fix I found was to swap /bin and /usr/bin

@citruspress

This comment has been minimized.

Copy link

commented Aug 14, 2019

@chadrien I see. I haven't noticed, I assume it hasn't shut down yet. Thanks again!

@Uberck

This comment has been minimized.

Copy link

commented Aug 14, 2019

@chadrien - Yes the fix works, but it has left my Kali-Linux distribution stuck with root user.

The screenshot I attached is where the installation process halted, so I'm not sure if the distro ever successfully fully installed...

Mind you, I am able to launch the distribution fine using wsl -d kali-linux, and it appears to be running fine (at least initially by running "help"

Just wondering if this looks ok to the rest of you (distro running in root by default)

kali-root-mode

@Uberck

This comment has been minimized.

Copy link

commented Aug 14, 2019

Going along with my last question, I've created a new user with sudo privileges in the Kali distro, but am unable to figure out how to set the default user as my newly creater user (I don't want to be running as root everyime I start the distro). How do I force WSL Kali to use a user other than root when launching with chadrien's fix?

@onomatopellan

This comment has been minimized.

Copy link

commented Aug 14, 2019

@Uberck wsl -d kali-linux -u $username where $username is the name of the user you have created.

@craigloewen-msft

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

@Uberck we are tracking the issue of changing the default user from root after importing a WSL distro here: #3974

@Uberck

This comment has been minimized.

Copy link

commented Aug 14, 2019

Thanks Craig and onomatopellan

@ Onomatopellan: I've incorporated that command into the profiles.json settings file for Windows terminal at "commandline" : "wsl.exe -d kali-linux -u myusername" under Kali settings, so this workaround is working nicely for now.

Craig: Thanks but I actually installed the distro from the Windows store, not the command line

@Uberck

This comment has been minimized.

Copy link

commented Aug 14, 2019

Suspiscions were right, its just a workaround for now...

Metasploit is broken :(

uberck@CPPCStation:/mnt/c/Users/Chris$ msfconsole
[-] ***rting the Metasploit Framework console...
[-] * WARNING: No database support: No database YAML file
[-] ***

uberck@CPPCStation:/mnt/c/Users/Chris$ sudo /usr/bin/msfdb start System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
[+] Starting database System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

@onomatopellan

This comment has been minimized.

Copy link

commented Aug 15, 2019

@Uberck If you need Systemd as PID 1 there are workarounds like https://github.com/arkane-systems/genie or https://github.com/shayne/wsl2-hacks

@craigloewen-msft

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

@Uberck if you've installed it from the store you can run the command:
kali.exe config --default-user $yourUserName
Just make sure to replace the $yourUserName value and you should be able to set a default user.

@navigaid

This comment has been minimized.

Copy link

commented Aug 17, 2019

Still not fixed in 18963. I'm going to revert back to 18945.

Update: no fix in 18965 either.

@GoodbyeNJN

This comment has been minimized.

Copy link

commented Aug 18, 2019

@chadrien It works fine in 18963. Thanks a lot!

@wight554 wight554 referenced this issue Aug 21, 2019
@XLWZ

This comment has been minimized.

Copy link

commented Aug 23, 2019

Still not fixed in 18965

@anaisbetts

This comment has been minimized.

Copy link

commented Aug 23, 2019

Is there a way to get any visibility as to what the WSL VM is doing? When errors like this happen you can't see any of the console log or anything, you just see the equivalent of "It didn't work /shrug"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.