Bug 6992 - Incorrect installation rights on external kernel module makes it unloadable
Summary: Incorrect installation rights on external kernel module makes it unloadable
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2014.02
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-27 09:01 UTC by Jean-pierre Cartal
Modified: 2014-05-07 13:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-pierre Cartal 2014-03-27 09:01:38 UTC
Hello,

I'm currently working on a project that needs using external kernel modules.
I added a dedicated package for those to be built and installed.
However I made a mistake in the INSTALL_TARGET_CMDS rule since I asked for those modules to be installed with 0755 access rights in the $(TARGET_DIR)/lib/modules/$(KERNEL_RELEASE)/kernel/drivers/net/wireless/ directory.

Using the access rights above have the unexpected consequence that those modules are stripped using the following command: 
$(STRIP_FIND_CMD) | xargs $(STRIPCMD) 2>/dev/null || true i.e. 
find buildroot/output/target -type f \( -perm /111 -o -name '*.so*' \) -not \( -name 'libpthread*.so*' \) -print | xargs buildroot/output/host/usr/bin/mipsel-buildroot-linux-uclibc-strip --remove-section=.comment --remove-section=.note 2>/dev/null || true
Thus leading to stripped kernel modules that can not be loaded.

Changing the install access rights to 0664 make the correct strip command to be used :
find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
		xargs -r $(KSTRIPCMD);fi

And the modules can then be loaded normally.

While I understand this is a mistake on my side and I found it quite hard to track the root of the issue, it might be usefull to either :
* Change the $(STRIP_FIND_CMD) to not take into account kernel modules
* Yield an error or a warning during the make process
* Document this behaviour

Regards.
Comment 1 Thomas De Schampheleire 2014-04-29 18:57:09 UTC
A patch implementing the first suggestion was sent to the list:
http://patchwork.ozlabs.org/patch/343972/
Comment 2 Thomas De Schampheleire 2014-05-07 13:09:05 UTC
Fixed with commit http://git.buildroot.org/buildroot/commit/?id=066359166fa9407382fd9ce40e002249dbdda9c7

Thanks for reporting!