search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.46k stars 822 forks source link

docker-desktop-data isn't a Linux distro (?) so it should not be settable as a default distro by wsl2 #8727

Closed therobyouknow closed 1 week ago

therobyouknow commented 2 years ago

Version

Microsoft Windows [Version 10.0.22000.856]

WSL Version

Kernel Version

5.10.102.1

Distro Version

No response

Other Software

No response

Repro Steps

wsl -l

Expected Behavior

docker-desktop-data to not be selected as the default distro.

The default distro setting could be overlooked as a root cause by folks troubleshooting other things as to why their set up isn't working properly. Please help folks out by ensuring that wsl2 can't select something that is not a distro as the default.

Reference: https://github.com/microsoft/WSL/issues/5923#issuecomment-1215454084

In that reference above, we found that =setting the default distro to a real distro like Ubuntu resolved errors such as:

Actual Behavior

docker-desktop-data selected as the default distro.

PS > wsl -l
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
Ubuntu
docker-desktop

docker-desktop-data is not a distro, right? So please ensure WSL2 can't select it.

Diagnostic Logs

No response

Biswa96 commented 2 years ago

docker-desktop-data is not a distro, right? So please ensure WSL2 can't select it.

WSL itself can/should not block a distribution name, what if any user set that distro name explicitly. The issue should be solved by Docker developers.

therobyouknow commented 2 years ago

docker-desktop-data is not a distro, right? So please ensure WSL2 can't select it.

WSL itself can/should not block a distribution name, what if any user set that distro name explicitly. The issue should be solved by Docker developers.

The distro itself should identify it as a distro -e.g. as a flag somewhere, not by just the name.

Or WSL should inspect the each item in the listing of wsl -l to determine whether it is a distro. Inspect by looking at files inside the distro, headers etc. And not list anything that is not found to be a distro following those checks. Or list them separately under a different heading as non-distros and not make them selectable as the default.

NotTheDr01ds commented 2 years ago

@therobyouknow

I do agree that it is not a very user-friendly experience when docker-desktop-data erroneously gets set as the default distribution. And this does tend to happen "automatically" for several reasons (and probably more than I can think):

While these sound like corner-cases, I've seen this come up quite frequently in Stack Exchange questions, as well as (as you mention) issue reports here.

While WSL could solve this by hardcoding the docker-desktop and docker-desktop-data distributions as ones never to set as default automatically (unless explicitly requested by user wsl --set-default ...), I agree with @Biswa96 that this would be a kind of hacky approach.

I also don't think that WSL can or should "define" a distribution as one that is bootable. It doesn't know until it attempts to run it. Non-bootable WSL distributions happen quite frequently as well, especially for those of us who are building our own. It could even be deliberate -- Perhaps a user wants a "data-only" distribution like docker-desktop-data.

I think I'd propose a different feature that might solve this:

At some point, hopefully, Docker could shift to using this new feature, and rename to .docker-desktop and .docker-desktop-data.

This seems to me to be a non-breaking change. Docker could even install its distributions with leading dots on older WSL versions without the "hidden" feature. They wouldn't be hidden on the older WSL versions, but they would eventually after a WSL upgrade.

NotTheDr01ds commented 2 years ago

Alternative that doesn't fix the issue, but it would be nice to have some more helpful error text around this situation.

If wsl is run without a -d/--distribution flag, and the instance fails to boot (i.e. Create process not expected to return), then it might be nice to provide some error help like:

The default distribution (docker-desktop-data) failed to boot.
You can set another installed distribution as default with:
    wsl --set-default <distribution name>

You have the following distributions installed:

<insert results of wsl -l here>

... of course, substituting the actual failed/default distribution in place of docker-desktop-data above, if it differs.

OneBlue commented 2 years ago

This is interesting issue. I think having a flag saying "This distro is not meant for interactive usage" is the best way forward.

It could be something that docker would specifically pass to wsl --import / wsl --register when they install the distro, and when an interactive distro is installed for the first time, this flag could be checked to see if the new distro should be set as default or not.

Any thoughts on that @benhillis / @craigloewen-msft ?

NotTheDr01ds commented 2 years ago

@OneBlue Interesting. I'm kind of surprised you'd pick a flag (which I assume would imply a registry entry?) over a naming convention (leading-dot). The hidden/leading-dot convention just seems so much more "Linuxy" ;-).

Would you list "not for interactive use" distributions with wsl -l? Or only use it to determine if a distro should be a candidate for automatic "set as default" behavior?

OneBlue commented 2 years ago

Thinking about this again, a new command line argument to wsl --import / --register wouldn't be a good option, because that wouldn't be backwards compatible.

The best option I can think of would be adding a new argument to either wsl or wslconfig. Something like:

wsl --set-distro-hidden <name> <true|false>

That way tools like docker can call wsl --register / wsl --import, and then wsl --set-distro-hidden, and ignore if wsl --set-distro-hidden fails in older WSL versions.

The '.' prefix would work, but I don't like it as much because it would mean that any user that has a distro with that prefix would see this distro suddenly disappear after a package upgrade, which could be confusing.

NotTheDr01ds commented 2 years ago

@OneBlue

I do like your --set-distro-hidden option better. That makes everything you could do with a leading-dot possible anyway. The --import flag was, IMHO, too limiting. And, as you say, not backwards-compatible.

Minor suggestion: Just --set-hidden distroname. This more closely aligns with the naming of other arguments, like --set-version (vs. --set-distro-version). And of course, --set-hidden distroname false?

it would mean that any user that has a distro with that prefix would see this distro suddenly disappear after a package upgrade, which could be confusing

Agreed, I did consider this. But it seemed like such a rare-to-nonexistent corner-case, and easily explainable/recoverable, that it was acceptable to me. But regardless, I'm totally good with --set-hidden (or --set-distro-hidden, if you must 😉).

scanyard commented 1 year ago

Just hit this; I couldn't figure out why launching from wsl.exe was suddenly complaining about fstab parsing failures, but they are indeed gone after replacing docker-desktop-data as default distro. The ability to set hidden would be nice, and maybe docker desktop would even use it in their installer.

microsoft-github-policy-service[bot] commented 1 week ago

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!