Hey, So, I've tried to run an OpenWrt system, x86_64, https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d
It was hanging on boot. I've ran in Virtual Machine Manager with QEMU/KVM. HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ] It looks to me that it's hanging at trying to mount root device /dev/mtdblock0 Any thoughts ? [ 1.213897] ata4: SATA link down (SStatus 0 SControl 300) [ 1.214781] ata2: SATA link down (SStatus 0 SControl 300) [ 1.215572] ata6: SATA link down (SStatus 0 SControl 300) [ 1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100 [ 1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 1.218787] ata1.00: applying bridge limits [ 1.233284] ata1.00: configured for UDMA/100 [ 1.234233] ata5: SATA link down (SStatus 0 SControl 300) [ 1.235915] ata3: SATA link down (SStatus 0 SControl 300) [ 1.237371] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 1 PQ: 0 ANSI: 5 [ 1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0 MB/15.3 MiB) [ 1.241487] sd 0:0:0:0: [sda] Write Protect is off [ 1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 1.245329] sda: sda1 sda2 [ 1.245887] sda: p2 size 262144 extends beyond EOD, enabling native capacity [ 1.247232] sda: sda1 sda2 [ 1.247784] sda: p2 size 262144 extends beyond EOD, truncated [ 1.248864] sd 0:0:0:0: [sda] Attached SCSI disk [ 1.256721] block2mtd: erasesize must be a divisor of device size [ 1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19 09:27:33 UTC (1484818053) [ 1.261388] Waiting for root device /dev/mtdblock0... On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean <ardeleana...@gmail.com> wrote: > Hey, > > So, if you try on the system. > > echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe > > Does it work ? I mean to just import iptc ? > It worked for me, but I tried on a LEDE system (x86_64), which I'm > hoping may be similar to OpenWrt. > > For me, the part that interests me the most, is if this is a bug > within Python [ since I maintain it ], and it runs on both LEDE & > OpenWrt. > > Will try to spin up a OpenWrt [just cloned trunk from Github ]. > > And I'll try to reproduce. > For reference ; Python is version 2.7.13 > It's from here: https://github.com/openwrt/packages > > I could not find hash 5ba298c in OpenWrt [ > https://github.com/openwrt/openwrt ] nor in packages [ link above ]. > > Will come back with findings for OpenWrt. > > In the meantime, I will see about proposing a solution for updating > /proc/sys/kernel/modprobe correctly for both LEDE & OpenWrt. > > Thanks > Alex > > > > On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com> wrote: >> Hi 郭涛 and Alexandru, >> >> ldconfig depends on using eglibc to fulfill libc requirement. >> >> Symbol: PACKAGE_ldconfig [=n] >> Type : tristate >> Prompt: ldconfig............................... Shared library path >> configuration >> Location: >> (3) -> Utilities >> Defined at tmp/.config-package.in:82365 >> Depends on: !USE_MUSL [=y] >> >> If we make python depend on ldconfig, then are we saying python cannot be >> used with MUSL libc? I don't know what the default libc is for OpenWRT or >> whether one is considered experimental more than the other. But this is >> something to consider. >> >> Thanks, >> Andrew >> >> >> On 1/18/17 03:32, 郭涛 wrote: >>> >>> Hi Andrew & Alexandru >>> >>> Forget the patch in prev mail, use attached patch instead. >>> >>> To use ctypes.util.find_library, you need one of gcc, ldconfig or >>> objdump. I suggest you use ldconfig >>> >>> After install ldconfig, run ldconfig first to update cache >>> then run ldconfig -p to show all of your libraries >>> in my case, it shows: >>> >>> 195 libs found in cache `/etc/ld.so.cache' (version 1.7.0) >>> uhttpd_tls.so (libc0) => /usr/lib/uhttpd_tls.so >>> rclibrary.so (libc0) => /usr/lib/rclibrary.so >>> libz.so.1 (libc0) => /usr/lib/libz.so.1 >>> libz.so (libc0) => /usr/lib/libz.so >>> libyaml-0.so.2 (libc0) => /usr/lib/libyaml-0.so.2 >>> ...... >>> >>> All libraries are libc0, that's why ctypes.util.find_library does not >>> work on my platform >>> >>> You need to run 'uname -m' to get your matchine name and run 'ldconfig >>> -p' to get library type. >>> Atter all, append '$machine' : '$type' to mach_map list in >>> ctypes/util.py and try find_library('pthread') >>> >>> >>>>>> from ctypes.util import find_library >>>>>> >>>>>> find_library('pthread') >>> >>> 'libpthread.so.0' >>> >>> >>> >>> >>> >>> >>> 2017-01-17 22:22 GMT+08:00 Alexandru Ardelean <ardeleana...@gmail.com>: >>>> >>>> Will give it a try. >>>> >>>> On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <and...@depht.com> >>>> wrote: >>>>> >>>>> Hi Alexandru and 郭涛, >>>>> >>>>> Attached is the Makefile I made for python-iptables. I can work around >>>>> this >>>>> by hardwiring library locations in the source of python-iptables, but >>>>> I'd >>>>> rather do it the correct way. To reproduce this build an OpenWrt system >>>>> with >>>>> this Makefile and then just create a simple Python script with 'import >>>>> iptc'. >>>>> >>>>> I am cloning OpenWrt from Github and running make menuconfig;make to >>>>> build >>>>> everything. My Github version is about 6 days old with the last commit >>>>> at >>>>> 5ba298c. >>>>> >>>>> I also found that /proc/sys/kernel/modprobe contains /sbin/modprobe, >>>>> while >>>>> the modprobe binary is at /usr/sbin/modprobe. According to the Debian >>>>> man >>>>> page on proc(5), /proc/sys/kernel/modprobe should point to the modprobe >>>>> binary. Googling about seems also to suggest that this file should >>>>> contain >>>>> the location of the modprobe binary. So I would say this is also a bug. >>>>> >>>>> Thanks! >>>>> --Andrew >>>>> >>>>> >>>>> On 1/16/17 07:23, Alexandru Ardelean wrote: >>>>>> >>>>>> Hey Andrew & 郭涛 >>>>>> >>>>>> Sorry I did not answer sooner. >>>>>> >>>>>> @Andrew: do you have a Makefile for the python-iptables packages ? >>>>>> I'd like to try to build it and see the issue. Or, are you just using >>>>>> that .py file ? >>>>>> Can you give a bit more input on which Python version you're using, >>>>>> and which OpenWrt version? >>>>>> >>>>>> If the issue is still present in the current packages trunk, I'd like >>>>>> to >>>>>> fix it. >>>>>> And if 郭涛's fix works, we can apply it to trunk. >>>>>> >>>>>> Thanks >>>>>> Alex >>>>>> >>>>>> >>>>>> On Mon, Jan 16, 2017 at 6:23 AM, 郭涛 <guotao...@gmail.com> wrote: >>>>>>> >>>>>>> I also meet this issue. >>>>>>> I fixed it using below change >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://github.com/gt945/Netgear-D7800-Openwrt-Packages/commit/fab71ca0ebf36d5f7b495b96f14d459e794b7224 >>>>>>> >>>>>>> >>>>>>> 2017-01-13 0:43 GMT+08:00 Andrew McConachie <and...@depht.com>: >>>>>>>> >>>>>>>> Hi OpenWRT Devs, >>>>>>>> >>>>>>>> I'm building an OpenWRT package for python-iptables for a project I'm >>>>>>>> working on and getting this error message when attempting to use it. >>>>>>>> >>>>>>>> import iptc >>>>>>>> File "/usr/lib/python2.7/site-packages/iptc/__init__.py", line >>>>>>>> 10, in >>>>>>>> <module> >>>>>>>> from ip4tc import (is_table_available, Table, Chain, Rule, >>>>>>>> Match, >>>>>>>> Target, >>>>>>>> File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py", line 13, >>>>>>>> in >>>>>>>> <module> >>>>>>>> from xtables import (XT_INV_PROTO, NFPROTO_IPV4, XTablesError, >>>>>>>> xtables, >>>>>>>> File "/usr/lib/python2.7/site-packages/iptc/xtables.py", line >>>>>>>> 677, in >>>>>>>> <module> >>>>>>>> _optind = ct.c_long.in_dll(_libc, "optind") >>>>>>>> AttributeError: 'NoneType' object has no attribute '_handle' >>>>>>>> >>>>>>>> You can view xtables.py here if you're curious. >>>>>>>> https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py >>>>>>>> >>>>>>>> The problem is that my python-iptables package cannot find libc >>>>>>>> functions >>>>>>>> using ctypes.util.find_library(). I've tried building OpenWRT using >>>>>>>> both >>>>>>>> musl and eglibc but neither work. I've also tried building OpenWRT >>>>>>>> with >>>>>>>> objdump and ldconfig. When I include ldconfig via 'make menuconfig' >>>>>>>> it >>>>>>>> doesn't actually populate my OpenWRT image with an ldconfig binary. >>>>>>>> Maybe >>>>>>>> this is the problem? >>>>>>>> >>>>>>>> This bug report looks similar to my problem, but it's about MIPS and >>>>>>>> marked >>>>>>>> as closed. >>>>>>>> https://dev.openwrt.org/ticket/20123 >>>>>>>> >>>>>>>> Any help or pointers would be much appreciated. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Andrew >>>>>>>> _______________________________________________ >>>>>>>> openwrt-devel mailing list >>>>>>>> openwrt-devel@lists.openwrt.org >>>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openwrt-devel mailing list >>>>>>> openwrt-devel@lists.openwrt.org >>>>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>>>> >>>>> >> _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
