snapd is intentionally broken under WSL and shouldn't be

[Alistair Young]

This commit:

https://github.com/snapcore/snapd/commit/1adae138ee8c489f959a29fc0ee349d697409bfb

causes the snap command to refuse to run on WSL.

I'm a little confused by why I'm bringing this up now, since it's a 2018 commit, but evidently it's only just surfaced, at least in my Debian installation.

This is something of a problem for all those of us who have been running snapd successfully on WSL up to now (either by using the previous method of running systemd in a pid 1 "bottle" or using the brand new systemd support under WSL, which renders the rationale for this change moot), obviously.

It also causes the rather unusual situation in which we are unable to manage snaps (without the snap command), but snaps which we had previously installed continue to work fine - just can't be removed or updated.

Please remove this check.

[Alistair Young (cerebrate)]

This appears to be fixed in the PR https://github.com/snapcore/snapd/pull/12179 . If and when that's merged, please close this bug.

[Edu Gómez Escandell (edugomez)]

Thanks for the report.

This bug was hidden by another bug which made WSL2 detection fail until this PR was merged https://github.com/snapcore/snapd/pull/12135/files. Seems like two wrongs made a right.

As you observed, PR https://github.com/snapcore/snapd/pull/12179 will fix this, and only disable snap on WSL1 as was originally intended.

[Edu Gómez Escandell (edugomez)]

The fix has reached 22.04. See https://github.com/ubuntu/WSL/issues/299#issuecomment-1291650396.

[Edu Gómez Escandell (edugomez)]

The fix has reached all but 22.10 by now. See link above.