I am wondering if I can use Docker for cross compilation for SDK according to my toolchain. It involves use of kernel files like linux-header--generic.
I ran the cross compilation with all its dependencies (toolchain), but when the kernel modules are involved, my cross compilation fails saying Module.symvers not found!!.
I came to know that docker container for ubuntu distrinution does not come with these kernel headers but can be installed by running apt-get install linux-headers-$(uname -r) -y in the dockerfile. Butstill I am getting the same error Module.symvers not found!!. Even though it is clearly present in some header files inside /usr/src/ folder.
Please note I performed the same compilation with same modules on Ubuntu host of same version and same make version, the compilation happens without any hinderance but in docker container it fails with above mentioned message. Please help.
I am using ubuntu 18.04 image. All the dependencies and toolchain are uploaded in docker container. I am running a shell script entrypoint.sh file to source the environment variables since RUN command opens up a new instance of shell so environment variables will be lost. The environmental variable file contain some export statements, some if-else, for loop block. After sourcing that file in entrypoint.sh through ENTRYPOINT cmd, Iâm running CMD the actual compilation of make. I dont know what am I missing.
Each RUN instruction will run in a separate container, the result will be an image layer that persists file system changes. Neither processes, nor variables survive after a RUN instruction is finished.
This is the right approach. The ENTRYPOINT instruction defines the script/binary to start, and CMD will be the argument to it. Please share your Dockerfile and entrypoint script.
This canât be right. Even though if you install the files that make up the kernel, the kernel wonât be used. Also linux-headers-$(uname -r) will relate to the hostâs kernel, no to the containers kernel.
There is no such thing as kernel in the container, since it is not a separate system. It doesnât need a kernel, it already has, the kernel of the host. It is just that the communication between the container and the host is limited. But sometimes processes in the container want to send system calls to the kernel. Then you need to allow the required kernel capabilities or run the container in privileged mode. It wasnât always possible during the build process, and I never needed it, but there are some flags for buildx which is the default builder now.
In your case the problem could be that something just checks if the module is available. The kernel header files are not the modules. As far as I know, those are just some api interfaces to communicate with the kernel. So if ou need the modules, you need to mount /lib/modules/${kernel_version} from the host.
I did it only once, when I needed to run virt-builder (to build VM images) in a Docker container because of some compatibility issues.
I also remember that once I had to install the header files, but I donât remember why and if it had to include the OS version, but I guess I didnât, because I didnât use the hwe kernel. In case of a container Iâm not sure which one I would need to define, the version of the container distro or the host.
There is a differente between a volume and a bind mount. I meant bind mounting the host folder which you could do in a Dockerfile too.
I forgot to add to my previous post, that it is also possible that what you want is just not meant to run a container.
I could mount the kernel modules, because I just ran the container on a server and mounted the folder in runtime. Building an image should never depend on a specific host, because you could move the image to another host and it would just not work. So you can try it, and you should try it just to see if it works, but I wouldnât recommend it if you want to share the image.