Rancher Desktop V 1.7.0 fails to start on Windows 11

[markarnott]

Actual Behavior

Install rancher desktop with Rancher.Desktop.Setup.1.7.0.msi.
Launch Rancher Desktop.
Nothing appears to happen.

Steps to Reproduce

I did some troubleshooting and looked at the log files. There appears to be a problem with an existing WSL distribution that was already installed on my machine.

I would like to configure rancher desktop to ignore that distribution.

Result

When I run Rancher Desktop from a terminal window I see the following

PS C:\Program Files\Rancher Desktop>
(node:6768) UnhandledPromiseRejectionWarning: Error: C:\WINDOWS\system32\wsl.exe exited with code 1
at ChildProcess. (C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:1:7721)
at ChildProcess.emit (node:events:390:28)
at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
(Use Rancher Desktop --trace-warnings ... to show where the warning was created)
(node:6768) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
background.log
integrations.log
wsl-helper.chrome.log
update.log
server.log
k8s.log
dashboardServer.log

Expected Behavior

Rancher Desktop GUI opens up and informs me that it had issues opening existing WSL distributions.

Additional Information

No response

Rancher Desktop Version

1.7.0

Rancher Desktop K8s Version

latest

Which container engine are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 Pro 22H2 OS Build 22621.1105

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

No response

[markarnott]

The WSL distribution named 'chrome' appears to be experiencing this issue:
microsoft/WSL#9252

[gunamata]

@markarnott , Can you try launching Rancher Desktop after unregistering (wsl --unregister <DistroName>) the WSL distro you are suspecting to be causing problems?

Please note that, unregistering a distro will delete all the files, settings and configurations of that distro, so please make sure you don't need them anymore before unregistering.

[markarnott]

@gunamata Once I removed the WSL distribution named 'chrome' from my machine, Rancher Desktop starts up with no issues.

I guess this is a feature request more than a bug report. I would like a way to tell Rancher Desktop to ignore specific WSL instances running on my machine.

[gunamata]

Oh, Ok. Thank you @markarnott . I will change the label to enhancement so that we look into this when we plan upcoming releases.

[markarnott]

The other concern is the way this issue presented itself. I installed rancher desktop and when I launched it, I got no feedback at all. I only knew how to find the logs and do some troubleshooting on my own because I have Rancher Desktop running on another machine.

Arguably the underlying issues is not RDs fault, but if I was a new RD user, I would have been totally confused.

[gunamata]

@markarnott , I need your help in reproducing the issue. I tried searching on the internet on how to install this chrome distro but couldn't find any quick info. Can you please share the steps to reproduce the issue please?

[markarnott]

This is going to be hard to reproduce. You won't find a WSL chrome distribution anywhere. That is a clone of the Ubuntu 20.04 Microsoft store distribution that I was doing some testing with the chrome browser. I still have the .vhdx file from that instance and I brought it back to life.

The way to reproduce this issue with Rancher Desktop is to get any WSL distribution to throw an error on startup.

The particular error that I am experiencing seems to be caused by upgrading WSL from the Windows OS version to the Microsoft store version (V 1.0.x). Several people are experiencing the problem (See WSL issue 9252 linked in the second comment) but I don't see that anyone knows how to reproduce it.

[jandubois]

Can't we figure out which wsl calls we are making while enumerating all available distros, and putting them into proper try/catch blocks. Wouldn't that be enough to ignore distros that throw an error?

[markarnott]

@gunamata I agree with @jandubois.
Putting a try catch/block around your startup scripts and then ignoring distributions that throw errors is the best approach.

I have figured out how to reproduce this error.

1. Upgrade to the Microsoft store WSL. The command wsl --version should indicate version 1.0.x
2. install an ubuntu distribution from the Microsoft store. (I had ubuntu 20.04, but I think 22.04 will have the same behavior)
3. add (or edit) /etc/wsl.config with the following:
   [automount]
   enabled = false

[interop]
enabled = false
appendWindowsPath = false

4. exit your WSL instance and restart it. You should see WSL (8) ERROR: CreateProcessParseCommon
5. exit your WSL instance.
6. Launch Rancher Desktop and then examine the log files.

[gunamata]

Thanks @markarnott for the sharing the repro steps. yes, I agree with @jandubois that adding try/catch block can be a good solution to handle this.

[manuel-fernandez-rodriguez]

Apparently, I have been struck by the same problem.

I was unable to install v1.7.0 properly until I unregistered my Ubuntu-20.04 distro.

The most prominent symptom are:

• An error popup at app start up, related to Kubernetes (which, btw, I chose not to install)
• No distro or distro-data folders were created under [...]\AppData\Local\rancher-desktop folder.

Hence, any command on the distro failed with a message similar to Failed to attach disk.

Seems to be a pretty concerning issue, since I am sure I am not the only one with an Ubuntu distro installed who is gonna try to install Rancher Desktop.

@markarnott As a side note, my wsl configuration did not have any of the settings you mentioned.

It was (and is, after succesfully installing Rancher Desktop) the following:

[wsl2]
memory=4GB
swap=16GB
localhostForwarding=true
guiApplications=false

I am pretty sure the last line is irrelevant, since I put it there trying to solve this issue, but it made no difference during the previous gazillions of failed attempts at installing Rancher Desktop. I haven't omitted it because I can't be 100% positive.

[rogerlga]

I was having trouble to first start RD. After reading this topic I managed to start it by unregistering a distro. This particular distro had /etc/wsl.config similar to what @markarnott presented in his comment #3785 (comment).

Can't we figure out which wsl calls we are making while enumerating all available distros, and putting them into proper try/catch blocks. Wouldn't that be enough to ignore distros that throw an error?

This would address the issue. Any plans to implement it?

[geertvanheusden]

I am running into the same issue while using this distro: https://github.com/sakai135/wsl-vpnkit .
A fix to address this would be really appreciated!

[markarnott]

@gunamata I have installed WSL version 1.2.5 (the latest preview release).
That version resolves the underlying WSL/Windows issue that caused this problem.

You may close this issue if you want to, or leave it open until you can implement the try/catch recommendation from jandubois

[gunamata]

@markarnott , Thank you very much for the feedback.
I feel it's still a good idea to add the try/catch, so I will leave this open for now.

[jandubois]

I've been able to reproduce #4560 which seems to be the same bug as this issue. It is too late now for 1.10, but I've added it to the 1.11 milestone. Will do the same for this issue, but eventually we should close one of the issues as a duplicate, but right now the threads in both issues contain useful information.

[jandubois]

Will do the same for this issue, but eventually we should close one of the issues as a duplicate

Will close this issue; fix for #4560 is being tested now.