Bug 6767 - kernel version mismatched on some BSPs
Summary: kernel version mismatched on some BSPs
Status: RESOLVED FIXED
Alias: None
Product: Kernel
Classification: Yocto Project Subprojects
Component: linux-yocto (show other bugs)
Version: 1.7
Hardware: x86 Multiple
: Medium minor
Target Milestone: 2.2 M4
Assignee: California Sullivan
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2014-09-26 06:47 UTC by Yi Zhao
Modified: 2016-09-22 21:04 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.