How to tell in Linux under WSL if using WSL1 vs WSL2 ? #4555

k7aay · 2019-09-30T18:06:00Z

Documentation missing instructions in how to tell within Linux under WSL whether using WSL1 or WSL2.

bytebounder · 2019-10-01T03:22:37Z

Here is a helpful doc - https://docs.microsoft.com/en-us/windows/wsl/wsl2-install

while setting a distro to be backed by WSL 2, I would run the following command in Powershell:

wsl -s 2

You can find your Distro by running: wsl -l

therealkenc · 2019-10-01T04:49:27Z

You can find your Distro by running: wsl -l

Yes, but there is no particularly good way right now to know your own distribution name once you are inside. There was another ask for that recently #4479.

Probably (possibly?) one way is to run a regex on /proc/version. So WSL1 looks like:

Linux version 4.4.0-18985-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1-Microsoft Fri Sep 13 14:26:00 PST 2019

While WSL2:

Linux version 4.19.67-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Sun Aug 18 13:37:54 UTC 2019

If it were me I wouldn't make a hard bet on the WSL2 string being set in concrete, but conversely, I can't imagine the WSL1 format changing gratuitously (not without grumbling, anyway). Matching that "gcc version n.x.x" and testing for n < 8 probably pretty future proof. There are other heuristics that would work. Calling dmesg and looking for a stable string like "Hypervisor" (or pick another).

Biswa96 · 2019-10-01T15:50:36Z

Here is a sample C program on how /init takes care of WSL1 vs WSL2:

#include <stdio.h>
#include <string.h>
#include <sys/utsname.h>

int main(void)
{
    struct utsname buf;
    memset(&buf, 0, sizeof buf);

    int ret = uname(&buf);
    if (ret == 0)
    {
        if (strstr(buf.release, "Microsoft"))
            printf("WSL1\n");
        else
            printf("WSL2\n");
    }
    else
        printf("uname error\n");

}

therealkenc · 2019-10-01T16:16:43Z

+1 for code always. But implied in my post was maybe better not to rely on oe-user@oe-host never ever changing. That strstr() is leaning pretty hard on a capital letter 'M'. [The string "icrosoft" matches both.]

Biswa96 · 2019-10-01T16:32:43Z

There may be hundreds of ad-hoc way to do it. For example, only WSL2 has $WSL_INTEROP, /proc/config.gz, /dev/vsock, /dev/sda, tty shows /dev/pts etc.

therealkenc · 2019-10-01T18:13:25Z

Money ➡️ mouth:

// g++ -std=c++17 wslver.cpp -o wslver
#include <fstream>
#include <iostream>
#include <array>
#include <string>
#include <charconv>
#include <regex>
using namespace std::string_literals;

int main(int argc, const char *argv[])
{
    std::ifstream ifs;
    ifs.open("/proc/version");
    constexpr size_t bufsz = 128;
    std::array<char, bufsz> buf;
    ifs.getline(buf.data(), bufsz, '\n');
    std::string proc_ver(buf.data(), buf.size());
    std::regex rx("Linux version [0-9]+\\.[0-9]+\\.[0-9]+.*[Mm]icrosoft.*gcc version ([0-9]+)\\.[0-9]+\\.[0-9]+");
    std::smatch match;
    auto gcc_major = (std::regex_search(proc_ver, match, rx) && match.size() == 2) ? match[1] : "5"s;
    int maj = 0;
    std::from_chars(gcc_major.data(), gcc_major.data() + gcc_major.size(), maj);
    std::cout << ((maj < 8) ? "1\n" : "2\n");
    return 0;
}

throwable-one · 2019-10-08T16:16:38Z

detect wsl1:)
uname -r | grep Microsoft > /dev/null && echo "WSL1"

therealkenc · 2019-10-08T19:52:33Z

