1

I want to make some weird container, one of my tasks were to replace the uname binary.
I coded it:

#include <stdio.h>
int main() {
   printf("This is a fake uname\n");
   return 0;
}  

Compiled it:

gcc uname.c -o uname

it works fine when I run it on my ubuntu.

I created a Dockerfile and copied it to the image:

cat > Dockerfile <<EOF
FROM alpine:latest
RUN rm /bin/uname
COPY uname /bin/
ENTRYPOINT sh;
WORKDIR /home
EOF  

And build it docker build -t myimage -f Dockerfile .

when I run the image:

docker run -it --rm myimage  

The file exist but when I try to run it, it writes it doesn't exist:

/home # uname
sh: uname: not found
/home # ls -lia uname
ls: uname: No such file or directory
/home # ls -lia /bin/uname
     35 -rwxr-xr-x    1 root     root          8600 Jan 29 13:27 /bin/uname
5

The problem is that you build your binary against glibc (as you are using Ubuntu), but then run it on Alpine (which uses musl instead).

When you build the binary, some metadata is hardcoded into it, specifically, the interpreter (dynamic linker) location. During the binary execution the kernel uses this interpreter to load the binary and all of its runtime dependencies. When you build against glibc, the binary requests the glibc's interpreter (something like /lib64/ld-linux-x86-64.so.2):

$ readelf -l /bin/uname
<...>
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

but there is no such interpreter under Alpine. Alpine has /lib/ld-musl-x86_64.so.1 instead, and all its binaries are built so that they request exactly this interpreter:

# readelf -l /bin/busybox
<...>
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]

So, when you build your uname in Ubuntu and then run it in Alpine, the kernel is unable to find the interpreter, thus it returns "not found".

The interesting point is that you may invoke the interpreter manually and this may work if the problem is only in the interpreter:

# /lib/ld-musl-x86_64.so.1 /bin/uname 
This is a fake uname

But this, of course, is only for troubleshooting.

So, what to do?

Your options are either statically link your binary (thus making the interpreter and all shared libraries unneeded so that the kernel may load and run the binary on its own):

gcc uname.c -static -o uname

or build it under Alpine (maybe try Docker's multistage builds? I would recommend this approach as in this case you explicitly declare your intention and show that you build your custom binary in Alpine to replace the original Alpine's one).

  • The -static solved it. Thanks you for your informative answer ! – E235 Jan 29 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.