I create an image where I copied an executable, it is successfully copied and with executable rights, but the systems said that there is not such a file. Here are the results on the ssh connection to the container:
root@5112b28ea77b:/usr/src# ls -la
total 708
drwxr-xr-x 2 root root 4096 May 13 14:34 .
drwxr-xr-x 38 root root 4096 Mar 26 12:00 ..
-rwxrwxr-x 1 root root 708460 May 13 14:24 cbox_stereo_armhf_rpi
-rwxrwxr-x 1 root root 1897 May 13 14:24 extrinsics.xml
-rwxrwxr-x 1 root root 1119 May 13 14:24 intrinsics.xml
root@5112b28ea77b:/usr/src# pwd
/usr/src
root@5112b28ea77b:/usr/src# sudo ./cbox_stereo_armhf_rpi
sudo: unable to execute ./cbox_stereo_armhf_rpi: No such file or directory
Does anyone know why the system says that there is no such a file if the file is there and “ready to be” executed?
Is cbox_stereo_armhf_rpi a binary? Does it have library dependencies? If so, how was it linked to its dependencies (i.e. static or dynamically linked)? If it was dynamically linked have you installed its dependencies?
yes, it is a binary and it is dynamically linked.
I have installed there dependencies like this in the docker template:
RUN apt-get update &&
apt-get install -yq
libusb-1.0-0-dev
libudev-dev
freeglut3-dev
libqt4-dev
v4l-utils
&& apt-get clean && rm -rf /var/lib/apt/lists/*
ADD src/cbox_stereo_armhf_rpi /usr/src/cbox_stereo_armhf_rpi
RUN chmod +x /usr/src/cbox_stereo_armhf_rpi
COPY src/extrinsics.xml /usr/src/extrinsics.xml
COPY src/intrinsics.xml /usr/src/intrinsics.xml
RUN chmod +x /usr/src/extrinsics.xml
RUN chmod +x /usr/src/intrinsics.xml
#switch on systemd init system in container
ENV INITSYSTEM on
#Run our binary on container startup
CMD ["/usr/src/cbox_stereo_armhf_rpi"]
Hi,
I’d recommend spinning up a container on your computer and trying to get the binary to work.
e.g. docker run --rm -i -t balenalib/raspberrypi3-debian /bin/bash
The error ‘File not found’ is usually a symptom of either the wrong architecture, or a library is dynamically linked that it can’t seem to find.
You can run file cbox_stereo_armhf_rpi to check arch and the ld path it is searching for.
And LD_DEBUG=libs ./cbox_stereo_armhf_rpi for more debug info.
Thanks
ZubairLK
I’m new in Docker technology so, I explain my exec context. 1) I compiled it in a RASPIAN OS and then use it to put it inside the Docker image using the Docker file that I add before. 2) When I run ldd cbox_stereo_armhf_rpi In the Raspi where I compiled the bin, it shows me all the dynamically linked libraries. When I run the same command in the Docker Image where I copied the executable, it tells me:
root@0bab67f95306:/usr/src# ldd cbox_stereo_armhf_rpi
not a dynamic executable
Do I have to compile the executable inside a Docker image?
@zubairlk I tried running your command of the container in my computer, but I got this:
Status: Downloaded newer image for balenalib/raspberrypi3-Debian:latest
standard_init_linux.go:207: exec user process caused "exec format error"
When I run the commands you told me inside the docker image the are not found neither. When I run it in the Raspi where I compiled the program, i got this:
file cbox_stereo_armhf
cbox_stereo_armhf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=58a29a15087c0c6f8e9bd99f50763a2032c25383, not stripped
@zubairlk Do you know what I’m doing wrong? Do you mean to run these commands where?
Can you give a try compiling it as the docker build step (that is, adding the compilation instructions to the Dockerfile? That’s the usual way of doing it, so the resulting binary will be applicable for the base image. What base image are you using, by the way, and what Raspberry Pi type? (Pi1/Zero/2/3?)
For the exec, sorry, that was an incorrect call, that’s an ARM image, and won’t run on your non-ARM laptop without modifications. The right way ahead is like as above, putting the compilation step in the build.
Let us know if you need any help with that, and if so, would be good if you could share your project with us to take a look!
1 Like
@imrehg I compiled inside using a build machine as I found in a compiling example and it worked. However, Do you know what happened with this Docker image? It is deleted after?
Now it seems to be working after some restart, but not immediately after the updated. It is also normal?
Here the example in case someone will have the same need in the future:
Create the compiling Docker image with building libraries
FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-node:10-stretch-run AS build
to compile you should install build-essential and I also use CMAKE
RUN apt-get update &&
apt-get install -yq
python
libusb-1.0-0-dev
libudev-dev
libqt4-dev
libopencv-dev
v4l-utils
build-essential
cmake
&& apt-get clean && rm -rf /var/lib/apt/lists/*
Switch into our apps working directory
WORKDIR /usr/src/app/build
Copy all the app source code into docker context
COPY countingsystem/ /usr/src/app/
compile the app using cmake
RUN cmake …
RUN make
change from Docker image, same base image but without extra compiling packages
FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-node:10-stretch-run
Bring the binary from the compiling base image
COPY --from=build /usr/src/app/bin/cbox_stereo_armhf /usr/src/app/cbox_stereo_armhf
install the required libraries (same as in the compiling base image)
RUN apt-get update &&
apt-get install -yq
python
libusb-1.0-0-dev
libudev-dev
libqt4-dev
libopencv-dev
v4l-utils
&& apt-get clean && rm -rf /var/lib/apt/lists/*
switch on systemd init system in container
ENV INITSYSTEM on
Run our binary on container startup with arguments
CMD [“/usr/src/app/cbox_stereo_armhf”,“-c”,“localhost”,“-gui”,“usb”,“-h”,“1800”]
@imrehg as I’m new in this, please correct my comments in case I’m using the wrong term, please?
Sorry, could you please elaborate more your questions? Are you referring to multistage builds?
@thundron here I hope to be more clear:
To solve this issue I create a temporal Docker Image where I compile my program and then I create another image where I copied the binary and run it. This final image is the one that keeps running. My first question is: what happens to this temporal image?. I ask because I also notice that the update size increased is size to the double, so I would like to know technically what happened with the temporal image called Build.
My second question was after I did this changes and I updated the testing device, the sale docker file was not running. I decided to restart physically and after that, the application was running without problems. IS this behavior normal? I would need to restart the devices in prod after I make an update to make it work?
the last one if the docker template I share is valid for you, please make sure my comments are right, I can change it for the correct terms in case I made a mistake.
Hello, regarding the first question: yes the temporal image (usually called build image in this context) will be discarded at the end of the compilation, the only files that are persisted are the ones you explicitly copy to the new one COPY --from=build /usr/src/app/bin/cbox_stereo_armhf /usr/src/app/cbox_stereo_armhf have a look at https://docs.docker.com/develop/develop-images/multistage-build/ for more information about this docker feature.
1 Like
Sorry, pressed send too early 
The Dockerfile looks good, I didn’t test it but every section lines up with your comments. There should be no need to physically restart the device though, is there any chance you can test this with a trivial change in the Dockerfile and see if this happens again? If you still experience this issue, we might need to dig further into this, if you don’t mind sharing the device UUID and enabling support access that should allow us to gather more information about the problem.