On Thu, Jul 20, 2023 at 6:06 AM Petr Gotthard
<petr.gotth...@advantech.cz> wrote:
>
> > -----Original Message-----
> > From: Bruce Ashfield <bruce.ashfi...@gmail.com>
> > Sent: Wednesday, July 19, 2023 11:56 PM
> > To: Petr Gotthard <petr.gotth...@advantech.cz>
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION
>
> > >
> > > The kernel is "linux-ti-staging_6.1" with quite standard settings.
> > > Recently I did explicitly set CONFIG_LOCALVERSION_AUTO=n which was "y"
> > > by default. With the default "y" setting I was getting a kernel version 
> > > with two
> > identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2", whereas the make-mod-
> > scripts used "6.1.33-g8f7f371be2").
> >
> > Did that only start happening recently ? because with the localversion_auto 
> > and a
> > set .scmversion, that's what I'd expect to happen (see below).
>
> > I'm curious if on-target module builds work on those boards, since as near 
> > as I can
> > tell the versions won't match (as the .scmversion file isn't captured, so 
> > the
> > vermagic will be different).
>
> The commit 
> https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
> seems to be the cause here.

I already described in detail about how that commit (which is mine),
is not the only cause.  I'm
quite aware of what is happening now. What is currently in place in
those recipes is about to break
and really was only working by a combination of careful dancing
through the fragility.

My question was about CONFIG_LOCALVERSION_AUTO being something that you changed
after the first issue popped up (I understood what it was changing
from your first description)
I can't clearly see if you turned it on in response to the breakage,
but I'm assuming that the
answer is yes.

Cheers,

Bruce

> Before this commit all modules (both out-of-tree and the standard ones) had a 
> version with one suffix ("6.1.33-g8f7f371be2") and could be loaded.
> After this commit:
>  - the standard modules have two suffxes ("6.1.33-g8f7f371be2-g8f7f371be2") 
> and work fine
>  - the out-of-tree modules have a "vermagic" with only one suffix 
> ("vermagic=6.1.33-g8f7f371be2") and fail due to the vermagic mismatch
>
> Setting CONFIG_LOCALVERSION_AUTO=n removes one suffix from everything, so the 
> mismatch for out-of-tree modules remains.
>
>
> Petr
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184636): 
https://lists.openembedded.org/g/openembedded-core/message/184636
Mute This Topic: https://lists.openembedded.org/mt/100240236/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to