On Tue, Mar 21, 2017 at 2:29 PM, Jon Seymour <jon.seym...@gmail.com> wrote:

>
>
> On Tuesday, 21 March 2017 14:18:41 UTC+11, William Hermans wrote:
>>
>> So, it's very likely you need the driver to come up before you can bring
>> the interface up. So, one option would be to "inject" your driver into the
>> initrd( very advanced ), or to write a systemd service( a systemd timer may
>> also work ) that sets the device up appropriately.
>>
>> My thinking is that /etc/network/interfaces is loading devices *before*
>> the device driver for your adapter is loaded and running. You could
>> experiment by duplicating the exact commands you're using to manually bring
>> the interface up( the commands where it works ), and run that script at
>> boot through a systemd service. If that works, there is a good chance that
>> it's still loading slower than using the /etc/network/interfaces file . . .
>> but if that's the way you have to get it working at boot. It'll work.
>> Anyway, try that, and see if that work. If not, then what I said about the
>> interfaces file trying ot load your network interface too fast is probably
>> the case.
>>
>>
> William, thanks for your reply.
>
> I haven't tried those steps yet, but what I have tried is systemctl stop
> networking which causes all intefaces but usb0 to disappear (which is
> fortunate, since I need that!). In particular, it removes eth0 and lo0. If
> I then run systemctl start networking, the other interfaces come back. My
> interpretation is that even if there was  race condition during boot that
> might prevent enxe46f13f3df43 being detected on first boot, by the time
> it starts the second time, it should be there.  The command I am using to
> bring up the interface is ifup, which does consult the
> /etc/network/interfaces file. It isn't clear to me why a manually invoked
> ifup works, but a systemctl start networking doesn't, even after the system
> has been booted for a while.
>
>
William,

I just tried the systemctl stop/start networking scenario again and found
that it does actually work in this case, so the problem I initially
reported does appear to be a startup race condition as you suggest.

I'll investigate what can be done to fix a boot race along the lines you
suggest. Thanks for your help!

jon.



> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/RFbRNJCk7l8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAH3AnroH_JCP%3DZ7Atj0gL4xJcYWO%2BOyhFKY%3Dcq3KWVND3HNWcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to