`4.20.0` bundle fails in first start on macOS and fails on linux in restart scenario

[lilyLuLiu]

Platform: macOS

Steps:

1. crc setup
2. crc start
3. crc stop
4. crc start => fail

Error message:

INFO Using bundle path crc_vfkit_4.20.0_arm64.crcbundle
INFO Checking if running macOS version >= 13.x
INFO Checking if running as non-root
INFO Checking if crc-admin-helper executable is cached
INFO Checking if running on a supported CPU architecture
INFO Checking if crc executable symlink exists
INFO Checking minimum RAM requirements
INFO Check if Podman binary exists in: /Users/podmanqe/.crc/bin/oc
INFO Checking if running emulated on Apple silicon
INFO Checking if vfkit is installed
INFO Checking if old launchd config for tray and/or daemon exists
INFO Checking if crc daemon plist file is present and loaded
INFO Checking SSH port availability
INFO Loading bundle: crc_vfkit_4.20.0_arm64...
INFO Starting CRC VM for openshift 4.20.0...
INFO CRC instance is running with IP 127.0.0.1
INFO CRC VM is running
INFO Updating authorized keys...
INFO Configuring shared directories
INFO Check internal and public DNS query...
INFO Check DNS query from host...
INFO Verifying validity of the kubelet certificates...
INFO Starting kubelet service
INFO Waiting for kube-apiserver availability... [takes around 2min]
ERRO Error waiting for apiserver: Temporary error: ssh command error:
command : timeout 5s oc get nodes --context admin --cluster crc --kubeconfig /opt/kubeconfig
err : Process exited with status 1
(x221)

[anjannath]

It fails with the following error:

level=debug msg="Running SSH command: timeout 5s oc get nodes --context admin --cluster crc --kubeconfig /opt/kubeconfig"
level=debug msg="SSH command results: err: Process exited with status 1, output: "
level=debug msg="Error in configuration: context was not found for specified context: admin\n"
level=debug msg="error: Temporary error: ssh command error:\ncommand : timeout 5s oc get nodes --context admin --cluster crc --kubeconfig /opt/kubeconfig\nerr     : Process exited with status 1\n - sleeping 1s"

which is caused by the ocp-cluster-ca.service running when using the bundle with crc (ideally it shouldn't run when using the bundle with crc or should be no-op if it runs)

After SSH into the machine the following command work:

[core@crc ~]$ oc get nodes --context system:admin --cluster crc --kubeconfig /opt/kubeconfig
NAME   STATUS   ROLES                         AGE     VERSION
crc    Ready    control-plane,master,worker   6d18h   v1.33.5

# but fails for the following:
[core@crc ~]$ oc get nodes --context admin --cluster crc --kubeconfig /opt/kubeconfig
Error in configuration: context was not found for specified context: admin

This is happening because the crc-self-sufficient-env.sh script thinks the bundle is running is self sufficient mode:

Oct 28 08:20:05 crc crc-self-sufficient-env.sh[13306]: /usr/local/bin/crc-self-sufficient-env.sh: line 7: /etc/sysconfig/crc-env: No such file or directory
Oct 28 08:20:05 crc crc-self-sufficient-env.sh[13306]: WARNING: crc-env not found
Oct 28 08:20:06 crc crc-self-sufficient-env.sh[13308]: Looking up the CID in /dev/vsock...
Oct 28 08:20:06 crc crc-self-sufficient-env.sh[13308]: Our vsock CID is 3.
Oct 28 08:20:06 crc crc-self-sufficient-env.sh[13308]: No remote host on vsock://2:1024 (Connection reset by peer)
Oct 28 08:20:06 crc crc-self-sufficient-env.sh[13306]: vsock/1024 not working, running with a self-sufficient bundle

[LightGuard]

This may be what I was seeing on my personal mac (M2-Pro running macOS 26) as well. I tried both from CLI and through podman desktop.

[gbraad]

@anjannath you said this has a workaround by using the override?

[anjannath]

@anjannath you said this has a workaround by using the override?

No, we need to generate new bundles, 4.20.1 will have the fix

the workaround user's can attempt would be to create a file in /etc/sysconfig/crc-env inside the VM with content CRC_SELF_SUFFICIENT=0 after the first boot

but there's another issue with the /opt/kubecofig there the context is not what crc expects, so they have to manually update the default context name from admin to system:admin!

[praveenkumar]

#1182 is what fix it and it is now part of 4.20.1 bundle