1.12.0 fails to start after install

[MHacker9404]

Actual Behavior

RD fails to start after install - just spins on updating certificates

Steps to Reproduce

Win11 Pro with WSL2 latest version
Install RD 1.12.0 with AllUsers
Reboot host
Start RD

Result

nothing

Expected Behavior

RD runs

Additional Information

No response

Rancher Desktop Version

1.12.0

Rancher Desktop K8s Version

0

Which container engine are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

11 Pro 22H2 22621 .3007

What CPU architecture are you using?

x64

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

None

Windows User Only

BitDefender anti-virus

[MHacker9404]

networking-ca.log
dashboardServer.log
k8s.log
background.log
networking.log

[mook-as]

networking-ca.log says:

unexpected fault address 0x230de7af210
fatal error: fault
[signal 0xc0000005 code=0x0 addr=0x230de7af210 pc=0xad3bba]

goroutine 1 [running]:
runtime.throw({0x1021937?, 0x40?})
	C:/hostedtoolcache/windows/go/1.21.5/x64/src/runtime/panic.go:1077 +0x65 fp=0xc00058f9d0 sp=0xc00058f9a0 pc=0xa5afe5
runtime.sigpanic()
	C:/hostedtoolcache/windows/go/1.21.5/x64/src/runtime/signal_windows.go:377 +0xd0 fp=0xc00058fa18 sp=0xc00058f9d0 pc=0xa6eef0
encoding/base64.(*Encoding).Encode(0xc0000c78c0?, {0xc0000c2db8?, 0x400?, 0x400?}, {0x230de7af210?, 0x480?, 0x15ad1a0?})
	C:/hostedtoolcache/windows/go/1.21.5/x64/src/encoding/base64/base64.go:156 +0x7a fp=0xc00058fa38 sp=0xc00058fa18 pc=0xad3bba
encoding/base64.(*encoder).Write(0xc0000c2d80, {0x230de7aef10?, 0x11?, 0x1021c21?})
	C:/hostedtoolcache/windows/go/1.21.5/x64/src/encoding/base64/base64.go:241 +0x10f fp=0xc00058fab8 sp=0xc00058fa38 pc=0xad400f
encoding/pem.Encode({0x120b6e0?, 0xc00010c020}, 0xc00058fce0)
	C:/hostedtoolcache/windows/go/1.21.5/x64/src/encoding/pem/pem.go:292 +0x357 fp=0xc00058fc70 sp=0xc00058fab8 pc=0xae2557

That's https://github.com/golang/go/blob/go1.21.5/src/encoding/base64/base64.go#L156 which probably means src is invalid.

rancher-desktop/src/go/wsl-helper/cmd/certificates_windows.go

Line 54 in de85021

err = pem.Encode(os.Stdout, block)

block is probably invalid, then?
It basically comes from

rancher-desktop/src/go/wsl-helper/pkg/certificates/certificates_windows.go

Line 77 in de85021

cert, err := x509.ParseCertificate(unsafe.Slice(certCtx.EncodedCert, certCtx.Length))

We may need to take a copy of that slice; since we're passing it over a channel it's possible that x509.ParseCertificate isn't making copies as I expected.

[fm-knopfler]

There might be different behaviour when running RD as admin vs non-admin.

The following appears in background.log when running as common user:

2024-01-11T09:01:36.123Z: Background process Vtunnel Host Process (pid 9924) exited with status 1 signal null
2024-01-11T09:01:37.234Z: Launching background process Vtunnel Host Process.
2024-01-11T09:01:43.134Z: Background process Win32 socket proxy (pid 1376) exited with status 1 signal null
2024-01-11T09:01:44.147Z: Launching background process Win32 socket proxy.
2024-01-11T09:01:48.729Z: Background process Vtunnel Host Process (pid 24820) exited with status 1 signal null

When launching as admin, it gets stuck on ca certificates.

In my case, running it as admin, quitting RD and start it as a normal user does the trick. Just launching as a non-privileged user in the first place doesn't work, see above.

[MHacker9404]

That worked the 1st time - but this morning when I started RD - it's just spinning on installing CA certificates

vtunnel-host.log
wsl-init.log
dashboardServer.log
host-resolver-host.log
k8s.log
update.log
diagnostics.log
settings.log
wsl-exec.log
networking-ca.log
background.log
server.log
shortcuts.log
wsl.log
integrations.log

[MHacker9404]

so that may have been the networking tunnel - turning that on now spinning on updating kubeconfig

wsl-exec.log
k3s.log
shortcuts.log
background.log
wsl.log
wsl-init.log
diagnostics.log
host-switch.log
dashboardServer.log
integrations.log
k8s.log
update.log
server.log
settings.log

[jandubois]

This has been fixed in #6308 and will be included in a 1.12.1 patch release.