All, The solution is trivial and deceptively so.
With the Pi Zero DISCONNECTED, use Gnome Desktop to edit / add connection to create a connection method with type Ethernet. Leave the mac address fields blank. Pull down tab IPv4 and select "share with other computers " and save / power off. Connect Zero and power on XO. The Pi Zero connection is automatically establish and persists through subsequent boots. Note that the mac fields remain blank. No special configuration for XO is needed. The Raspberry Pi Zero setup is as in the first post. Basic setup -- 'host_addr' and 'dev_addr' are not needed in cmdline.txt . Area's that I might monitor are other connection methods marked to "try to connect on boot" and any changes to mac addresses and "no auto default" in /etc/NetworkManager.conf . Prior practice was to power on XO with Zero connected and the connection method was automatically created with a random mac. If the mac field was changed, a "connection error" would occur. With an Activity to run a script, simple access to the Raspian Desktop should be possible from Sugar. A shout-out to Tony Anderson who may have such an Activity. This should close my request for help with resources. Carrol Riddle > On July 28, 2018 at 3:20 AM James Cameron <qu...@laptop.org> wrote: > > > That's great. I've a Raspberry Pi Zero and XO-1 that I can put > together. Might even be room inside or etch some of the back > plastic. > > On Fri, Jul 27, 2018 at 08:22:43PM -0400, Carrol Riddle wrote: > > All: > > With the possibilities narrowed by James Cameron, found something that > > works repeatedly on my test XO-1. Must test again on a fresh system to > > find minimum configuration. Changes made to correct board id's, udev > > rules, connection method prepared from scratch, and unmanaged mac entry in > > /etc/NetworkManager.conf . > > > > Will post configuration later to close thread (if I can replicate it :) ) > > > > Thanks all for help. > > Carrol Riddle > > > > > > Now, setting MACAddressPolicy to none has no effect, which > > > > suggests the random address is coming from the kernel. > > > > > > > > My guess is that the reason why your udev rpi script fails is that it > > > > is triggered on more than one udev event, or races with other things > > > > for access to the device. Add more logging and debugging to it. > > > > > > > > Reference: > > > > > > > > https://www.freedesktop.org/software/systemd/man/systemd.link.html > > -- > James Cameron > http://quozl.netrek.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
