Indeed. However the usage requirement of the system rely on being headless, and thus a power-pull is likely to happen.
I guess the only way to rule this in/out would be run with a RO rootfs - and mount a sperate partition for user files. Do you know how I can achieve this? On 18 July 2013 15:13, Gary Thomas <[email protected]> wrote: > On 2013-07-18 08:07, Rich Bayliss wrote: >> >> On 18 July 2013 14:50, Rich Bayliss <[email protected]> wrote: >>> >>> On 18 July 2013 12:28, Rich Bayliss <[email protected]> wrote: >>>> >>>> On 18 July 2013 12:07, Paul Barker <[email protected]> wrote: >>>>> >>>>> On 18 July 2013 11:55, Rich Bayliss <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Is this a known issue? Does anyone have any ideas? >>>>>>>> >>>>> >>>>> Could you try running 'ip addr' and 'ip link' instead of 'ifconfig'? >>>>> Just wondering whether they query information differently and might >>>>> show something else. The other place to look is in the output of >>>>> 'dmesg'. >>>>> >>>>> Does un-plugging and re-plugging the network cable (without running >>>>> 'ifup' or 'ifdown') make any difference? >>>>> >>>>> -- >>>>> Paul Barker >>>>> >>>>> Email: [email protected] >>>>> http://www.paulbarker.me.uk >>>> >>>> >>>> I have tried unplugging/replugging and it stays down. >>>> >>>> I have run the commands and there is a difference, however I also ran >>>> "lsmod" and there is a big difference. >>>> >>>> Working: >>>> root@raspberrypi:~# lsmod >>>> Not tainted >>>> ipv6 281069 12 - Live 0xbf02c000 >>>> spidev 5343 0 - Live 0xbf022000 >>>> joydev 9477 0 - Live 0xbf01c000 >>>> evdev 9486 0 - Live 0xbf015000 >>>> leds_gpio 2194 0 - Live 0xbf011000 >>>> led_class 3581 1 leds_gpio, Live 0xbf00d000 >>>> spi_bcm2708 4631 0 - Live 0xbf004000 >>>> i2c_bcm2708 3879 0 - Live 0xbf000000 >>>> >>>> Not working: >>>> root@raspberrypi:~# lsmod >>>> Not tainted >>>> ipv6 281069 12 - Live 0xbf00d000 >>>> joydev 9477 0 - Live 0xbf007000 >>>> evdev 9486 0 - Live 0xbf000000 >>>> >>>> At this point, if I then do the "ifdown"/"ifup" dance, my connection >>>> works, but not more modules are loaded - does this help you guys? >>>> >>>> -- >>>> Rich Bayliss >>> >>> >>> I have connected a serial terminal now, and I can provide boot logs. >>> It looks like maybe UDEV is causing/part of the issue. When it boots >>> successfully, then I dont get a "udevadm settle" message: >>> >>> Starting udev >>> [ 3.085091] smsc95xx v1.0.4 >>> [ 3.157196] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at >>> usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:e1:f6:e2 >>> [ 3.487588] udevd[74]: starting version 182 >>> Starting Bootlog daemon: bootlogd. >>> [ 6.162643] EXT4-fs (mmcblk0p2): re-mounted. Opts: >>> errors=remount-ro,data=ordered >>> Configuring network interfaces... udhcpc (v1.21.1) started >>> Sending discover... >>> [ 9.138863] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, >>> full-duplex, lpa 0xC1E1 >>> Sending discover... >>> Sending select for 192.168.1.110... >>> Lease of 192.168.1.110 obtained, lease time 268435455 >>> /etc/udhcpc.d/50default: Adding DNS 192.168.1.254 >>> done. >>> >>> However when the network is broken I see the following: >>> >>> Starting udev >>> [ 5.342406] udevd[74]: starting version 182 >>> Starting Bootlog daemon: bootlogd. >>> [ 7.938281] EXT4-fs (mmcblk0p2): re-mounted. Opts: >>> errors=remount-ro,data=ordered >>> >>> udevadm settle - timeout of 3 seconds reached, the event queue contains: >>> /sys/devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 >>> (980) >>> /sys/devices/platform/mmc_host/mmc0/mmc0:8fe4/block/mmcblk0/mmcblk0p1 >>> (985) >>> /sys/devices/platform/mmc_host/mmc0/mmc0:8fe4/block/mmcblk0/mmcblk0p2 >>> (986) >>> Configuring network interfaces... ifup: interface lo already configured >>> ifup: interface eth0 already configured >>> done. >>> >>> -- >>> Rich Bayliss >> >> >> Could be a total wildcard, but I have managed to reliably reproduce >> this behavior: >> >> 1) Boot from fresh SD image - network working. >> 2) run "dmesg | grep recovery" - no results >> 3) pull the power >> 4) Boots without network >> 5) run "dmesg | grep recovery" - 1 result "EXT4-fs (mmcblk0p2): >> recovery complete" >> 6) run "reboot" >> 7) Boots with network >> 8) run "dmesg | grep recovery" - no results >> >> I wonder if the dirty reboot by power pull as making the boot process >> longer, and thus UDEV is failing to bring eth0 up in time? What do you >> guys think? > > > I think the key difference is that when you type 'reboot' everything > is shut down sanely and the "saved state" indicates as such. When you > simply yank the power, the state information is stale and incorrect, > causing your problems. > > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > _______________________________________________ > yocto mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/yocto -- Rich Bayliss _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
