Fix 433: insert_modules: Ignore modprobe's return code #891
Conversation
yanosz
force-pushed
the
master+flyspray_433
branch
from
876f731 to
a5019e5
Compare
|
Your commit has formal issues. Please have a look at draft version of the github submission guidelines and the generic submission guidelines.
Please have a look at the LEDE commit history to have some examples on how to do it the right way. |
When installing kmod-* packages, insert_modules modprobes all modules. modprobe fails, if the module is already loaded and succeeds if the module doesn't exists. Ignoring its return code appears reasonable. This causes package installation to fail Fix FS#433 - kmod-ebtables, kmod-br-netfilter opkg install failed Related to Busybox bug 9676 Signed-off-by: Jan 'yanosz' Lühr <lede@yanosz.net>
yanosz
force-pushed
the
master+flyspray_433
branch
from
a5019e5 to
71b45b3
Compare
|
hmm.. hope hope its ok, now |
| # Since busybox modprobe returns 0 on loading non-existing | ||
| # and 255 on loading already loaded modules | ||
| # its return-code is not useful | ||
| modprobe $m || true |
There was a problem hiding this comment.
better make it modprobe; [ "$?" = 0 -o "$?" = 255 ] and adapt the comment accordingly
There was a problem hiding this comment.
hmm... I don't agree.
This code doesn't ignore modprobe's return code. I think, we should do so, since its bogus
Thus I don't like to make "255" explicit and go for ignoring modprobe's return code at all.
I think, that there's a semantic difference.
If you are aware of specific return code, that should be taken into account, I'm happy with mapping that option to some error value.
There was a problem hiding this comment.
ok, got it. thanks for the efforts ;)
|
Well, I just checked the issue again. It seems like the modprobe in question here is from the ubox package, not busybox. We should fix ubox kmodloader instead. @yanosz , to verify, please check the output of |
|
This patch shouldn't be required any longer. The issue was fixed with https://git.lede-project.org/21a4bd04062e16164f4f3e1c67005a062f470b0c, which went into LEDE with https://git.lede-project.org/c8f7031ba76824642035ed0525fd640e00f58926. Beside of that, no response from the PR author. |
3 participants
Fix for https://bugs.lede-project.org/index.php?do=details&task_id=433
Work-around for https://bugs.busybox.net/show_bug.cgi?id=9676