insmod: ERROR: could not insert module ./generic_raw_uart.ko: Invalid module format

[mschlenstedt]

Hallo Alex,

vielleicht kannst Du mir weiterhelfen - ich verzweifel noch :-) Du erinnerst Dich vielleicht an unser LoxBerry/LoxMatic Projekt, wo ich große Teile aus Deinem Git-Repo und aus RaspberryMatic verwende.

Ich habe hier ein Debian Buster, bei dem der Kernel mit "rpi-update" aktualisiert wurde. Passend dazu habe ich mit "rpi-source" auch die Kernel-Sourcen entsprechend zum Kernel aktualisiert.

Die Kernelmodule kompilieren auch alle durch, aber beim Laden bekomme ich ein "Invalid module format".

Kernel ist:

root@loxberry:/opt/piVCCU/kernel# uname -a
Linux loxberry 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

Dazu passende Quellen:

root@loxberry:~/linux# make kernelversion
4.19.75

Ein modinfo sagt, dass alles in Ordnung ist (aus meiner Sicht :-)):

root@loxberry:/opt/piVCCU/kernel# modinfo generic_raw_uart.ko
filename:       /opt/piVCCU/kernel/generic_raw_uart.ko
author:         Alexander Reinert <alex@areinert.de>
description:    generic raw uart driver for communication of piVCCU with the HM-MOD-RPI-PCB and RPI-RF-MOD radio modules
version:        1.11
license:        GPL
alias:          platform:generic-raw-uart
srcversion:     4AAA362A6FBA374DF226AD3
depends:
name:           generic_raw_uart
vermagic:       4.19.75-v7l+ SMP mod_unload modversions ARMv7 p2v8
parm:           load_dummy_rx8130_module:Loads the dummy_rx8130 module

Aber das Laden schlägt fehl:

root@loxberry:/opt/piVCCU/kernel# insmod ./generic_raw_uart.ko
insmod: ERROR: could not insert module ./generic_raw_uart.ko: Invalid module format

MIt dem alten 4.14er Kernel habe ich das eigentlich immer so gemacht, und es hat auch immer funktioniert.

Kannst Du mir einen Tipp geben, wo ich noch suchen kann?

[alexreinert]

Ich würde darauf tippen, dass das Modul für eine falsche Architektur gebaut ist, der Raspberry Kernel Source wird ja mittlerweile für 4 Architekturen verwendet.

Aber warum nimmst du nicht einfach die beiden deb Pakete pivccu-modules-dkms und pivccu-modules-raspberrypi?

[mschlenstedt]

Danke für die Antwort! Wir liefern mit dem LoxBerry (ist ein Raspberry) einen bestimmten (neueren) Kernel aus und nicht den Standardkernel aus der Distribution. Daher muss ich die Module immer jeweils passend kompilieren.

Ich hatte die Kernelsourcen vorher mit passender .config (aus /proc/config.gz) entsprechend konfguriert. Die Module scheinen auch für ARM kompiliert zu sein:

loxberry@loxberry:~/opt/piVCCU/kernel $ file generic_raw_uart.ko
generic_raw_uart.ko: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), BuildID[sha1]=286ccdb31e2956ff84cbf08e6c968de976074e0b, not stripped

Oder kann ich das noch anders herausfinden?

Oder könnte das an der verwendeten GCC-Version in Buster liegen? (kenne mich mit C leider so überhaupt nicht aus...):

loxberry@loxberry:~/opt/piVCCU/kernel $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/shar                                                           e/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major                                                           -version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build                                                           -id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --                                                           enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-lib                                                           stdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-suppor                                                           t --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --dis                                                           able-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=re                                                           lease --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1)

[mschlenstedt]

Per dmesg kriege ich noch folgende Meldung beim laden - bringt mich aber auch nicht weiter... :-(

generic_raw_uart: disagrees about version of symbol module_layout

[mschlenstedt]

Hab's gelöst. Entscheidender Hinweis (falls es mal noch jemand braucht...): https://www.raspberrypi.org/forums/viewtopic.php?t=17666#p179845

Für einen Kernel, der per rpi-update aktualisiert wurde bzw. dessen Quellen per rpi-source geholt wurden, muss die passende Module.symvers von hier geholt werden: https://github.com/Hexxeh/rpi-firmware

Zu beachten ist, dass man die richtige Module.symvers herunterladen muss und entsprechend umbenennen muss: Module.symvers, Module7.symvers oder Module7l.symvers

Trotzdem Danke für Deinen Support!

[alexreinert]

Es gibt nicht einfach nur ARM, es gibt verschiedene ARM Architekuren, bei RPi entscheidet der Bootloader, welcher Kernel gestartet wird, je nach Pi ist das dann der mit Suffix +, der mit +v7, der mit +v7l oder der mit +v8. Ich wiederhole aber nochmal meine Frage, warum nicht die fertigen Pakete? Diese nutzen DKMS und kompilieren auf den eigentlichen System für den jeweils aktiven Kernel (sofern die Header verfügbar sind) und das dann auch, wenn der Endnutzer ein Kernel Update durchführt.

BTW: Der Kernel, welcher mit rpi-update installiert wird ist testing/unstable und soll nicht auf produktiven Systemen genutzt werden, so die klare Aussage der RPI Foundation.

[mschlenstedt]

Ist schon klar mit den unterschiedlichen ARM Versionen, deswegen gibt es auch die unterschiedlichen Module.symvers. Früher waren die in den Kernelsourcen enthalten, heute nicht mehr. Das ist das Problem.

DKMS geht nicht, da wir die Kernelheader nicht haben bzw. nur mit den Kernelsourcen bekommen, die mehrere 100MB groß sind.