Bug 3962 - Kernel module packages have a hard coded path to STAGING_KERNEL_DIR in the package install scripts
Summary: Kernel module packages have a hard coded path to STAGING_KERNEL_DIR in the pa...
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: kernel (show other bugs)
Version: 1.4
Hardware: x86 Multiple
: Undecided normal
Target Milestone: ---
Assignee: Mark Hatle
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-02-28 17:53 UTC by Mark Hatle
Modified: 2013-03-02 16:36 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hatle 2013-02-28 17:53:12 UTC 
The kernel module packages (from kernel.bbclass and modules.bbclass) are getting package post install (and remove) scripts that contain a hard coded reference to STAGING_KERNEL_DIR.

This causes depmod failures when installing from an sstate-cache (or package feed).
Comment 1 Mark Hatle 2013-03-01 17:54:53 UTC 
Change has been merged into oe-core:

b18c61bae4d7161c087a004bba3c696006f7a2f6
Comment 2 Martin Jansa 2013-03-02 16:05:14 UTC 
This doesn't work correctly with multiple machines with same architecture:

../sstate-cache/76/sstate-depmodwrapper-cross-cortexa8-vfp-neon-oe-linux-gnueabi-1.0-r0-cortexa8-vfp-neon-3-76f6af3dfee642561bca7b346ed63612_populate-sysroot.tgz
../sstate-cache/76/sstate-depmodwrapper-cross-cortexa8-vfp-neon-oe-linux-gnueabi-1.0-r0-cortexa8-vfp-neon-3-76f6af3dfee642561bca7b346ed63612_populate-sysroot.tgz.siginfo
../sstate-cache/7c/sstate-depmodwrapper-cross-cortexa8-vfp-neon-oe-linux-gnueabi-1.0-r0-cortexa8-vfp-neon-3-7c0a55714df15cf765dd32b67e2c3fbb_populate-sysroot.tgz
../sstate-cache/7c/sstate-depmodwrapper-cross-cortexa8-vfp-neon-oe-linux-gnueabi-1.0-r0-cortexa8-vfp-neon-3-7c0a55714df15cf765dd32b67e2c3fbb_populate-sysroot.tgz.siginfo

It's looking into wrong STAGING_KERNEL_DIR, finds wrong kernel-abiversion and fails.

It needs to be MACHINE_ARCH, because STAGING_KERNEL_DIR is MACHINE specific.