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

Gary Thomas gary at mlbassoc.com
Thu Jul 18 07:38:01 PDT 2013


On 2013-07-18 08:20, Rich Bayliss wrote:
> 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?

There is some support in recent OE-core for read-only rootfs.  Search
the Yocto project archives for more information (I've not tried it yet).

The more interesting thing is that I have systems other than the RPI
that are built using Poky/Yocto where the power is often the cause
of a reboot and I've never seen this error/situation occur!  Maybe
I can experiment a bit and compare the RPI build with my other systems
(I have both) and see why.  Not sure when I can get to it though...

>
> 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
>
>
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------



More information about the yocto mailing list