-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, August 29, 2017 7:11 AM
To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
<hernan_gutier...@hp.com>; linux-yocto@yoctoproject.org
Subject: Re: [linux-yocto] Kernel modules and vermagic
On 08/28/2017 06:46 PM, Gutierrez, Hernan Ildefonso (Boise R&D, FW)
wrote:
Hi,
I am new to this dist-list and I am not sure if this is the right forum.
My apologies beforehand if this is not the right list.
This one is as good as any for this question.
Problem statement:
I am evaluating Yocto for a project. We have a workflow where linux
kernel is built from a local git repo separately from the root file system.
I made a recipe to build rootfs using yocto to our target, I deployed
both images (Kernel built from our git repo + rootfs generated by
Yocto) ... all this works great.
Now I want to add a couple of kernel modules provided by a third party
vendor. If the module is built along with our kernel build system (and
deployed to target), they work fine.
Is there a way to build kernel modules with Yocto and point them to
the includes of our git kernel repo just to satisfy the kernel dependencies?
Investigate setting your kernel up as an externalsrc recipe. In that workflow
you setup/configure your kernel as you normally do and have a recipe that
points the build system at the source (local to the build machine). The build
system won't configure or otherwise modify your kernel tree, but will use it as
the kernel provider.
As such the modules, etc, will build against the artifacts from that kernel
build
and everything will match.
In attempts to explore options, I made a yocto kernel recipe to build
a kernel from our internal git repo.
I made also yocto recipes to build the kernel modules which resolve
dependencies for kernel header files with above yocto kernel recipes.
So I'm clear, in this configuration you have a standard format kernel recipe
that is building your kernel tree (fetched from your repo) and then the
modules are built as they normally would (i.e. the build system takes care of
everything).
But you are actually deploying the kernel image from another build that
you've done (i.e. your existing workflow).
All above builds fine, I can deploy the rootfs which includes the .ko
files I need, I even ask yocto to autoinitialize the modules on boot.
Rootfs fails to load the modules like this:
[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.
When I try to insmod the module manually it fails with a vermagic
error like this:
# insmod hello-mod.ko
hello: version magic *'4.9.13_1.0.0_hgv+g68f8dea22b* SMP
preempt mod_unload ARMv7 p2v8 ' should be '4.9.13 SMP preempt
mod_unload ARMv7
p2v8 '
insmod ERROR: could not insert module hello.ko: Invalid module
format
I've read enough and it seems like this is because the kernel image
deployed generated with our separate workflow has a uname as *4.9.13*
and it seems like yocto adds the string _*1.0.0_hgv+g68f8dea22b* to
the vermagic... of the kernel modules, which seems to come from the
kernel recipe I generated to satisfy the dependencies to build the module.
Correct.
You could jump through some hoops to force the build system to not modify
the version string. Alternatively, you could turn off modversions checking in
your kernel build.
But in the end, either of those could cause you issues down the road since we
are circumventing a check that is there to save subtle issues that could creep
into the kernel -> modules interfaces.
I want to know if there is a way to keep building our kernel
separately from the root file system and kernel modules with yocto.
Have a closer look at externalsrc, it may help here.
Bruce
This is just because our workflows are separate for the project we're
working on. If we build the kernel with yocto, the internal workflows
will change and we are evaluating the options we have.
Thanks, I'll appreciate any help and if this is not the right
dist-list, please let me know where it's best to get help.
--Hernan
