Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Waiting on Kubernetes API on startup #7989

Open
lyngekpdxc opened this issue Dec 20, 2024 · 2 comments · May be fixed by #7995
Open

Waiting on Kubernetes API on startup #7989

lyngekpdxc opened this issue Dec 20, 2024 · 2 comments · May be fixed by #7995
Assignees
@mook-as
Labels
kind/bug Something isn't working platform/windows

Comments

@lyngekpdxc
Copy link

Actual Behavior

New installation won't finish starting up. Stuck on "Waiting on Kubernetes API"

Steps to Reproduce

Install Rancher Desktop
Start Rancher Desktop

Result

Stuck on this state without any further progress. Restarting the application. Uninstall/reinstall does not resolve the issue.

Expected Behavior

Install + Start should properly finish setup and give a working installation.

Additional Information

I have previous to installing Rancher desktop already used WSL with Ubuntu 24.04 with a docker installation. I would think that this should have no effect on Rancher. But perhaps it might be relevant to mention?

Rancher Desktop Version

1.16.0

Rancher Desktop K8s Version

1.30.6

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 Enterprise 23H2

What CPU architecture are you using?

x64

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

None

Windows User Only

Appgade SDP and Ivanti Secure Client. Used for work environment. I have tried disabling both without any change.
@lyngekpdxc lyngekpdxc added the kind/bug Something isn't working label Dec 20, 2024
@lyngekpdxc
Copy link
Author

logs.zip
I have attached logs here

@mook-as
Copy link
Contributor

mook-as commented Dec 20, 2024

wsl.log contains a lot of loops of:

2024-12-20T12:10:56.541Z: Capturing output: wsl.exe --distribution rancher-desktop --exec cat /proc/net/route
2024-12-20T12:10:56.892Z: captureCommand:
command: (cat '/proc/net/route')
output: <Iface  Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT                                                       
eth3    00000000        0101A8C0        0003    0       0       25      00000000        0       0       0                                                                              
docker0 000011AC        00000000        0001    0       0       0       0000FFFF        0       0       0                                                                            
eth3    0001A8C0        00000000        0001    0       0       281     00FFFFFF        0       0       0                                                                             
eth3    0101A8C0        00000000        0005    0       0       25      FFFFFFFF        0       0       0                                                                              
veth-rd-wsl     008FA8C0        00000000        0001    0       0       0       00FFFFFF        0       0       0                                                                        
>

That means it's stuck because the code is failing around

rancher-desktop/pkg/rancher-desktop/backend/wsl.ts

Lines 943 to 949 in 2fab96e

const routesString = await this.captureCommand('cat', '/proc/net/route');
const routes = routesString.split(/\r?\n/).map(line => line.split(/\s+/));
const route = routes.find(route => route[0] === 'eth0' && route[1] !== '00000000');
if (!route) {
return undefined;
}

So the issue seems to be that we're unexpectedly not seeing eth0 (but there's eth3 instead). We may need to fall back to any interface that has a destination of all zeros, but I'd be curious to know about why the interface name is different.

(Having a different distribution with a local dockerd should be no issue; I have that too, just with openSUSE. Also, thanks for uploading the logs!)

@mook-as mook-as linked a pull request Dec 21, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mook-as mook-as

Labels
kind/bug Something isn't working platform/windows
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

WSL: Handle eth0 being renamed mook-as/rd
3 participants
@mook-as @gunamata @lyngekpdxc