10845 2016-12-22 14:35:43 +0000 test-image: compile and load a kernel module under the qemu-lsb image is failing 2017-01-11 16:30:43 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-runtime 2.3 x86 Multiple RESOLVED NOTABUG Medium normal 2.3 M3 1 jose.perez.carranza bruce.ashfield randy.macleod yp.kernel.watcher yp.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 69313 0 jose.perez.carranza 2016-12-22 14:35:43 +0000 STATUS: FAILED BUILD: 2.3_M1_rc1: 573c646d4cc62dcd0c230381df4940bdf314d495 ENVIRONMENT: qemux86_64-lsb Image: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-64-lsb/core-image-lsb-sdk-qemux86-64.ext4 STEPS TO REPRODUCE: THIS IS A COPY OF TC 316 AND IS REPORTED WITH THAT ID ON TESTIMAGE 1.Create a QEMU(x86 or x86-64) core-image-sato-sdk image. 2.Run 'make scripts' in /usr/src/kernel 3. cd /home/root and create hello.c with the following content: #undef __KERNEL__ #define __KERNEL__ #undef MODULE #define MODULE #include <linux/module.h> #include <linux/kernel.h> #include <linux/init.h> static int __init hello_init(void) { printk(KERN_INFO "Hello world!\n"); return 0; } static void __exit hello_cleanup(void) { printk(KERN_INFO "Cleaning up module.\n"); } module_init(hello_init); module_exit(hello_cleanup); 4. Create a Makefile with the following content and run 'make' obj-m := hello.o KDIR := /usr/src/kernel PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean 5. Run insmod hello.ko 6.After the module is compiled and loaded, check that it is present by running "lsmod" command and dmesg | grep -i hello EXPECTED OUTCOME: The module could be properly loaded ACTUAL OUTCOME: Traceback (most recent call last): File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 109, in wrapped_f return func(*args, **kwargs) File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 97, in wrapped_f return f(*args, **kwargs) File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/utils/decorators.py", line 97, in wrapped_f return f(*args, **kwargs) File "/home/jgperezc/Yocto/poky-2.3-lsb/meta/lib/oeqa/runtime/kernelmodule.py", line 31, in test_kernel_module self.assertEqual(status, 0, msg="\n".join([cmd, output])) AssertionError: 1 != 0 : cd /tmp && insmod hellomod.ko insmod: ERROR: could not insert module hellomod.ko: Invalid module format 69674 1 bruce.ashfield 2017-01-10 20:37:38 +0000 This is likely modversions kicking in. Can you check to see if the kernel build has MODVERSIONS enabled ? Also, what does dmesg log when the module load fails ? It could also be an invalid entry point, but something should be dumped in those cases. 69682 2 jose.perez.carranza 2017-01-10 21:29:39 +0000 Checking on file /proc/config.gz is giving: # CONFIG_MODVERSIONS is not set ---- The image kernel is giving: $uname -r kernel 4.8.12-yocto-standard ---- and dmesg is giving the following: [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt mod_unload PENTIUMM ' 69683 3 bruce.ashfield 2017-01-10 21:31:27 +0000 (In reply to comment #2) > Checking on file /proc/config.gz is giving: > # CONFIG_MODVERSIONS is not set > > ---- > > The image kernel is giving: > $uname -r > kernel 4.8.12-yocto-standard > > ---- > and dmesg is giving the following: > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt > mod_unload PENTIUMM ' aha. so it is a version skew. The running kernel is different from the SDK one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK is fixed ? or vice versa ? 69684 4 jose.perez.carranza 2017-01-10 21:36:56 +0000 (In reply to comment #3) > (In reply to comment #2) > > Checking on file /proc/config.gz is giving: > > # CONFIG_MODVERSIONS is not set > > > > ---- > > > > The image kernel is giving: > > $uname -r > > kernel 4.8.12-yocto-standard > > > > ---- > > and dmesg is giving the following: > > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt > > mod_unload PENTIUMM ' > > aha. so it is a version skew. The running kernel is different from the SDK > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK > is fixed ? or vice versa ? I'm not building the images, I'm using the ones uploaded to the public AB http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-lsb/ is there a way to check this directly on the image booted? 69717 5 bruce.ashfield 2017-01-11 15:19:04 +0000 (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Checking on file /proc/config.gz is giving: > > > # CONFIG_MODVERSIONS is not set > > > > > > ---- > > > > > > The image kernel is giving: > > > $uname -r > > > kernel 4.8.12-yocto-standard > > > > > > ---- > > > and dmesg is giving the following: > > > > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt > > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt > > > mod_unload PENTIUMM ' > > > > aha. so it is a version skew. The running kernel is different from the SDK > > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK > > is fixed ? or vice versa ? > > I'm not building the images, I'm using the ones uploaded to the public AB > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/ > qemu/qemux86-lsb/ is there a way to check this directly on the image booted? Not really. But you can check the captured kernel source in the SDK and note the version from the Makefile. The system is working as expected by refusing to load the version mismatched kernel module and running kernel. Not knowing how the kernel you are booting is associated to the SDK you are downloading I can't say exactly why they are different. Do you know where both are coming from ? Can we confirm they are from the same build / build artifacts ? 69719 6 jose.perez.carranza 2017-01-11 16:13:11 +0000 (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > Checking on file /proc/config.gz is giving: > > > > # CONFIG_MODVERSIONS is not set > > > > > > > > ---- > > > > > > > > The image kernel is giving: > > > > $uname -r > > > > kernel 4.8.12-yocto-standard > > > > > > > > ---- > > > > and dmesg is giving the following: > > > > > > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt > > > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt > > > > mod_unload PENTIUMM ' > > > > > > aha. so it is a version skew. The running kernel is different from the SDK > > > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK > > > is fixed ? or vice versa ? > > > > I'm not building the images, I'm using the ones uploaded to the public AB > > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/ > > qemu/qemux86-lsb/ is there a way to check this directly on the image booted? > > Not really. But you can check the captured kernel source in the SDK and note > the version from the Makefile. > > The system is working as expected by refusing to load the version mismatched > kernel module and running kernel. > > Not knowing how the kernel you are booting is associated to the SDK you are > downloading I can't say exactly why they are different. > > Do you know where both are coming from ? Can we confirm they are from the > same build / build artifacts ? I saw that there are 2 kenles uploade to the AB, I do a test with both and below are the results : http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/qemu/qemux86-lsb/ - bzImage--4.1.36+git0+44719fa8f7_fec4924781-r0.2-qemux86-20161216115813.bin: running with this one the test PASS - bzImage-qemux86.bin : running with this one the test FAIL 69720 7 jose.perez.carranza 2017-01-11 16:30:43 +0000 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > (In reply to comment #2) > > > > > Checking on file /proc/config.gz is giving: > > > > > # CONFIG_MODVERSIONS is not set > > > > > > > > > > ---- > > > > > > > > > > The image kernel is giving: > > > > > $uname -r > > > > > kernel 4.8.12-yocto-standard > > > > > > > > > > ---- > > > > > and dmesg is giving the following: > > > > > > > > > > [ 2337.132062] hello: version magic '4.1.36-yocto-standard SMP preempt > > > > > mod_unload PENTIUMM ' should be '4.8.12-yocto-standard SMP preempt > > > > > mod_unload PENTIUMM ' > > > > > > > > aha. so it is a version skew. The running kernel is different from the SDK > > > > one. Is one build using AUTOREV ? i.e. the image one is AUTOREV but the SDK > > > > is fixed ? or vice versa ? > > > > > > I'm not building the images, I'm using the ones uploaded to the public AB > > > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/ > > > qemu/qemux86-lsb/ is there a way to check this directly on the image booted? > > > > Not really. But you can check the captured kernel source in the SDK and note > > the version from the Makefile. > > > > The system is working as expected by refusing to load the version mismatched > > kernel module and running kernel. > > > > Not knowing how the kernel you are booting is associated to the SDK you are > > downloading I can't say exactly why they are different. > > > > Do you know where both are coming from ? Can we confirm they are from the > > same build / build artifacts ? > > I saw that there are 2 kenles uploade to the AB, I do a test with both and > below are the results : > > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M1.rc1/machines/ > qemu/qemux86-lsb/ > > - > bzImage--4.1.36+git0+44719fa8f7_fec4924781-r0.2-qemux86-20161216115813.bin: > running with this one the test PASS > > - bzImage-qemux86.bin : running with this one the test FAIL Seems like there were a mistake on the link for Artifacts download script.. I downloaded correct artifacts and tested again with both Kernels an d the error is not appearing anymore. Will close this as not a bug