I'm unable to switch to Gnome desktop envivorment in Kali linux running on WSL2. I'm booting with kex (kex -s). Already installed Gnome updatet to latest release, but it always boot in Xfce.
Tried this guide: https://www.youtube.com/watch?v=pX7RHXRgBLs&ab_channel=500ATC using https://sourceforge.net/projects/vcxsrv/ but when i start from terminal it gives me "something went wrong" error.
this doesn't work too: https://www.youtube.com/watch?v=SVUDIWKh_w0&ab_channel=TechSolutionZ.
Thanks.
Well, it's been a while since I worked with Kali or Kex, but I was able to get Gnome hobbling along, at least.
A few notes first:
This answer builds off several of my previous Ask Ubuntu answers:
Gnome requires Systemd, and Systemd does not play well with WSL (and WSL does not play well with Systemd).
There are ways to make it work (as I'll demonstrate), but I do not recommend running Systemd on WSL unless you really understand what is going on and/or can troubleshot it. Systemd drastically alters the behavior of WSL (and even other distributions that you might run under WSL). I came across another question just today where a Systemd script (similar to what I'm about to show you) is creating issues.
Running Gnome under WSL on Kali is not necessarily more difficult than running it under Ubuntu under WSL. Due to its Systemd requirement, it requires a lot of work on both. That said, Kali is a more advanced distribution, and so you'll often find more hand-holding on Ubuntu. Worth reading this Meta Unix post on Kali.
Just to be clear, Kali is a great distribution, and I have a lot of respect for it. Plus I appreciate the fact that their Kex implementation was several years ahead of the WSLg/Windows 11 support. However, those that run it need to be clear that there's more to noodle out on your own with Kali than with many other distributions.
Okay, with that out of the way. Here's how I run Gnome on WSLg/Windows 11 with Kali:
sudo apt install kali-win-kex # Just to be sure I was working from a similar configure as yours
sudo apt install gnome
sudo -b unshare --pid --fork --mount-proc --kill-child sh -c "export container=wsl; mount -t binfmt_misc binfmt_misc /proc
/sys/fs/binfmt_misc; exec /lib/systemd/systemd --system-unit=multi-user.target"
This starts up Systemd in a separate namespace, as I explain in some of the other answers I linked above. You'll need to give it a few seconds to start up. Check with ps -efH -- Once the udev processes start to die off, you should be good to proceed:
sudo -E nsenter -m -p --wd="$PWD" -t $(pgrep -xo systemd) runuser -P -l -w WSL_INTEROP -w WSL_DISTRO_NAME $USER -c "set PATH \
"$PATH\"; exec $SHELL"
You are now in that namespace, and with another ps -efH, you can see that Systemd is running as PID1, which it must in order to operate properly.
However, the bad news is that some of the default Systemd initialization for Kali (and most other distributions) has now overwritten the WSLg integration points, so we need to recreate them manually:
sudo rmdir /tmp/.X11-unix/
sudo ln -s /mnt/wslg/.X11-unix/ /tmp
export WAYLAND_DISPLAY=wayland-0
export XDG_RUNTIME_DIR=/mnt/wslg/runtime-dir
Xwayland :1 &
That will start up a background, fullscreen Xwayland server that Gnome can work on. Otherwise, it will clash with the already running Weston window manager (again, as mentioned in one of the other linked answers).
Hit Enter in your WSL/Kali shell to get a prompt again. Then:
export DISPLAY=:1
dbus-run-session gnome-session
Gnome should now be running under Xwayland. There's probably some way to run it under Wayland or Weston directly, but I haven't figured out how to just yet.
Note that there's still a lot going on in Gnome that will work erratically, since it's expecting a physical or virtual machine.
When you are done, make sure to wsl --shutdown to return everything back to a "non-Systemd" state.
As mentioned in my other answers, there are helper scripts out there for Systemd on WSL, but I recommend only going that route if you have to.
For Gnome, my advice would be to run in a virtual machine rather than directly in WSL. Ironically, you can even run that virtual machine (via libvirtd) inside WSL2. But that's a separate topic ...
