Bug 6767

Summary: kernel version mismatched on some BSPs
Product: [Yocto Project Subprojects] Kernel Reporter: Yi Zhao <yi.zhao>
Component: linux-yoctoAssignee: California Sullivan <california.l.sullivan>
Status: RESOLVED FIXED QA Contact:
Severity: minor    
Priority: Medium CC: alexandru.c.georgescu, dvhart, ke.zou, richard.purdie, sgw, zhangle.yang
Version: 1.7   
Target Milestone: 2.2 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Yi Zhao 2014-09-26 06:47:10 UTC 
Image location: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.rc1/machines/
Git rev: master: 8ac8eca2e3bd8c78e2b31ea974930ed0243258a3

The kernel file in autobuilder directory shows the kernel version is 3.14.19. But the "uname -a " shows the real version is 3.14.17.

For example:
#################
kernel file for mpc8315e-rdb on autobuilder: 

http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.rc1/machines/mpc8315e-rdb/uImage--3.14.19+git0+0bd3ec19b6_a6b4507afe-r0-mpc8315e-rdb-20140924023740.bin

"uname -a":
Linux mpc8315e-rdb 3.14.17-yocto-standard #1 PREEMPT Wed Sep 24 02:52:35 UTC 2014 ppc GNU/Linux
####################

This issue exists on mpc8315e-rdb, edgerouter, and beaglebone.
Comment 1 Bruce Ashfield 2014-09-26 12:13:28 UTC 
We've had this bug before, and I've mentioned before .. that we don't
need a bug.

Yes. I update the oe-core kernel version, and then the h/w BSPs are
updated later. There's a lag between the two. I don't typically
update the reference BSPs myself, so there's a window like this.

It doesn't hurt anything, so there's no concern.

I'll take this one, but note my response for the future.
Comment 2 Richard Purdie 2014-10-02 14:46:51 UTC 
The concern here is that the modules file that is generated says its "3.14.19" when its actually "3.14.17" due to the way the kernel versioning works.

This could lead to confusion where for example someone looks at the package name and assumes security fixes are applied based on the version when in fact they were not.

In the 1.8 timeframe we need to ensure the correct version gets injected into things like the kernel file name and the modules tarball name for that reason, its not 1.7 material though. I'd suggest we keep this bug open to get this fixed.
Comment 3 Bruce Ashfield 2015-01-27 16:12:19 UTC 
I'll address this when the new 3.19+ kernel comes out.
Comment 4 Bruce Ashfield 2016-03-21 23:21:36 UTC 
This hasn't caused us any issues in the 2.1 cycle, so I'm moving it to 2.2 M2 where I can test it with the introduction of a new versioned kernel.
Comment 5 Richard Purdie 2016-07-25 21:00:46 UTC 
To resolve this we need a sanity check that the kernel version matches the version from the recipe. If they mismatch we need an error, not a quiet failure which could for example have security implications.