Can't exec `bash` error on `distroless` image.

[sureshg]

Env

Rander Desktop: 1.7.0
Mac OS: 12.5
cdebug: 0.0.6

I do have a sample container images created out of Google distroless java base and running cdebug on that container gives the following error.

$ docker run -d --platform linux/amd64 --pull always -p 8080:80 --name openjdk-playground --rm ghcr.io/sureshg/containers:openjdk-latest

$ cdebug exec --privileged -it --rm docker://openjdk-playground
Pulling debugger image...
latest: Pulling from library/busybox
Digest: sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c
Status: Image is up to date for busybox:latest
chroot: can't execute 'bash': No such file or directory

Any idea what is missing here? Could this be an issue running on Rancher Desktop ?

[iximiuz]

It's actually a regression introduced by https://github.com/iximiuz/cdebug/commit/6701046f6989ff85e13f5384910735a7ec5b5573. There is no bash in busybox and Alpine-based images. Don't know what I was thinking... Thanks for reporting. Pushing a fix.

For now, you can use the following workaround:

# Notice explicit `sh`
cdebug exec --privileged -it --rm <target> sh

# Alternatively, you can use another toolkit image:
cdebug exec --image nixery.dev/shell --privileged -it --rm <target>

[iximiuz]

Released the fix https://github.com/iximiuz/cdebug/releases/tag/v0.0.7.

[sureshg]

Still having the same issue with the default busybox image

❯ cdebug -v
cdebug version 0.0.7 (built: 2023-01-15T20:28:55Z commit: cda4fa475c560dde244e507c998ebdefe4dce835)

❯ cdebug exec --privileged -it --rm test
Pulling debugger image...
latest: Pulling from library/busybox
Digest: sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c
Status: Image is up to date for busybox:latest
chroot: can't execute 'sh': No such file or directory

❯ cdebug exec --privileged -it --rm  test sh
Pulling debugger image...
latest: Pulling from library/busybox
Digest: sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c
Status: Image is up to date for busybox:latest
chroot: can't execute 'sh': No such file or directory

But things are working fine if we use --image nixery.dev/busybox image.

[iximiuz]

Oh, shoot! It's another bug 🙈 Likely, your target image is amd64 but it looks like you're running cdebug on an arm64 machine (based on the sha256: 7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c digest). So, then cdebug pulls the arm64 version of busybox and tries to execute it in an amd64 container... The sh binary is actually there, but it's of the wrong architecture. Lemme push the fix quickly. Great find!

[iximiuz]

Made another release https://github.com/iximiuz/cdebug/releases/tag/v0.0.8. Ideally, cdebug will detect the platform of the target container automatically. However, it's not always possible to do using just the "standard" means provided by Docker on containerd (at least, to the best of my knowledge). For instance, docker container inspect $(docker run ghcr.io/sureshg/containers:openjdk-latest) doesn't have any platform/architecture information. So, I added an option to provide a manual override.

I'm sure the UX can be streamlined even further (e.g., using a more clever target platform detection), but for now, it's like that:

cdebug exec --privileged -it --rm --platform linux/amd64 test

Thanks for your report and for providing the much-needed debugging info!

[sureshg]

Thanks for the all help. That worked 👍🏼

[sureshg]

Sorry to bother again, i am still having the issue with scratch images

 $ docker run \
         --platform linux/arm64 \
         --pull always \
         -p 8080:80 \
         -it --rm \
         --name test \
         ghcr.io/sureshg/containers:nativeimage-latest

❯ cdebug -v
cdebug version 0.0.10 (built: 2023-01-21T12:05:37Z commit: 2ac0a0d1759acaafa9be070a84a3a1399d6130b0)

❯ cdebug exec \
         --privileged \
         -it \
         --rm \
         --platform linux/arm64 \
         docker://test
Pulling debugger image...
latest: Pulling from library/busybox
Digest: sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c
Status: Image is up to date for busybox:latest
chroot: can't execute 'sh': No such file or directory

Image Layer details to confirm it's a scratch image

Cmp   Size  Command                                  └── httpserver
     27 MB  FROM 5eb9f9215b86686

│ Layer Details ├───────────────────────────────────

Tags:   (unavailable)
Id:     5eb9f9215b866864ed2540070df0dba564662c8ed98b
Digest: sha256:f33829da506caf93372287053dfa3f8830e86
Command:
COPY /app/httpserver / # buildkit

│ Image Details ├───────────────────────────────────

Image name: ghcr.io/sureshg/containers:nativeimage-l
Total Image size: 27 MB
Potential wasted space: 0 B
Image efficiency score: 100 %

[iximiuz]

Great catch! Turns out some busybox images aren't statically linked! Replaced busybox:latest with busybox:musl. Could you try v0.0.11?

[sureshg]

Yeah..busybox:musl works fine. Thanks for the quick fix.

[iximiuz]

Yay! Thanks for helping eliminate all these bugs!