Hi Alexandru,

You're missing some kernel hardware driver. I'm not sure if the default compile options include kernel drivers for all HDDs, or for SATA/AHCI. You probably just need to include some extra kernel drivers in make menuconfig.

--Andrew

On 1/19/17 04:31, Alexandru Ardelean wrote:
Hey,

So, I've tried to run  an OpenWrt system, x86_64,
https://github.com/openwrt/openwrt/commit/4e53a6e9c560b54361f9ed3639e8d12f9ab8939d

It was hanging on boot.
I've ran in Virtual Machine Manager with QEMU/KVM.
HDD emulation is SATA/AHCI [ I checked it's SATA/AHCI ]

It looks to me that it's hanging at  trying to mount root device  /dev/mtdblock0
Any thoughts ?

[    1.213897] ata4: SATA link down (SStatus 0 SControl 300)
[    1.214781] ata2: SATA link down (SStatus 0 SControl 300)
[    1.215572] ata6: SATA link down (SStatus 0 SControl 300)
[    1.216359] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.217229] ata1.00: ATA-7: QEMU HARDDISK, 2.3.1, max UDMA/100
[    1.217976] ata1.00: 31233 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    1.218787] ata1.00: applying bridge limits
[    1.233284] ata1.00: configured for UDMA/100
[    1.234233] ata5: SATA link down (SStatus 0 SControl 300)
[    1.235915] ata3: SATA link down (SStatus 0 SControl 300)
[    1.237371] scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK
   1    PQ: 0 ANSI: 5
[    1.239155] sd 0:0:0:0: [sda] 31233 512-byte logical blocks: (16.0
MB/15.3 MiB)
[    1.241487] sd 0:0:0:0: [sda] Write Protect is off
[    1.242882] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[    1.245329]  sda: sda1 sda2
[    1.245887] sda: p2 size 262144 extends beyond EOD, enabling native capacity
[    1.247232]  sda: sda1 sda2
[    1.247784] sda: p2 size 262144 extends beyond EOD, truncated
[    1.248864] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.256721] block2mtd: erasesize must be a divisor of device size
[    1.259958] rtc_cmos 00:00: setting system clock to 2017-01-19
09:27:33 UTC (1484818053)
[    1.261388] Waiting for root device /dev/mtdblock0...

On Wed, Jan 18, 2017 at 6:05 PM, Alexandru Ardelean
<ardeleana...@gmail.com> wrote:
Hey,

So, if you try on the system.

echo /usr/sbin/modprobe > /proc/sys/kernel/modprobe

Does it work ? I mean to just  import iptc ?
It worked for me, but I tried on a LEDE system (x86_64), which I'm
hoping may be similar to OpenWrt.

For me, the part that interests me the most, is if this is a bug
within Python [ since I maintain it ], and it runs on both LEDE &
OpenWrt.

Will try to spin up a OpenWrt [just cloned trunk from Github ].

And I'll try to reproduce.
For reference ; Python is version 2.7.13
It's from here: https://github.com/openwrt/packages