[ $(grep -oE 'gcc version ([0-9]+)' /proc/version | awk '{print $3}') -gt 5 ] && \
    echo "WSL2" || echo "WSL1"

andyneff · 2020-03-24T23:50:40Z

Update (Windows 10 version 2004):

I'm brand new to WSL2, however...

uname -r says microsoft-standard in it, so all checks for the word [mM]icrosoft would fail
(opinion) The gcc method seems arbitrary, assuming WSL1 never changes to a new gcc
(opinion) WSL_INTEROP still works, and seems like the best test for now, but that's just my opinion

levesquejf · 2020-04-06T16:45:30Z

WSL2 has the directory /run/WSL/ and not WSL1.

TuxVinyards · 2020-06-22T14:40:17Z

I think that perhaps a belt & braces approach is needed. We have don't have any control over WSL1 getting a similar folder added. Likewise, whether 'Microsoft' has upper or lower case.

Using [[ -d "/run/WSL" ]] && echo "WSL2 present" is nice and easy, I acknowledge. But IMO a better method is to test for the underlying hyper-v running system that WSL2 uses.

Try lshw | grep smp for instance. WSL1 shows 'smp' while WSL2 will show both smp & vsyscall32.

We can write something like WSL2_Flag="$(lshw | grep vsyscall32) ; if [[ $WSL2_Flag ]] ; then echo "WSL2 present" ; fi

Or alternatively, we can look in '/proc'. We can't guarantee 'lshw' to be present in every Linux distro, although it usually is:

In WSL1 cat /proc/interrupts is empty whereas with WSL2 it is positively active, especially the line for HVS Hyper -V !

eg. WSL2_Flag="$(cat /proc/interrupts ) ; if [[ $WSL2_Flag ]] ; then echo "WSL2 present" ; fi

vlovich · 2020-09-09T22:41:02Z

What about the environment variable WSL_DISTRO_NAME? [[ -n "$WSL_DISTRO_NAME" ]]. Is that a suitable & cheap way to detect WSL 1 or 2?

Biswa96 · 2020-09-10T03:43:38Z

No. WSL_DISTRO_NAME variable is set by /init binary blob for both WSL1 and WSL2.

vlovich · 2020-09-10T21:58:09Z

@Biswa96 I asked if it's suitable for WSL1 OR WSL 2, not WSL 2 vs WSL 1 so it sounds like the answer to my question is actually yes?

therealkenc · 2020-09-10T22:45:28Z

Yes but not retroactively.

mirabilos · 2020-09-28T14:25:42Z

@therealkenc is the way you described (distinguish between WSL 1 and WSL 2 using the GCC version) going to be guaranteed stable, even in future versions of WSL 1?

Which is the guaranteed way to distinguish between these two and nōn-WSL Linux then? The presence of the string icrosoft?

Someone suggested checking the root filesystem type, which for WSL 1 is wslfs, but that won’t help for WSL 2. Any other filesystem can be umounted… and some people have trouble with custom kernels and the detection mechanism you provided (especially in the “WSL vs Linux” case).

Anything that needs superuser privilegues (lshw…) is also out, for hopefully obvious reasons.

therealkenc · 2020-09-28T18:43:35Z

No guarantees in life. Although given that the unspoken textual API has now irretrievably leaked into userspace, yes, I would treat regex [Mm] difference as pretty future proof.

That said, users can (and do) compile their own kernels in WSL2 and then misname the their kernel, or compile with clang, so you can't count on the kernel string in WSL2 to be anything in particular. Fortunately (notwithstanding the env pollution) recent WSL has the WSL_DISTRO_NAME and WSL_INTEROP environment variables. WSL_INTEROP is only present in WSL2. Using them is not backwards compatible with older WSL though, and they won't EOL for years.

Possible approach:

Test for existence WSL_DISTRO_NAME. If it exists, test for WSL_INTEROP. Yes, WSL2; no, WSL1.
If WSL_DISTRO_NAME does not exist, fall back on the version string regex.

