Lsmod / insmod in resinos 2.0

Product support
1

Hi All,

I’ve been adapting the https://github.com/resin-io-playground/kernel-module-build example to compile the kernel module required for an RTL8812 USB WIFI device, (using resin/nuc-debian as base.) Kernel module compilation is working fine, however I’m unable to use any of the standard module tools (insmod, lsmod etc.) Both insmod & lsmod return:

bash: /sbin/lsmod: No such file or directory

insmod rtl8812au_intel-nuc_1.24.0/8812au.ko
bash: /sbin/insmod: No such file or directory

obviously the insmod & lsmod commands are there:

s -al /sbin/lsmod
lrwxrwxrwx 1 root root 9 Sep 27 2014 /sbin/lsmod -> /bin/kmod
root@846ae08-846ae08:/usr/src/app# /bin/kmod
bash: /bin/kmod: No such file or directory
root@846ae08-846ae08:/usr/src/app# ls -al /bin/kmod
-rwxr-xr-x 1 root root 132912 Jun 26 2016 /bin/kmod

This happens both when run from within my Dockerfile, or when run via the terminal. Anyone have any ideas what might be wrong here?

Thanks!

2

As I remember, these sort of things can happen, if kmod is the wrong architecture (I think), I remember coming across something like this as well. The kernel module build processes are not complete yet, so it’s not entirely surprising that it does not work yet, will debug this and get back to you with more info! :bulb:

Could go to the web terminal and run a file /bin/kmod (might need to install file first), and see the output.

3

I tried it out with Resinos 1.24, and got the same problem - which I was quite surprised about.

The architecture doesn’t seem to be the problem, everything looks ok there:

/bin/kmod: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ac37a4a513e991b468915df134442f1d54874be0, stripped

4

Sorry - spoke too soon there. Just compared the output with lsusb - which works:

root@intel-corei7-64-e666724:~# file /usr/bin/lsusb
/usr/bin/lsusb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=177396b8bda08b8b017090c39049a49b3e25091c, stripped

root@intel-corei7-64-e666724:~# ln -s /lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2

And now everything is fine :wink:

5

So to fix the issue, you had to create an extra symlink, you mean? That really should not be necessary, imho, if things are set up correctly, investigating! :mag_right:

6

Just wondered if anyone managed to create a fix for this? Currently we’re still manually creating the symlink.

7

Hey @cmoss. We suspect you might be hitting an ugly issue which is a result of us having kernel modules compressed on the HostOS and the docker container running debian with an old version of kmod that can’t deal with the decompressing of them. To work around this we bind mounted the hostOS kmod into the container if it was a Debian container. So I think this might be wreaking havoc with the linker.

There are probably two things you can try for this. One. Try using an Alpine base image instead of debian, the alpine images have a more recent kmod I am told and dont suffer from this. Two. You can wait until we release resin.io beta.8 (hopefully at the start of next week) this version reverts the kernel module compression and removes the ugly kmod bind mount, so should just work.

Let me know if neither of these solutions work for you and I’ll see if there are other ideas out there :slight_smile:

8

I’d noticed beta.8 turned up for the NUC image last week, so we’ll give that a try. For now the symlink hack is actually working fine, and doesn’t seem to have any negative side effects, so it’s not super urgent.

I’ll let you know as soon as we’ve tried with beta.8

Thanks!

1 Like