https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
q
Restarting it again triggered the update available prompt
But, of course, when they restarted to upgrade, it crashed with some message that's pretty painful.... The context is "Updating outdated virtual machine"
Looks like there's a line that says 
sudoers file ... is out of sync and must be regenerated
but I can't tell if that's relevant
restarting it again yielded an admin acess required prompt... but ideally this would not have been the upgrade sequence...
f
I don't think it is related, but unless you kept the original logs, it is probably no longer possible to figure out what triggered the problem
q
how do i to the logs from the ui?
oh, right, found it
i really wish it zipped the old logs each time it started and left them around for a while
they're tiny and fairly cheap on average
f
In general I would recommend not to use admin mode unless you really need an external IP address for the VM, or the docker socket in the 
/var/run
location. Everything else should work withoutit.
q
right
we tried that
it broke differently 🙂
so, now we're at that breakage
ok, current breakage is 
unknown field "vdeSwitch"
f
Is that an error and not just a warning?
You should be able to get rid of the warning by removing the entry from 
~/Library/Application\ Support/rancher-desktop/lima/_config/networks.yaml
q
can't tell? something's pissed
something's still pissed 🙂
f
But it should just be a warning from the YAML parser that the key is no longer used
q
passwordLessSudo failed
f
That should be fine as long as the sudoers file has been updated
q
Copy code
stderr: 'time="2025-01-29T15:00:25-05:00" level=info msg="Using the existing instance \\"0\\""\n' +
    'time="2025-01-29T15:00:25-05:00" level=info msg="Stopping socket_vmnet daemon for \\"rancher-desktop-shared\\" network"\n' +
    'time="2025-01-29T15:00:25-05:00" level=fatal msg="passwordLessSudo error: failed to run [sudo --user root --group wheel --non-interactive true]: exit status 1"\n',
f
So something failed to create the sudoers file.
q
why would it want one? we told it we don't want to use sudo...
f
then it should need it; are you sure you disabled admin mode?
q
definitely not sure
certain i tried to
btw, i hate that the error is 
kubernetes error
, for the record, we have kubernetes disabled in rancher
f
I know; it is the hard-coded title of the generic error dialog 😞
q
Yeah, I get it, technical debt, but I suffer... and I don't have the time to fix it
so, what logs would be helpful?
or should we use the magic pill of enabling admin access, or should we reset rancher -- we definitely don't need any of the data in it
f
If you don't need to keep the data, then do a factory reset and see if that fixes it
q
done
note: I can never remember if i need to start it after hitting the factory reset button
f
BTW, recent changes in gvisor-tap-vsock created lots of DNS/VPN related issues; they just reverted all their refactoring. So if you run into DNS problems, maybe go back to a previous version and wait until this is all sorted out.
We did revert gvisor-tap-vsock for the Windows version, but unfortunately not for macOS, because it didn't have the obvious symptoms. But it has problems with local resolvers, or split DNS and similar
q
We were on 1.15.1 and the kuberlr wasn't compatible w/ our k8s instance, so we needed to upgrade long enough for it to download the newer kubectl -- it did that, we could probably downgrade... This is macOS, and i think part of the problem is that there are still some sudo processes left over that non sudo rancher can't kill:
Copy code
ps aux|grep -i rancher
root             18760   0.0  0.0 410806352   5040   ??  S     2:51pm   0:00.12 /opt/rancher-desktop/bin/socket_vmnet --pidfile=/private/var/run/rancher-desktop-bridged_en0_socket_vmnet.pid --socket-group=everyone --vmnet-mode=bridged --vmnet-interface=en0 /private/var/run/socket_vmnet.rancher-desktop-bridged_en0
root             18757   0.0  0.0 410325424   9216   ??  S     2:51pm   0:00.01 sudo --user root --group wheel --non-interactive /opt/rancher-desktop/bin/socket_vmnet --pidfile=/private/var/run/rancher-desktop-bridged_en0_socket_vmnet.pid --socket-group=everyone --vmnet-mode=bridged --vmnet-interface=en0 /private/var/run/socket_vmnet.rancher-desktop-bridged_en0
root             18755   0.0  0.0 410802720   4560   ??  S     2:51pm   0:00.01 /opt/rancher-desktop/bin/socket_vmnet --pidfile=/private/var/run/rancher-desktop-shared_socket_vmnet.pid --socket-group=everyone --vmnet-mode=shared --vmnet-gateway=192.168.205.1 --vmnet-dhcp-end=192.168.205.254 --vmnet-mask=255.255.255.0 /private/var/run/socket_vmnet.rancher-desktop-shared
root             18753   0.0  0.0 410332592   9152   ??  S     2:51pm   0:00.01 sudo --user root --group wheel --non-interactive /opt/rancher-desktop/bin/socket_vmnet --pidfile=/private/var/run/rancher-desktop-shared_socket_vmnet.pid --socket-group=everyone --vmnet-mode=shared --vmnet-gateway=192.168.205.1 --vmnet-dhcp-end=192.168.205.254 --vmnet-mask=255.255.255.0 /private/var/run/socket_vmnet.rancher-desktop-shared
should i shoot them?
f
Yeah, or do a reboot... 😄
q
killed
my guess is you need a mode where you ask for sudo to kill those processes even though you won't be using sudo going forward
anyway, having killed those processes, rancher started and we now appear to have a happy docker
f
Ok, good. You should normally not be in a situation where the processes are running, but you don't have either a working sudoers file, or passwordless sudo enabled. Because you can't start them without it.
q
i should have asked the processes which version of rancher they came from before i shot them 😞
the processes were started recently, but it could have been the 1.15.1 processes i suppose
15 Views
Open in Slack
PreviousNext
Powered by