Running sudo snap on WSL2 with ubuntu18.04

By following WSL: Am I running version 1 or version 2? I've verified that my WSL is version 2. Running uname -a outputs "Linux DESKTOP 4.4.0-18362-Microsoft"

I want to install microk8s on WSL2 so that I can use kubeflow. There seems to be many instructions on how to install microk8s by enabling sudo snap command by enabling sytemD however none of the instruction seem to work on mine.

1. following -> https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950

I got stuck on /tmp/install-sg.sh && rm /tmp/install-sg.sh running it outputs Error: Too many request

2. follwing -> https://wsl.dev/wsl2-microk8s/

I can't even run WSL command, when I do it outputs:

WSL
Wsman Shell commandLine, version 0.2.1

USAGE: wsl COMMAND [PARAMS...]

COMMANDS:
identify  - WS-Identify
enum      - WS-Enumerate
get       - WS-Get
put       - WS-Put
invoke    - WS-Invoke
xclean    - Delete all files generated by this tool set
xcred     - Create or display credential file
xcert     - Get server certificate (saved to <IPADDRESS>.crt)

PARAMS specification is specific to a COMMAND.

Output will be saved to ./response.xml. If you want to run parallel
executions in the same directory, define RTFILEPREFIX in the environment.
Doing so may significantly increase files generated.

Requires: curl, xmllint, GNU core utilities.
Optional: xsltproc for output formatting, gpg for encrypted credential.
Optional: wget as alternate for curl when not available.

and when I try to run apt install -yqq fontconfig daemonize it outputs:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

Thanks in advance!

Solution 1:

Older question that bumped by another NATO today.

There were at least two problems going on in this question.

First, Snap requires Systemd, and WSL doesn't support Systemd at this time. Instead, it uses its own /init as PID1.

There are some hacky workarounds available to start Systemd in a container/namespace. See this answer for a deeper dive.

The second issue was that running wsl ran the "wrong thing". You were expecting it to run the Windows Subsystem for Linux tool, but instead it ran the WSMAN command line tool.

Usually, the wsl command is run from PowerShell or CMD. In the Windows environment, running wsl and wsl.exe are the same thing.

But if you are in WSL/Linux, you do have to specify the extension explicitly, i.e. wsl.exe.

Normally the Linux wsl (WSMAN tool) isn't installed by default in Ubuntu, so I'm guessing you actually did a sudo apt install wsl at some point.

Regardless, running wsl.exe will get you the tool you were looking for in the first place.