When trying to run new CL docker images based on Debian bookworm, I'm getting errors like this: ``` Executing "step_script" stage of the job script 00:03 Using docker image sha256:09d35b13e5a86639aa00b12c2f57561e55a6126c78f654df463f3c914e2eff31 for rpgoldman/ccl:latest with digest rpgoldman/ccl@sha256:746098f1e5c7e82a4f1605817af3137a966b50b7d935caeb5b313f7d20841556 ... shell not found ``` Googling reveals [this gitlab discussion](https://forum.gitlab.com/t/jobs-fails-shell-not-found-version-python/88340/1... following, which suggests a possible work-around, but that also contains the following note:

In my case gitlab-runner’s shell detection script was failing to stat the available shell executables due to an incompatibility between the container and the host, thus returning failure for every check and giving up with the “shell not found” error.

This sometimes happens when running bleeding edge images on older hosts, but typically it’s more obvious and often presents itself as a filesystem permissions error or some other system call failure. Essentially, the binaries/libraries in the container are using new/modified system calls that the dockerd/containerd’s seccomp layer doesn’t understand yet. *Updating the host kernel and container runtime tends to fix this.* [italics added]

Is there any chance that the GitLab host needs a refresh? Thanks, R