Problem with new Docker images and GitLab actions at cl.net

Robert Goldman <[email protected]> Wed, 18 Sep 2024 09:17:24 -0500
Newsgroups gmane.lisp.common-lisp-net.devel
Message-ID <[email protected]>
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/18)the 
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