Hi Alexandru,
Moving the kmod userspace tools to /sbin/ would align OpenWRT with other
distros and fix the problem with /proc/sys/kernel/modprobe pointing at
the wrong binary. I like the idea, but I do worry that it might break
things that are now expecting these binaries in /usr/sbin/. We know that
no one is resolving the location of modprobe correctly because
/proc/sys/kernel/modprobe is a broken link.
According to the proc(5) manpage this file is described in
Documentation/kmod.txt which is only present in 2.4 kernels and earlier.
I've dug up this file from 2.4.5 and attached it to this mail.
Thanks,
Andrew
On 1/20/17 02:24, Alexandru Ardelean wrote:
Hey,
So, just to follow up, real quick.
There's another proposal here [that started in parallel and earlier than mine]:
https://patchwork.ozlabs.org/patch/713718/
On Thu, Jan 19, 2017 at 9:07 PM, Alexandru Ardelean
<ardeleana...@gmail.com> wrote:
Cool.
Then, a fix I'm proposing to LEDE, and will also spin up a PR for OpenWrt:
https://github.com/lede-project/source/pull/722/commits/6e0844540355c89e7f39504db374278d1c6cf05c
Feel free to use it.
It should apply on top of OpenWrt.
Though, be aware ; it's not yet been discussed whether this method is
completely sane.
I'm hoping some sort of elegant solution will come out of that.
In the worst case, you'll need to patch python-iptables [ add a patch
in python-iptables' folder ] to use /usr/sbin/modprobe directly.
Which may not be a bad idea either.
I think it may come down to preferences.
In any case, since it's not a issue with Python, I'll just keep an eye
on that PR, and update OpenWrt if needed.
Thanks
Alex
On Thu, Jan 19, 2017 at 8:20 PM, Andrew McConachie <and...@depht.com> wrote:
Hi Alexandru,
Yes, I'm sorry I didn't respond earlier. Having the correct binary location
in /proc/sys/kernel/modprobe resolves any problems with python-iptables.
It's really just a problem with the kernel not populating that file
correctly.
Thanks,
Andrew
On 1/19/17 11:49, Alexandru Ardelean wrote:
I'm pretty sure the driver was selected.
I'll try to check a bit more in-depth.
In the meantime, did you try the
echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
?
On Thu, Jan 19, 2017 at 4:07 PM, Andrew McConachie <and...@depht.com>
wrote:
Hi Alexandru,
You're missing some kernel hardware driver. I'm not sure if the default
compile options include kernel drivers for all HDDs, or for SATA/AHCI.
You
probably just need to include some extra kernel drivers in make
menuconfig.
--Andrew
On 1/19/17 04:31, Alexandru Ardelean wrote:
Hey,
So, I've tried to run an OpenWrt system, x86_64,
https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d
It was hanging on boot.
I've ran in Virtual Machine Manager with QEMU/KVM.
HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ]
It looks to me that it's hanging at trying to mount root device
/dev/mtdblock0
Any thoughts ?
[ 1.213897] ata4: SATA link down (SStatus 0 SControl 300)
[ 1.214781] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.215572] ata6: SATA link down (SStatus 0 SControl 300)
[ 1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100
[ 1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 1.218787] ata1.00: applying bridge limits
[ 1.233284] ata1.00: configured for UDMA/100
[ 1.234233] ata5: SATA link down (SStatus 0 SControl 300)
[ 1.235915] ata3: SATA link down (SStatus 0 SControl 300)
[ 1.237371] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK
1 PQ: 0 ANSI: 5
[ 1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0
MB/15.3 MiB)
[ 1.241487] sd 0:0:0:0: [sda] Write Protect is off
[ 1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 1.245329] sda: sda1 sda2
[ 1.245887] sda: p2 size 262144 extends beyond EOD, enabling native
capacity
[ 1.247232] sda: sda1 sda2
[ 1.247784] sda: p2 size 262144 extends beyond EOD, truncated
[ 1.248864] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1.256721] block2mtd: erasesize must be a divisor of device size
[ 1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19
09:27:33 UTC (1484818053)
[ 1.261388] Waiting for root device /dev/mtdblock0...
On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean
<ardeleana...@gmail.com> wrote:
Hey,
So, if you try on the system.
echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe
Does it work ? I mean to just import iptc ?
It worked for me, but I tried on a LEDE system (x86_64), which I'm
hoping may be similar to OpenWrt.
For me, the part that interests me the most, is if this is a bug
within Python [ since I maintain it ], and it runs on both LEDE &
OpenWrt.
Will try to spin up a OpenWrt [just cloned trunk from Github ].
And I'll try to reproduce.
For reference ; Python is version 2.7.13
It's from here: https://github.com/openwrt/packages
I could not find hash 5ba298c in OpenWrt [
https://github.com/openwrt/openwrt ] nor in packages [ link above ].
Will come back with findings for OpenWrt.
In the meantime, I will see about proposing a solution for updating
/proc/sys/kernel/modprobe correctly for both LEDE & OpenWrt.
Thanks
Alex
On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com>
wrote:
Hi 郭涛 and Alexandru,
ldconfig depends on using eglibc to fulfill libc requirement.
Symbol: PACKAGE_ldconfig [=n]
Type : tristate
Prompt: ldconfig............................... Shared library path
configuration
Location:
(3) -> Utilities
Defined at tmp/.config-package.in:82365
Depends on: !USE_MUSL [=y]
If we make python depend on ldconfig, then are we saying python cannot
be
used with MUSL libc? I don't know what the default libc is for OpenWRT
or
whether one is considered experimental more than the other. But this
is
something to consider.
Thanks,
Andrew
On 1/18/17 03:32, 郭涛 wrote:
Hi Andrew & Alexandru
Forget the patch in prev mail, use attached patch instead.
To use ctypes.util.find_library, you need one of gcc, ldconfig or
objdump. I suggest you use ldconfig
After install ldconfig, run ldconfig first to update cache
then run ldconfig -p to show all of your libraries
in my case, it shows:
195 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
uhttpd_tls.so (libc0) => /usr/lib/uhttpd_tls.so
rclibrary.so (libc0) => /usr/lib/rclibrary.so
libz.so.1 (libc0) => /usr/lib/libz.so.1
libz.so (libc0) => /usr/lib/libz.so
libyaml-0.so.2 (libc0) => /usr/lib/libyaml-0.so.2
......
All libraries are libc0, that's why ctypes.util.find_library does not
work on my platform
You need to run 'uname -m' to get your matchine name and run
'ldconfig
-p' to get library type.
Atter all, append '$machine' : '$type' to mach_map list in
ctypes/util.py and try find_library('pthread')
from ctypes.util import find_library
find_library('pthread')
'libpthread.so.0'
2017-01-17 22:22 GMT+08:00 Alexandru Ardelean
<ardeleana...@gmail.com>:
Will give it a try.
On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie
<and...@depht.com>
wrote:
Hi Alexandru and 郭涛,
Attached is the Makefile I made for python-iptables. I can work
around
this
by hardwiring library locations in the source of python-iptables,
but
I'd
rather do it the correct way. To reproduce this build an OpenWrt
system
with
this Makefile and then just create a simple Python script with
'import
iptc'.
I am cloning OpenWrt from Github and running make menuconfig;make
to
build
everything. My Github version is about 6 days old with the last
commit
at
5ba298c.
I also found that /proc/sys/kernel/modprobe contains
/sbin/modprobe,
while
the modprobe binary is at /usr/sbin/modprobe. According to the
Debian
man
page on proc(5), /proc/sys/kernel/modprobe should point to the
modprobe
binary. Googling about seems also to suggest that this file should
contain
the location of the modprobe binary. So I would say this is also a
bug.
Thanks!
--Andrew
On 1/16/17 07:23, Alexandru Ardelean wrote:
Hey Andrew & 郭涛
Sorry I did not answer sooner.
@Andrew: do you have a Makefile for the python-iptables packages ?
I'd like to try to build it and see the issue. Or, are you just
using
that .py file ?
Can you give a bit more input on which Python version you're
using,
and which OpenWrt version?
If the issue is still present in the current packages trunk, I'd
like
to
fix it.
And if 郭涛's fix works, we can apply it to trunk.
Thanks
Alex
On Mon, Jan 16, 2017 at 6:23 AM, 郭涛 <guotao...@gmail.com> wrote:
I also meet this issue.
I fixed it using below change
https://github.com/gt945/Netgear-D7800-Openwrt-Packages/commit/fab71ca0ebf36d5f7b495b96f14d459e794b7224
2017-01-13 0:43 GMT+08:00 Andrew McConachie <and...@depht.com>:
Hi OpenWRT Devs,
I'm building an OpenWRT package for python-iptables for a
project
I'm
working on and getting this error message when attempting to use
it.
import iptc
File "/usr/lib/python2.7/site-packages/iptc/__init__.py",
line
10, in
<module>
from ip4tc import (is_table_available, Table, Chain,
Rule,
Match,
Target,
File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py",
line
13,
in
<module>
from xtables import (XT_INV_PROTO, NFPROTO_IPV4,
XTablesError,
xtables,
File "/usr/lib/python2.7/site-packages/iptc/xtables.py",
line
677, in
<module>
_optind = ct.c_long.in_dll(_libc, "optind")
AttributeError: 'NoneType' object has no attribute '_handle'
You can view xtables.py here if you're curious.
https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py
The problem is that my python-iptables package cannot find libc
functions
using ctypes.util.find_library(). I've tried building OpenWRT
using
both
musl and eglibc but neither work. I've also tried building
OpenWRT
with
objdump and ldconfig. When I include ldconfig via 'make
menuconfig'
it
doesn't actually populate my OpenWRT image with an ldconfig
binary.
Maybe
this is the problem?
This bug report looks similar to my problem, but it's about MIPS
and
marked
as closed.
https://dev.openwrt.org/ticket/20123
Any help or pointers would be much appreciated.
Thanks,
Andrew
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Kmod: The Kernel Module Loader
Kirk Petersen
Kmod is a simple replacement for kerneld. It consists of a
request_module() replacement and a kernel thread called kmod. When the
kernel requests a module, the kmod wakes up and execve()s modprobe,
passing it the name that was requested.
If you have the /proc filesystem mounted, you can set the path of
modprobe (where the kernel looks for it) by doing:
echo "/sbin/modprobe" > /proc/sys/kernel/modprobe
To periodically unload unused modules, put something like the following
in root's crontab entry:
0-59/5 * * * * /sbin/rmmod -a
Kmod only loads modules. Kerneld could do more (although
nothing in the standard kernel used its other features). If you
require features such as request_route, we suggest that you take
a similar approach. A simple request_route function could be called,
and a kroute kernel thread could be sent off to do the work. But
we should probably keep this to a minimum.
Kerneld also had a mechanism for storing device driver settings. This
can easily be done with modprobe. When a module is unloaded, modprobe
could look at a per-driver-configurable location (/proc/sys/drivers/blah)
for device driver settings and save them to a file. When a module
is loaded, simply cat that file back to that location in the proc
filesystem. Or perhaps a script could be a setting in /etc/modules.conf.
There are many user-land methods that will work (I prefer using /proc,
myself).
If kerneld worked, why replace it?
- kerneld used SysV IPC, which can now be made into a module. Besides,
SysV IPC is ugly and should therefore be avoided (well, certainly for
kernel level stuff)
- both kmod and kerneld end up doing the same thing (calling modprobe),
so why not skip the middle man?
- removing kerneld related stuff from ipc/msg.c made it 40% smaller
- kmod reports errors through the normal kernel mechanisms, which avoids
the chicken and egg problem of kerneld and modular Unix domain sockets
Keith Owens <k...@ocs.com.au> December 1999
The combination of kmod and modprobe can loop, especially if modprobe uses a
system call that requires a module. If modules.dep does not exist and modprobe
was started with the -s option (kmod does this), modprobe tries to syslog() a
message. syslog() needs Unix sockets, if Unix sockets are modular then kmod
runs "modprobe -s net-pf-1". This runs a second copy of modprobe which
complains that modules.dep does not exist, tries to use syslog() and starts yet
another copy of modprobe. This is not the only possible kmod/modprobe loop,
just the most common.
To detect loops caused by "modprobe needs a service which is in a module", kmod
limits the number of concurrent kmod issued modprobes. See MAX_KMOD_CONCURRENT
in kernel/kmod.c. When this limit is exceeded, the kernel issues message "kmod:
runaway modprobe loop assumed and stopped".
Note for users building a heavily modularised system. It is a good idea to
create modules.dep after installing the modules and before booting a kernel for
the first time. "depmod -ae m.n.p" where m.n.p is the new kernel version.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
