You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the channel server at https://update.k3s.io/v1-release/channel has periodic problems that look like the results of a DoS attack. This could result in issue #7412, which was supposed to be fixed by #7461.
However, it turns out the trigger condition for #7412 was not just the failure of the channel server, but also that the k3s-versions.json file had been removed from the cache directory while the settings.json file remained and had Kubernetes enabled.
After the fix from #7461 this trigger now results in a different error:
I simulate the channel server failure by redirecting the request to a local http server. It seems important that the request returns a 2XX response and not a 404:
I'm temporarily still putting this into the 1.16 milestone, but feel free to move to 1.17 if the fix is non-trivial, as the trigger condition seems rather uncommon,
Run Rancher Desktop normally, enabling Kubernetes (and let it cache k3s)
Edit k3sHelper.ts and change channelApiUrl to https://github.com/rancher-sandbox/rancher-desktop/raw/refs/heads/main/package.json (a valid JSON filed, but not expected contents)
Remove k3s-versions.json
Start Rancher Desktop.
Relevant logs:
k8s.log ─2024-09-19T11:29:00.940-0700: Got K3s update channel data: undefined
kube.log ┌2024-09-19T11:29:00.941-0700: k3sHelper.initialize failed: Error: Channel response does not have correct resource type: undefined
kube.log │ at K3sHelper.updateCache (…/dist/app/background.js:21748:27)
kube.log │ at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
kube.log └ at async …/dist/app/background.js:21853:17
k8s.log ─2024-09-19T11:29:00.941-0700: Error: Channel response does not have correct resource type: undefined
background.log ┌2024-09-19T11:29:00.941-0700: UnhandledRejectionWarning: Error: Channel response does not have correct resource type: undefined
background.log │ at K3sHelper.updateCache (…/dist/app/background.js:21748:27)
background.log │ at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
background.log └ at async …/dist/app/background.js:21853:17
kube.log ─2024-09-19T11:29:22.523-0700: Could not get desired version: Error: Channel response does not have correct resource type: undefined
k8s.log ─2024-09-19T11:29:22.523-0700: Got installed k3s version: 1.30.4+k3s1 (k3s version v1.30.4+k3s1)
background.log ┌2024-09-19T11:29:22.524-0700: Kubernetes was unable to start: Error: Invalid state, no container engine client available.
background.log │ at get containerEngineClient (…/dist/app/background.js:24181:15)
background.log │ at startK8sManager (…/dist/app/background.js:45692:49)
background.log │ at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
background.log │ at async startBackend (/…/dist/app/background.js:45669:9)
background.log └ at async …/dist/app/background.js:45460:9
Currently the channel server at
https://update.k3s.io/v1-release/channel
has periodic problems that look like the results of a DoS attack. This could result in issue #7412, which was supposed to be fixed by #7461.However, it turns out the trigger condition for #7412 was not just the failure of the channel server, but also that the
k3s-versions.json
file had been removed from the cache directory while thesettings.json
file remained and had Kubernetes enabled.After the fix from #7461 this trigger now results in a different error:
I simulate the channel server failure by redirecting the request to a local http server. It seems important that the request returns a 2XX response and not a 404:
The text was updated successfully, but these errors were encountered: