[yocto] [meta-raspberrypi] Network not working after first boot success

[Rich Bayliss]

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 <gary at mlbassoc.com> wrote:
> On 2013-07-18 08:07, Rich Bayliss wrote:
>>
>> On 18 July 2013 14:50, Rich Bayliss <richbayliss at gmail.com> wrote:
>>>
>>> On 18 July 2013 12:28, Rich Bayliss <richbayliss at gmail.com> wrote:
>>>>
>>>> On 18 July 2013 12:07, Paul Barker <paul at paulbarker.me.uk> wrote:
>>>>>
>>>>> On 18 July 2013 11:55, Rich Bayliss <richbayliss at gmail.com> 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: paul at paulbarker.me.uk
>>>>> 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 at 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 at 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
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Rich Bayliss