[linux-yocto] Kernel modules and vermagic

[Bruce Ashfield]

On 2018-01-02 2:02 PM, Gutierrez, Hernan Ildefonso (Boise R&D, FW) wrote:
> Hi Bruce,
> 
> I sent the note below back in August and you nicely point me to the external source recipe workflow. Just before the Dec break, I ran into this nice tutorial from the yocto project which covers the topic in detail.
> 
> https://www.yoctoproject.org/sites/default/files/kernel-lab-1.5.pdf
> 
> This doc is a bit dated but great information in it!
> Are you (or anybody aware) if there is a more recent version of this doc compared to more recent yocto branches?
> Is information basically mostly applicable to more recent yocto branch versions?

The basic information is still valid. The scripts referenced in the
tutorials about creating recipes and BSPs are no longer maintained,
but any of the manual layer and recipe manipulation sections and
steps are still valid.

I don't know of a really recent version, since the folks that used
to work on that lab are no longer active in the project.

Bruce

> 
> Thanks,
> 
> --Hernan
> 
> 
> 
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
>> Sent: Tuesday, August 29, 2017 7:11 AM
>> To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
>> <hernan_gutierrez at hp.com>; linux-yocto at 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
>>>
>>>
>>>
>