James Kingdon Posted October 14, 2017 Share Posted October 14, 2017 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! Link to comment Share on other sites More sharing options...
Igor Posted October 14, 2017 Share Posted October 14, 2017 Are you using your own config file? Link to comment Share on other sites More sharing options...
James Kingdon Posted October 14, 2017 Author Share Posted October 14, 2017 Hi Igor, I'm not specifying a config file, so I believe it's picking up the default .config Link to comment Share on other sites More sharing options...
Igor Posted October 14, 2017 Share Posted October 14, 2017 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. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted October 14, 2017 Share Posted October 14, 2017 AFAIK you need to set the LOCALVERSION too (on the command line) to make the new modversion compatible with the old one. Link to comment Share on other sites More sharing options...
James Kingdon Posted October 14, 2017 Author Share Posted October 14, 2017 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. Link to comment Share on other sites More sharing options...
James Kingdon Posted October 14, 2017 Author Share Posted October 14, 2017 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. Link to comment Share on other sites More sharing options...
martinayotte Posted October 15, 2017 Share Posted October 15, 2017 5 hours ago, James Kingdon said: I suspect if I hadn't done that, things might have worked fine Exactly ! ... Link to comment Share on other sites More sharing options...
Recommended Posts