On Openshift, pods in CrashLoopBackOff due to timeout getting SR image

[opstalj]

Hi,
I am trying to deploy clabernetes on Openshift (4.16.9).
The manager got deployed nicely and now I am using clabverter to deploy a clab.

I faced some issue with privileged access, so I do upfront:

1. create clab namespace (in my case: c9s-sros-sros)
2. give full privileged access (oc adm policy add-scc-to-user privileged -z clabernetes-launcher-service-account -n c9s-sros-sros)

I have a harbor repo server and have uploaded the Nokia SR-OS image there.
However, whatever I tried to get the pod to download the image, it always failed and then it goes into CrashLoopBackOff.
Typical log that I see:

    INFO |              containerlab | time="2025-09-19T06:14:00Z" level=info msg="Pulling harbor.antwerplab.com/sr-images/nokia_srsim:25.7.R1 Docker image"

    INFO |              containerlab | Error: Error response from daemon: Get "https://harbor.antwerplab.com/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I have tried many other things as well:

1. download the image onto the worker node where my srsim pod will land:

oc adm policy [root@worker20 run]# crictl image |grep nokia
harbor.antwerplab.com/sr-images/nokia_srsim 25.7.R1 8c69dafa63f8d 1.98GB

-> same issue as before

2. tagged the image and renamed it as a local image on the worker node (and adapted the clab topology file accordingly):

[root@worker20 run]# crictl image |grep nokia
harbor.antwerplab.com/sr-images/nokia_srsim                                                       25.7.R1             8c69dafa63f8d       1.98GB
localhost/nokia_srsim                                                                             25.7.R1             8c69dafa63f8d       1.98GB

-> same issue as before

3. I thought maybe an imagePullSecret was needed and tried that as well ... no luck.
   Now, the crictl pull on the worker node worked without secret ... so I guess this is not needed...

Any idea what I can try next?

Note: this is also strange: I could not use the kind 'nokia_srsim':

INFO | containerlab | Error: error constructing node "srsim10": kind "nokia_srsim" is not supported. Supported kinds are "arista_ceos, arista_veos, aruba_aoscx, bridge, c8000, ceos, checkpoint_cloudguard, cisco_c8000, cisco_c8000v, cisco_cat9kv, cisco_csr1000v, cisco_ftdv, cisco_iol, cisco_n9kv, cisco_xrd, cisco_xrv, cisco_xrv9k, crpd, cumulus_cvx, cvx, dell_ftosv, dell_sonic, ext-container, fortinet_fortigate, freebsd, generic_vm, host, huawei_vrp, ipinfusion_ocnos, juniper_crpd, juniper_vjunosevolved, juniper_vjunosrouter, juniper_vjunosswitch, juniper_vmx, juniper_vqfx, juniper_vsrx, k8s-kind, keysight_ixia-c-one, linux, mikrotik_ros, nokia_srlinux, nokia_sros, openbsd, ovs-bridge, paloalto_panos, rare, sonic-vm, sonic-vs, srl, vr-aoscx, vr-arista_veos, vr-aruba_aoscx, vr-cisco_csr1000v, vr-cisco_n9kv, vr-cisco_xrv, vr-cisco_xrv9k, vr-csr, vr-dell_ftosv, vr-ftosv, vr-juniper_vmx, vr-juniper_vqfx, vr-juniper_vsrx, vr-mikrotik_ros, vr-n9kv, vr-nokia_sros, vr-paloalto_panos, vr-pan, vr-ros, vr-sros, vr-veos, vr-vmx, vr-vqfx, vr-vsrx, vr-xrv, vr-xrv9k, xrd"

-> so I am using the kind = nokia_sros instead of nokia_srsim in my clab topology file

Kind regards,

Jan

Oh, the pod logs show this version of ContainerLab:

INFO | containerlab | time="2025-09-19T06:13:59Z" level=info msg="Containerlab v0.64.0 started"

[hellt]

the easiest way to check the pull procedure is to open a shell in the launcher pod and do docker pull <image> you will see what it tries to do.
Since the pod in essence runs a docker-in-docker, your pull procedure would rely on docker's config

Yes, the c9s currently is pinned to an older version, you can set it to 0.69.3 via global config https://artifacthub.io/packages/helm/clabernetes/clabernetes?modal=values&path=globalConfig.deployment.containerlabVersion to play with nokia_srsim

[opstalj]

Hi,

Thanks for your fast reply :).

1. What do you mean with the launcher pod? I was watching the pod creation when I started the deployment, but only see:

# oc get pods -n c9s-sros-sros NAME READY STATUS RESTARTS AGE srsim10-866f8c8d76-qm2bc 0/1 CrashLoopBackOff 3 (32s ago) 90s srsim11-7f6b7b6d89-ssfzf 0/1 CrashLoopBackOff 3 (41s ago) 90s

-> these pods are in RUNNING state for a short while ... should I exec into 1 of these pods and then try the docker pull here?

2. In the meanwhile, I can already try to use version 0.69.3., can I do that with a helm upgrade, like:

helm upgrade --install clabernetes oci://ghcr.io/srl-labs/clabernetes/clabernetes --version=0.69.3 ?

Thanks once more.

[hellt]

you can use alpine:3 as a node in your topology to have the launcher pod not going into the crashloop, then you k exec into it and try docker pull for the image you need to pull to see whats going on

[opstalj]

Ah, could this warning be the show stopper:

    INFO |               clabernetes | image pull through mode "auto", start image pull through attempt...
    WARN |               clabernetes | error creating image manager, err: errLaunch: unknown criKind, cannot create image manager
    WARN |               clabernetes | image pull through mode is auto, but criKind is not set or unknown, continuing to normal launch...

On my Openshift, I am not using containerd, but cri-o as container runtime.
Should I use the 'criSockOverride' option?

[opstalj]

Note: I pointed to the 0.69.3 version as follows:

clabverter --stdout --naming non-prefixed --containerlabVersion 0.69.3 | oc apply -f -

[opstalj]

hi,

Any idea what is meant with: criKind?

" WARN | clabernetes | error creating image manager, err: errLaunch: unknown criKind, cannot create image manager"

and in the env variables of the pod:

LAUNCHER_CRI_KIND=unknown

Now, I am using Openshift where the cri sock is to be set to '/var/run/crio/crio.sock', so I added this in my values file:

globalConfig:
imagePull:
imagePullThroughMode: auto
criSockOverride: "/var/run/crio/crio.sock"

but it did not make a change ... The pods keep complaining about a timeout when trying to pull the image.
Even loading the image into the local worknode and pointing the image variable to 'localhost/...' did not help.

Hope I can get some help here.
Regs,

Jan

[hellt]

image pull through only supports containerd socket. Nothing else. If you don't have containerd you won't be able to use the pull through functionality and you will need to set it to disabled and make sure your launcher pods can pull the image from the registry instead of them trying to pull it from the worker node

[opstalj]

So I did:

clabverter --stdout --naming non-prefixed --topoSpecFile values.yaml | oc apply -f -

where my values file contains:

globalConfig:
imagePull:
imagePullThroughMode: never

but it seems that the values file gets ignored?
(the Topology does not contain the imagePullThroughMode: never)

Is there another way to disable the imagePullThroughMode?