Hi,

 

If I build my kernel 'properly' using the armbian compile.sh script with docker, everything works fine. If I run the docker image interactively, go into /armbian-cache/_data/sources/linux-pine64/my-hacks-1.2 and do

export PATH=/root/armbian/cache/toolchains/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/:$PATH

make ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-" -j8 $*

I get a kernel that seem to work in every way, except it won't load any modules. The 'normal' build uses modules in /lib/modules/3.10.107-pine64. The non-compliant kernel reports uname -r of 3.10.107+. I tried copying the existing /lib/modules/3.10.107-pine64 to /lib/modules/3.10.107+ and running depmod, but it doesn't seem to have helped.

Can anyone point me in the right direction to fix this? While running the whole compile.sh process makes sense for a final build, while I'm hacking on the device driver it's a lot quicker to just recompile inside an interactive docker process than it is to generate new patch files and create a new docker image.

 

Thanks for any help!

Are you using your own config file?

Hi Igor,

I'm not specifying a config file, so I believe it's picking up the default .config

OK, it's not the most obvious problem. Try to recreate some other kernel (bananapi legacy for example) to see if the same problem manifests there to narrow down the nature of the problem. Just peek into resulting deb file.

AFAIK you need to set the LOCALVERSION too (on the command line) to make the new modversion compatible with the old one.

Hmm, I just found something about vermagic strings embedded in the module .ko files. It seems my understanding of how modules work is very naive. I think I'll try using a different LOCALVERSION post fix and creating a matching set of kernel and modules and see if that works.

ok, that worked (compiling a matching set of kernel + modules with a new LOCALVERSION so that I could tell them apart from everything else, and packaging as a deb).

 

Looking at the vermagic strings, it looks like I threw myself off by setting a kernel config option for module versions before I took Zador's advice of using LOCALVERSION to make the uname -r strings match. I suspect if I hadn't done that, things might have worked fine, but I have a tendency to thrash around trying things out and generally getting myself into trouble.

 

5 hours ago, James Kingdon said:

I suspect if I hadn't done that, things might have worked fine

Exactly ! ...