I could not find hash 5ba298c   in OpenWrt [
https://github.com/openwrt/openwrt ]  nor in packages [ link above ].

Will come back with findings for OpenWrt.

In the meantime, I will see about proposing a solution for updating
/proc/sys/kernel/modprobe   correctly for both LEDE & OpenWrt.

Thanks
Alex



On Wed, Jan 18, 2017 at 4:38 PM, Andrew McConachie <and...@depht.com> wrote:
Hi 郭涛 and Alexandru,

ldconfig depends on using eglibc to fulfill libc requirement.

Symbol: PACKAGE_ldconfig [=n]
Type  : tristate
Prompt: ldconfig............................... Shared library path
configuration
Location:
(3) -> Utilities
Defined at tmp/.config-package.in:82365
Depends on: !USE_MUSL [=y]

If we make python depend on ldconfig, then are we saying python cannot be
used with MUSL libc? I don't know what the default libc is for OpenWRT or
whether one is considered experimental more than the other. But this is
something to consider.

Thanks,
Andrew


On 1/18/17 03:32, 郭涛 wrote:
Hi Andrew & Alexandru

Forget the patch in prev mail, use attached patch instead.

To use ctypes.util.find_library, you need one of gcc, ldconfig or
objdump. I suggest you use ldconfig

After install ldconfig,  run ldconfig first to update cache
then run ldconfig -p to show all of your libraries
in my case, it shows:

195 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
          uhttpd_tls.so (libc0) => /usr/lib/uhttpd_tls.so
          rclibrary.so (libc0) => /usr/lib/rclibrary.so
          libz.so.1 (libc0) => /usr/lib/libz.so.1
          libz.so (libc0) => /usr/lib/libz.so
          libyaml-0.so.2 (libc0) => /usr/lib/libyaml-0.so.2
          ......

All libraries are libc0, that's why ctypes.util.find_library does not
work on my platform

You need to run 'uname -m' to get your matchine name and run 'ldconfig
-p' to get library type.
Atter all, append  '$machine' : '$type'  to  mach_map list in
ctypes/util.py and try find_library('pthread')


from ctypes.util import find_library

find_library('pthread')
'libpthread.so.0'






2017-01-17 22:22 GMT+08:00 Alexandru Ardelean <ardeleana...@gmail.com>:
Will give it a try.

On Mon, Jan 16, 2017 at 9:41 PM, Andrew McConachie <and...@depht.com>
wrote:
Hi Alexandru and 郭涛,

Attached is the Makefile I made for python-iptables. I can work around
this
by hardwiring library locations in the source of python-iptables, but
I'd
rather do it the correct way. To reproduce this build an OpenWrt system
with
this Makefile and then just create a simple Python script with 'import
iptc'.

I am cloning OpenWrt from Github and running make menuconfig;make to
build
everything. My Github version is about 6 days old with the last commit
at
5ba298c.

I also found that /proc/sys/kernel/modprobe contains /sbin/modprobe,
while
the modprobe binary is at /usr/sbin/modprobe. According to the Debian
man
page on proc(5), /proc/sys/kernel/modprobe should point to the modprobe
binary. Googling about seems also to suggest that this file should
contain
the location of the modprobe binary. So I would say this is also a bug.

Thanks!
--Andrew


On 1/16/17 07:23, Alexandru Ardelean wrote:
Hey Andrew & 郭涛

Sorry I did not answer sooner.

@Andrew: do you have a Makefile for the python-iptables packages ?
I'd like to try to build it and see the issue. Or, are you just using
that .py file ?
Can you give a bit more input on which Python version you're using,
and which OpenWrt version?

If the issue is still present in the current packages trunk, I'd like
to
fix it.
And if  郭涛's fix works, we can apply it to trunk.

Thanks
Alex


On Mon, Jan 16, 2017 at 6:23 AM, 郭涛 <guotao...@gmail.com> wrote:
I also meet this issue.
I fixed it using below change



https://github.com/gt945/Netgear-D7800-Openwrt-Packages/commit/fab71ca0ebf36d5f7b495b96f14d459e794b7224


2017-01-13 0:43 GMT+08:00 Andrew McConachie <and...@depht.com>:
Hi OpenWRT Devs,

I'm building an OpenWRT package for python-iptables for a project I'm
working on and getting this error message when attempting to use it.

       import iptc
     File "/usr/lib/python2.7/site-packages/iptc/__init__.py", line
10, in
<module>
       from ip4tc import (is_table_available, Table, Chain, Rule,
Match,
Target,
     File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py", line 13,
in
<module>
       from xtables import (XT_INV_PROTO, NFPROTO_IPV4, XTablesError,
xtables,
     File "/usr/lib/python2.7/site-packages/iptc/xtables.py", line
677, in
<module>
       _optind = ct.c_long.in_dll(_libc, "optind")
AttributeError: 'NoneType' object has no attribute '_handle'

You can view xtables.py here if you're curious.
https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py

The problem is that my python-iptables package cannot find libc
functions
using ctypes.util.find_library(). I've tried building OpenWRT using
both
musl and eglibc but neither work. I've also tried building OpenWRT
with
objdump and ldconfig. When I include ldconfig via 'make menuconfig'
it
doesn't actually populate my OpenWRT image with an ldconfig binary.
Maybe
this is the problem?

This bug report looks similar to my problem, but it's about MIPS and
marked
as closed.
https://dev.openwrt.org/ticket/20123

Any help or pointers would be much appreciated.

Thanks,
Andrew
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to