mirabilos · 2020-09-28T20:17:30Z

This might do. I was thinking of simplifying this a bit:

if / is wslfs, then it’s WSL 1, else it’s either Linux/Android or WSL 2
if WSL_INTEROP or even WSL_DISTRO_NAME is set or the version contains icrosoft it’s WSL 2, else Linux/Android

Doing this without /proc (which is not guaranteed to be mounted) is more tricky. After statfs("/", &buf), buf.f_type is 0x53464846 on my test setup. Is this true for all WSL 1 systems?

The WSL 2 detection is even more fragile. Addition of an API from the start would have helped :/

For version detection, uname(2) exists, so this can also be done without procfs. The WSL 2 caveats apply :/

therealkenc · 2020-09-28T22:22:30Z

Use uname(2) if you can't depend on /proc. The gcc test was belt+suspenders overkill, and given existence possibility clang probably does more harm than good. strstr(buf.release, "Microsoft") means WSL1. Else Linux/Android/WSL2. For your purposes WSL2 is Linux anyway.

mirabilos · 2020-09-28T22:55:08Z

therealkenc dixit:

In `uname(2)` if you can't depend on `/proc`. The `gcc` test was belt+suspenders overkill, and given existence possibility `clang` probably does more harm than good. `strstr(buf.release, "Microsoft")` means WSL1. Else Linux/Android/WSL2. For [your

OK, great, that will work.

