Yup, you read that right. Sounds crazy, I know. But entirely possible, and surprisingly usable. Pretty easy too.
Enabling Windows Subsystem for Linux
Follow this official guide - Windows Subsystem for Linux Installation Guide for Windows 10 - to enable WSL on Windows. Make sure you follow till step 5 of the manual method to have WSL2 as default. Everything is explained in great detail in the guide.
Now, there are two ways to install Arch - the first one is extremely easy and preferable, and the second is for those who like to have more fine-grain control over stuff.
Installing Arch Linux - Method I
Arch Linux used to be an official app on the Windows Store some time ago, but the Arch community isn't onboard with the concept of WSL, or they aren't exactly comfortable with how easy WSL makes Linux installations for Windows users. Not to worry though, since both Arch Linux and the WSL kernel are open source, you can just easily install it manually too. Follow the steps given in this short guide How to Setup | ArchWSL Documentation.
Installing Arch Linux - Method II
We will use a tool called LxRunOffline to install and manage WSLs on our system. Open up Administrator CMD and run the following commands:
cd %USERPROFILE%\Downloads
curl -LO https://github.com/DDoSolitary/LxRunOffline/releases/download/v3.5.0/LxRunOffline-v3.5.0-msvc.zip
powershell -c Expand-Archive LxRunOffline-v3.5.0-msvc.zip
cd LxRunOffline-v3.5.0-msvc
copy LxRunOffline.exe C:\Windows
The last line copies the LxRunOffline.exe file to a location which is included in PATH environment variable, so that we can call this from anywhere. Here, for example, it copies this to 'C:\Windows' (this is why elevated access is required).
Now, we have to download Arch rootfs. In CMD, run:
cd %USERPROFILE%\Downloads
curl -LO https://mirrors.edge.kernel.org/archlinux/iso/2020.12.01/archlinux-bootstrap-2020.12.01-x86_64.tar.gz
Once the download is complete, we can instruct LxRunOffline to start the extraction:
mkdir D:\WSL\Arch
LxRunOffline i -n Arch -d D:\WSL\Arch\ -f %USERPROFILE%\Downloads\archlinux-bootstrap-2020.12.01-x86_64.tar.gz -r root.x86_64
Instead of 'D:\WSL\Arch\', you can specify any location path. Also, make sure the path doesn't have any spaces (Linux doesn't like spaces). This can take a bit of time.
After that, run:
wsl --set-version Arch 2
wsl ~ -d Arch
By default, Arch is installed as an instance of WSL1. We don't want that, so the first line fixes that. The second line runs the Arch distribution (the '~' tells it to open in the default home directory).
Now the rootfs we downloaded was an absolute minimal install, and includes nothing by default. To add to the problem, the package manager pacman wouldn't run because all the mirrors in '/etc/pacman.d/mirrorlist' are commented by default, and we don't even have a text editor to uncomment them! To fix this, we just open it in notepad (life hack!):
notepad.exe /etc/pacman.d/mirrorlist
Uncomment the three worldwide mirrors (or the ones based on your location). After that, we will install the basic utilities and a terminal text editor:
pacman-key --init
pacman-key --populate archlinux
pacman -Sy base base-devel nano
Next we'd want to add a non-root user. Run the following to create a user username and give it a password:
useradd -m -G wheel username
passwd username
EDITOR=nano visudo
Here, uncomment the line that says %wheel ALL=(ALL) ALL, save and exit the editor.
Exit Arch. To make this new user the default user of Arch, run this in CMD:
LxRunOffline su -n Arch -v 1000
The next time you start Arch, it'll start as username.
Installing KDE Plasma
After you've created a non-root user, run the following commands in Arch's bash shell to update existing packages and install the KDE Plasma desktop environment:
sudo pacman -Syu plasma
Now there are multiple ways of enabling displays in WSL2 - X display forwarding, Virtual Network Computing and Remote Desktop Protocol. We'll cover two of them, first X and second VNC. While I was able to set up RDP connections in Debian-based WSLs, I couldn't get it to work in Arch.
The first method is extremely easy - just a few clicks - and doesn't involve inputting commands. However, it might not be as responsive and reliable (when you might have multiple WSL distros) as the second. The second method requires heavy use of the commandline - for installing packages and editing configs.
Enabling GUI display - Method I
Configuring a proper X-server for WSL was always a pain, until now. Enter GWSL, a preconfigured X-server that uses VcXsrv under the hood. Since it is a general purpose X-server, it can be used for making graphical SSH connections, launching individual Linux apps and other cool stuff. Here we'll just press a couple of buttons to start KDE in Arch.
First run
Go to the Store page or pull down the latest release from its releases page and install it. Upon first launch, it'll ask for Firewall permissions; give it both Public and Private access. Once that's done, right click on the icon on the taskbar and set the Default Window Mode to 'Single Window Mode'. This is done because we want to launch the DE as a whole; this can be skipped if you just want to run Linux app GUIs in their own separate windows, through the Linux apps option in GWSL dashboard (after exporting the display variable).
Export environment variable
Once that's done, left-click on the same icon to pull up the GWSL Dashboard. From there, select GWSL Distro Tools (and select Arch from there if you have multiple distros). Click on 'Auto-Export Display'. It'll automatically restart Arch for the changes to take effect.
Command shortcut
Now we need to tell GWSL how to launch KDE. Open up the dashboard again and select Shortcut Creator. In this window:
- Put a name of your choice in the 'Shortcut Label' field, for example
KDE-Plasma. - The 'Shortcut Command' is
dbus-launch startplasma-x11. - For the 'Run In' field, select
Arch.
Click on 'Add this to Start menu' to finish.
Now launch this shortcut from the Start menu, and focus on the VcXsrv window. Viola, we're in Plasma!
Enabling GUI display - Method II
VNC allows us to send input and receive graphical output over a network, and we'll use TigerVNC server on our Arch subsystem and TigerVNC client on our Windows host system.
Configuring systemd
Arch Linux allows running VNC servers only as a system service, so we'll have to make sure we have a usable systemd. This is also mentioned as an optional step in the How to Setup | ArchWSL Documentation page. We'll use genie in this tutorial.
Installing genie would have been a lot easier, but unfortunately, because of reasons aforementioned, genie was pulled down from AUR. We can download and install the PKGBUILD (source) manually. The original PKGBUILD file has some license file issue, so I've modified the file and we'll use that. Run the following in bash:
sudo pacman -S base-devel
curl -Lo PKGBUILD https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=daemonize
makepkg -si
rm PKGBUILD
curl -Lo PKGBUILD https://gist.githubusercontent.com/rashil2000/f148d5fd207eb30c43f269dcd4f7c6fb/raw/73db1b0a14634c23b35a01168b5068aee877b74c/PKGBUILD-release
makepkg -si
rm PKGBUILD
The first command installs the packages needed to build other packages manually (you might get a warning regarding fakeroot, press 'n' for that). The next three commands install daemonize, a dependency for genie. The last three install genie itself, from my modified PKGBUILD.
Installing VNC server
pacman can be used to install TigerVNC server, while we can directly download and run the Windows client binary.
sudo pacman -S tigervnc
curl -Lo ~/.local/bin/vncviewer.exe --create-dirs https://bintray.com/tigervnc/stable/download_file?file_path=vncviewer64-1.11.0.exe
chmod +x ~/.local/bin/vncviewer.exe
vncpasswd
sudo nano /etc/tigervnc/vncserver.users
You should immediately set a password for your VNC server using vncpasswd (you can skip view-only password). The last command opens up a config. file where you need to put a new line saying :1={username}, where username is the name of the non-root user you set earlier (remove the braces). See the examples given in that file if you're confused.
Running VNC client
genie -i
genie -c sudo systemctl start vncserver@:1
~/.local/bin/vncviewer.exe -passwd ~/.vnc/passwd 127.0.0.1:1
The first command enables systemd. The second one starts up the VNC server as a service at the first VNC port. The third connects the Windows client to that server.
Viola, again! You'll have to run these three commands every time you'd like to spin up the GUI.
Enabling audio forwarding
coming soon
Again this is something that I was able to do only in Debian-based distros, through PulseAudio server. No luck in Arch yet...
Top comments (15)
I am hoping to add PulseAudio support to GWSL sometime in the future. It depends on business and demand ;)
Hey! Thanks for your efforts on GWSL! It feels good when utility authors themselves participate in such discussions :)
I had fun making it! :) I had no idea that this had any coverage anywhere. Thanks for writing about it! It is good to know it is working for people. I only see download stats and get very little feedback (compared to the number of installs) so it is good to see tutorials that use it. Now I want to try to get KDE working haha.
Hey hey - I've also posted an article about how to use GWSL to run KDE on Artix on WSL2 ( No SystemD ). Pulseaudio support would be outstanding.
Also, is there any way to use WSL2's ssh (or Windows OpenSSH?) instead of PuTTY for remote SSH? All my servers use Public/Private Key Authentication and that's just a right royal pain with PuTTY :)
Fabulous project though - thanks for it!
I have not done it but with other SSH tools but it shouldn't be a problem. You just need to forward the remote display to GWSL's display. I do not know how off the top of my head though. And glad you like it!
And GWSL 1.3.8 is out with audio support :)
Wow that's amazing. Can't wait to try it out!
is there any way you could run the pulseaudio without the microphone icon popping up in system tray?
I am used to not see it unless an app absolutely needs to use the microphone right now.
it seems that the pulseaudio server triggers the microphone icon permanently.
maybe dynamically be able to restart pulseaudio daemon in two configuration modes, one with microphone and in one without it, user selectable from GUI config of the app? I don't think I need pulseaudio to permanently hook the microphone device, even if it actually does not make use of it.
a major drawback of current state is that I would miss real microphone notification if some other app actually wants to use the microphone.
when only one app is using the microphone, when you hover the mouse it tells the name of the app. when 2 apps are using, it only tells "2 apps are using", which requires extra clicks to see exactly which ones are listed in the settings app
I tried like this unix.stackexchange.com/questions/2...
$ pactl unload-module 7
shared memfd open() failed: Function not implemented
"pactl list" relevant module:
Module #7
Name: module-waveout
Argument: sink_name=output source_name=input record=0
Usage counter: 0
Properties:
module.author = "Pierre Ossman"
module.description = "Windows waveOut Sink/Source"
module.version = "1.1"
the same error with
$ sudo pactl suspend-source 2 true
shared memfd open() failed: Function not implemented
Failure: No such entity
I am more interested in, what are your hardware specs? I am have MacBook Air 2012, with replaced SSD harddisk and 8 GB RAM.
My latest complaint is, VirtualBox performance is damn bad; and WSL2 is damn RAM hogging.
My PC has a 2nd Gen Intel i3 processor and 4 GB RAM. WSL does consume a lot of RAM, but I haven't noticed any performance impacts on other apps running alongside. Even WSL runs buttery-smooth for me.
I saw that 127.0.0.1 is used as the link address in the tutorial. This method is possible in wsl1, but I can’t implement it on wsl2. I can only use export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk'{print $2; exit;}'):0.0 Get the ip of wsl2 dynamically. And the link will be broken every time the wifi is changed or disconnected. Can you explain how to use 127.0.0.1 in wsl2?
You can't use 127.0.0.1. WSL2 is no longer running natively (i.e. through translation). It's a virtual machine now. So it'll function the same as a VM; it'll have it's own network interfaces separate from those of Windows.