| Message ID | CAGbKfme=ecViP00rc0E7oBRJFxj0A0_Xn=+Wd=WvkVO+zBrEmQ@mail.gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | John Crispin |
| Headers | show |
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 <ardeleanalex@gmail.com>: >> Will give it a try. >> >> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>
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 <andrew@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 <ardeleanalex@gmail.com>: >>> >>> Will give it a try. >>> >>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>> >>>> >
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 <ardeleanalex@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 <andrew@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 <ardeleanalex@gmail.com>: >>>> >>>> Will give it a try. >>>> >>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>> >>>>> >>
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 > <ardeleanalex@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 <andrew@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 <ardeleanalex@gmail.com>: >>>>> Will give it a try. >>>>> >>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>
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 <andrew@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 >> <ardeleanalex@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 <andrew@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 <ardeleanalex@gmail.com>: >>>>>> >>>>>> Will give it a try. >>>>>> >>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>> >>>>>>> >
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 <andrew@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 >>> <ardeleanalex@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 <andrew@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 <ardeleanalex@gmail.com>: >>>>>>> Will give it a try. >>>>>>> >>>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>>>
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 <andrew@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 <andrew@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 >>>> <ardeleanalex@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 <andrew@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 >>>>>>> <ardeleanalex@gmail.com>: >>>>>>>> >>>>>>>> Will give it a try. >>>>>>>> >>>>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie >>>>>>>> <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>>>> >>>>>>>>> >
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 <ardeleanalex@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 <andrew@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 <andrew@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 >>>>> <ardeleanalex@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 <andrew@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 >>>>>>>> <ardeleanalex@gmail.com>: >>>>>>>>> >>>>>>>>> Will give it a try. >>>>>>>>> >>>>>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie >>>>>>>>> <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>>>>> >>>>>>>>>> >>
@ 郭涛 I took a look over your patch. I wonder if that's just specific to ARM architecture. I don't have an ARM device to test. On Fri, Jan 20, 2017 at 9:24 AM, Alexandru Ardelean <ardeleanalex@gmail.com> 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 > <ardeleanalex@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 <andrew@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 <andrew@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 >>>>>> <ardeleanalex@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 <andrew@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 >>>>>>>>> <ardeleanalex@gmail.com>: >>>>>>>>>> >>>>>>>>>> Will give it a try. >>>>>>>>>> >>>>>>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie >>>>>>>>>> <andrew@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, 郭涛 <guotao945@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 <andrew@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 >>>>>>>>>>> >>>>>>>>>>> >>>
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 > <ardeleanalex@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 <andrew@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 <andrew@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 >>>>>> <ardeleanalex@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 <andrew@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 >>>>>>>>> <ardeleanalex@gmail.com>: >>>>>>>>>> Will give it a try. >>>>>>>>>> >>>>>>>>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie >>>>>>>>>> <andrew@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, 郭涛 <guotao945@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 <andrew@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 <kaos@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.
--- a/Lib/ctypes/util.py +++ b/Lib/ctypes/util.py @@ -223,6 +223,7 @@ elif os.name == "posix": 'sparc64-64': 'libc6,64bit', 's390x-64': 'libc6,64bit', 'ia64-64': 'libc6,IA-64', + 'armv7l-32': 'libc0', } abi_type = mach_map.get(machine, 'libc6')
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 <ardeleanalex@gmail.com>: > Will give it a try. > > On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <andrew@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, 郭涛 <guotao945@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 <andrew@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 >> >>