purposes](https://github.com/tarent/ECN-Bits/blob/18320ef9e0b0a674e09668392224770d7ba6a7be/c/lib/tc.c#L53) WSL2 is Linux anyway.

Oh, kudos for finding this one. For that purpose, WSL 2 probably is “don’t use” anyway, considering the networking issues. But I guess there are other people around who might wish to figure out WSL 2, too. Perhaps an identifier can be added in a next version? Thanks, I’ll adapt the code to use uname(2) and check for WSL 1 only and document that.

therealkenc · 2020-09-28T23:18:02Z

WSL 2 probably is “don’t use” anyway

WSL2 should be perfectly fine. WSL1 looks like it might be "don't use anyway". Either that's a hard fail in your use-case, or it isn't a hard fail. If it isn't a hard fail, there is no reason for it to be a hard fail on Linux or Android either. Just let that function always succeed, and lie about success when it doesn't. If it is a hard fail, you don't need to test for WSL1. Let it fail.

The better approach than querying the OS is to test capabilities. Here, the runtime capability test is whether setsockopt(...IPV6_TCLASS...) works, not whether you are "on WSL1" or "on Linux". Maybe one day in some mythical future IPV6_TCLASS starts working on win32 (and by extension WSL1). I bring it up not for your specific use-case, but because near all of the "if(WSL)" scattered on the Interwebs are testing the wrong thing.

Perhaps an identifier can be added in a next version?

That's existence environment WSL_DISTRO_NAME for WSL plus && WSL_INTEROP to differentiate WSL1 v. WSL2. But you can't use it retroactively, so the uname(2) or /proc fallback is necessary regardless.

mirabilos · 2020-09-28T23:46:15Z

therealkenc dixit:

> WSL 2 probably is “don’t use” anyway WSL2 should be perfectly fine.

Except it doesn’t share the host network and doesn’t even support IPv6, AIUI (I haven’t tested this yet, this was information I gleaned from learning about WSL 2 ahead of tests) which is a pretty big problem. Disqualifyingly so.

_WSL1_ looks like it might be "don't use anyway". Either that's a hard

Nah, the _setting_ the traffic class is an add-on, the project is about _getting_ it really, and IPV6_RECVTCLASS (and IP_RECVTOS) work fine, both on WSL 1 and on Winsock2.

fail in your use-case, or it isn't a hard fail. If it **isn't** a hard fail, there is no reason for it to be a hard fail on Linux or Android

Mh, probably. I’ve documented this, but I’d expect Windows- oriented users to use the ws2/ variant anyway, which omits this functionality completely.

The better approach than querying the OS is to test capabilities. Here, the runtime capability test is whether `setsockopt(...IPV6_TCLASS...)` works, not whether you are "on WSL1" or "on Linux". Maybe one day in some mythical future `IPV6_TCLASS` starts working on win32 (and by extension WSL1). I bring it up not for your specific use-case, but because near all of the "`if(WSL)`" scattered on the Interwebs are testing the wrong thing.

Yes, completely! Unfortunately, some of the things fail silently, or need an actual network socket to test. This is also not quite my area of expertise, but if I figure out feature tests I’ll use them. I’ve got multiple places to work on first, though…

> Perhaps an identifier can be added in a next version? That's existence environment `WSL_DISTRO_NAME ` for WSL plus `&& WSL_INTEROP` to differentiate WSL1 v. WSL2. But you can't use it

Except when someone unset them… it’s like procfs… it’s normally there but not always. Still helpful but fragile. But thank you anyway. I’ll treat WSL 2 as regular Linux and proceed with the tests, and WSL is not the project main concern right now anyway.

Based on microsoft/WSL#4555 via https://github .com//issues/374 which has a ton more possibilities to detect WSL.

Based on microsoft/WSL#4555 via #374 which has a ton more possibilities to detect WSL.

t-ru · 2021-04-04T00:35:55Z

Detecting WSL (bash code). Tested with

WSL 1
WSL 2 (standard kernel AND custom kernel)

The detection should be future safe. Code is from a new (currently not released) native systemd initialization for WSL

https://github.com/t-ru/wsl-misc/blob/master/detect-wsl-version/detect-wsl-version-v1.sh

mirabilos · 2021-04-04T00:49:24Z

t-ru dixit:

Detecting WSL (bash code). Tested with

From a shell developer PoV this is horridly inefficient. You call mount twice, you can use grep -q instead of -c, a temporary file is also not necessary, etc. (I needed a C solution in the project that caused me to ask anyway.) bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

t-ru · 2021-04-04T01:33:30Z

From a shell developer PoV this is horridly inefficient.

Maybe. But it's working.

Is your C-Code working under all conditions?
No.

Is your C-Code posted above inefficient?
Yepp.
Checking uname is stupid.
Checking WSL_INTEROP before WSL_DISTRO_NAME is also stupid.

You call mount twice, you can use grep -q instead of -c

many roads lead to rome

a temporary file is also not necessary,

The temporary file is required. The reason is that commands (grep, awk, head, ...) are not work on wsl.exe.
The way with temp file is always working.

I needed a C solution in the project that caused me to ask anyway.

Feel free and write your one holy grail solution.

mirabilos · 2021-04-04T02:13:23Z

t-ru dixit:

> From a shell developer PoV this is horridly inefficient. Maybe. But it's working.

I’m almost tempted to make a more efficient shell implementation of the same algorithm, but your attitude is… off-putting, at least.

>a temporary file is also not necessary, The temporary file is required. The reason is that grep on the wsl.exe does not work.

Why even use grep? Shows how little you understand the Unix toolkit and shell. (But then, you mentioned systemd, so this is to be expected.) bye, //mirabilos -- 22:59⎜<Vutral> glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜<Vutral> die meisten raffen auch nicht mehr von windows | 23:01⎜<Vutral> bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?

t-ru · 2021-04-04T09:38:54Z

Why even use grep? Shows how little you understand the Unix toolkit and shell. (But then, you mentioned systemd, so this is to be expected.)

I know the tools very well. But I write the code on a system that has only a minimal set of packages installed. Writing tiny code on systems that have all the tools installed is easy. Another aspect is that WSL is from Microsoft. There, the clocks tick differently than usual. By the way, the code was written in less than 30 minutes.

Systemd is the devil and because it is so bad, all major Linux distributions have switched to Systemd. The problem with Systemd is not Systemd, but the users who don't understand it. It is the same as with Wayland.

I’m almost tempted to make a more efficient shell implementation of the same algorithm, but your attitude is… off-putting, at least.

The most important thing in an implementation is that it works. Optimization is phase 2. I published the code because there was no solution for the problem "detection of WSL" that works reliably so far. Feel free to adapt the code and write your own implementation.

t-ru · 2021-04-04T11:08:50Z

The optimized version

https://github.com/t-ru/wsl-misc/blob/master/detect-wsl-version/detect-wsl-version-v2.sh

mirabilos · 2021-04-04T15:37:36Z

t-ru dixit:

if [ -n "$( cat /proc/self/mounts | grep rootfs | grep -E 'lxfs | wslfs' )" ] ; then

cat | grep | grep… AAAAAAAAAAAAH!

>I know the tools very well. But I write the code on a system that has >only a minimal set of packages installed. Writing tiny code on systems >that have all the tools installed is easy.

It’s not about the amount of tools, it’s how one uses them.

t-ru · 2021-04-04T16:41:30Z

Bring butter to the fishes. Post better code. I will gladly take it over.

I found code from you

/* check uname first (this is improbable to fail) */
	if ((uerr = uname(&u)) == 0) {
		if (strstr(u.release, "Microsoft") != NULL) {
			/* pretty certainly WSL 1 */
			errno = e;
			return (1);
		}
		if (strstr(u.release, "microsoft") != NULL) {
			/* probably WSL 2 */
			errno = e;
			return (2);
		}
	}


if (getenv("WSL_INTEROP") != NULL) {
		/* relatively certainly WSL 2 */
		errno = e;
		return (2);
	}
	if (getenv("WSL_DISTRO_NAME") != NULL) {
		/* relatively certainly WSL under a WSL-1/2-capable NT */
		/* since we detect WSL 1 above, this is probably 2 */
		/* assume WSL 1 when uname(2) failed, though */
		errno = e;
		return (uerr ? 1 : 2);
	}

Top code... What is with WSL and custom kernels? Many, many "if" statements. Is this good code?
No. That's "divine code"

Write better code and post it. I'm waiting!!!

This commit filters the following warning: > UserWarning: Signature b'\x00\xd0\xcc\xcc\xcc\xcc\xcc\xcc\xfb\xbf\x00\x00\x00\x00\x00\x00' for > <class 'numpy.longdouble'> does not match any known type: falling back to type probe function. > This warnings [sic] indicates broken support for the dtype! > machar = _get_machar(dtype) To ensure that this warning is only filtered on WSL1, we try to detect WSL by checking for a WSL-specific string from the uname, which appears to be endorsed by WSL devs. (microsoft/WSL#4555 (comment)) I also tried checking the `WSL_INTEROP` and `WSL_DISTRO_NAME` environment variables as suggested in the above linked issues, but I liked that `platform` was already imported inside `casting.py`. There is perhaps a more thorough approach where we collect all raised warnings, test the collected warnings, etc. but I didn't want to overcomplicate things.

This commit filters the following warning: > UserWarning: Signature b'\x00\xd0\xcc\xcc\xcc\xcc\xcc\xcc\xfb\xbf\x00\x00\x00\x00\x00\x00' for > <class 'numpy.longdouble'> does not match any known type: falling back to type probe function. > This warnings [sic] indicates broken support for the dtype! > machar = _get_machar(dtype) To ensure that this warning is only filtered on WSL1, we try to detect WSL by checking for a WSL-specific string from the uname, which appears to be endorsed by WSL devs. (microsoft/WSL#4555 (comment)) I also tried checking the `WSL_INTEROP` and `WSL_DISTRO_NAME` environment variables as suggested in the above linked issues, but I preferred reusing the `platform` module that was already imported inside `casting.py`. There is perhaps a more thorough approach where we collect all raised warnings, test the collected warnings, etc. but I didn't want to overcomplicate things.

therealkenc added the question label Jan 21, 2020

therealkenc closed this as completed Jan 21, 2020

therealkenc mentioned this issue Jan 25, 2020

rustup doc does not work on Windows/WSL rust-lang/rustup#2206

Closed

ihor-sviziev mentioned this issue May 22, 2020

[WSL2] Correctly detect host IP address ModestCoders/magento2-dockergento#76

Merged

cherichy mentioned this issue May 24, 2020

Fix is_wsl() on wsl2 fish-shell/fish-shell#7027

Merged

mgautam98 mentioned this issue Jun 22, 2020

add launbrowser on run fonsp/Pluto.jl#190

Merged

ark3 mentioned this issue Aug 25, 2020

Cannot start telepresence in wsl due to iptables issue telepresenceio/telepresence#1091

Closed

evertheylen mentioned this issue Aug 29, 2020

WSL2 detection is not perfect on custom kernels arkane-systems/genie#75

Closed

WyriHaximus mentioned this issue Feb 2, 2021

Detect WSL(2) WyriHaximus/php-test-utilities#374

Open

This was referenced Feb 2, 2021

add some functions and changes makinbacon21/switchroot-script-builder#8

Closed

Fix and Improvements makinbacon21/switchroot-script-builder#9

Merged

This was referenced Feb 22, 2021

Publish the runing WSL version #6577

Closed

Provide a way to positively detect WSL from an app compiled on Linux. #423

Closed

WyriHaximus added a commit to WyriHaximus/php-test-utilities that referenced this issue Mar 3, 2021

Detect WSL and only use more then 1 thread when NOT on WSL

1e946f0

Based on microsoft/WSL#4555 via https://github .com//issues/374 which has a ton more possibilities to detect WSL.

WyriHaximus added a commit to WyriHaximus/php-test-utilities that referenced this issue Mar 3, 2021

Detect WSL and only use more then 1 thread when NOT on WSL

cec682a

Based on microsoft/WSL#4555 via https://github .com//issues/374 which has a ton more possibilities to detect WSL.

WyriHaximus mentioned this issue Mar 3, 2021

Detect WSL and only use more then 1 thread when NOT on WSL WyriHaximus/php-test-utilities#390

Merged

WyriHaximus added a commit to WyriHaximus/php-test-utilities that referenced this issue Mar 3, 2021

Detect WSL and only use more then 1 thread when NOT on WSL

dbe06a2

Based on microsoft/WSL#4555 via #374 which has a ton more possibilities to detect WSL.

WyriHaximus added a commit to WyriHaximus/php-test-utilities that referenced this issue Mar 3, 2021

Detect WSL and only use more then 1 thread when NOT on WSL

5a9549a

Based on microsoft/WSL#4555 via #374 which has a ton more possibilities to detect WSL.

haneefdm mentioned this issue May 21, 2021

Add ability to change localhost when starting gdb Marus/cortex-debug#402

Closed

251 mentioned this issue Jun 18, 2021

Test failure for WSL 1 klee/klee#1412

Merged

8 tasks

nandojve mentioned this issue Aug 10, 2021

BOSSAC support on Windows zephyrproject-rtos/zephyr#37538

Closed

malcom2073 mentioned this issue Aug 21, 2021

ServerStartLinux.sh hangs on ping inside of check_connection EnigmaticaModpacks/Enigmatica2Expert#1942

Closed

slonopotamus mentioned this issue Sep 21, 2021

Should we continue supporting building Linux container images under Windows? adamrehn/ue4-docker#205

Closed

YaSuenag mentioned this issue Nov 18, 2021

8277370: configure script cannot distinguish WSL version openjdk/jdk#6446

Closed

3 tasks

gromgit mentioned this issue Jun 16, 2022

cannot execute binary file: Exec format error Homebrew/brew#13432

Closed

2 tasks

scottshambaugh mentioned this issue May 1, 2023

Fix broken symlinks for expected images on WSL matplotlib/matplotlib#25792

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How to tell in Linux under WSL if using WSL1 vs WSL2 ? #4555

How to tell in Linux under WSL if using WSL1 vs WSL2 ? #4555

k7aay commented Sep 30, 2019

bytebounder commented Oct 1, 2019 •

edited

Loading

therealkenc commented Oct 1, 2019

Biswa96 commented Oct 1, 2019

therealkenc commented Oct 1, 2019

Biswa96 commented Oct 1, 2019 •

edited

Loading

therealkenc commented Oct 1, 2019 •

edited

Loading

throwable-one commented Oct 8, 2019

therealkenc commented Oct 8, 2019

andyneff commented Mar 24, 2020

levesquejf commented Apr 6, 2020

TuxVinyards commented Jun 22, 2020

vlovich commented Sep 9, 2020 •

edited

Loading

Biswa96 commented Sep 10, 2020

vlovich commented Sep 10, 2020

therealkenc commented Sep 10, 2020

mirabilos commented Sep 28, 2020 •

edited

Loading

therealkenc commented Sep 28, 2020

mirabilos commented Sep 28, 2020

therealkenc commented Sep 28, 2020 •

edited

Loading

mirabilos commented Sep 28, 2020 via email

therealkenc commented Sep 28, 2020

mirabilos commented Sep 28, 2020 via email

t-ru commented Apr 4, 2021 •

edited

Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021 •

edited

Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021

t-ru commented Apr 4, 2021 •

edited

Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021 •

edited

Loading

How to tell in Linux under WSL if using WSL1 vs WSL2 ? #4555

How to tell in Linux under WSL if using WSL1 vs WSL2 ? #4555

Comments

k7aay commented Sep 30, 2019

bytebounder commented Oct 1, 2019 • edited Loading

therealkenc commented Oct 1, 2019

Biswa96 commented Oct 1, 2019

therealkenc commented Oct 1, 2019

Biswa96 commented Oct 1, 2019 • edited Loading

therealkenc commented Oct 1, 2019 • edited Loading

throwable-one commented Oct 8, 2019

therealkenc commented Oct 8, 2019

andyneff commented Mar 24, 2020

levesquejf commented Apr 6, 2020

TuxVinyards commented Jun 22, 2020

vlovich commented Sep 9, 2020 • edited Loading

Biswa96 commented Sep 10, 2020

vlovich commented Sep 10, 2020

therealkenc commented Sep 10, 2020

mirabilos commented Sep 28, 2020 • edited Loading

therealkenc commented Sep 28, 2020

mirabilos commented Sep 28, 2020

therealkenc commented Sep 28, 2020 • edited Loading

mirabilos commented Sep 28, 2020 via email

therealkenc commented Sep 28, 2020

mirabilos commented Sep 28, 2020 via email

t-ru commented Apr 4, 2021 • edited Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021 • edited Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021

t-ru commented Apr 4, 2021 • edited Loading

mirabilos commented Apr 4, 2021 via email

t-ru commented Apr 4, 2021 • edited Loading

bytebounder commented Oct 1, 2019 •

edited

Loading

Biswa96 commented Oct 1, 2019 •

edited

Loading

therealkenc commented Oct 1, 2019 •

edited

Loading

vlovich commented Sep 9, 2020 •

edited

Loading

mirabilos commented Sep 28, 2020 •

edited

Loading

therealkenc commented Sep 28, 2020 •

edited

Loading

t-ru commented Apr 4, 2021 •

edited

Loading

t-ru commented Apr 4, 2021 •

edited

Loading

t-ru commented Apr 4, 2021 •

edited

Loading

t-ru commented Apr 4, 2021 •

edited

Loading