Thanks Martin.<br><br>This REALLY is a useful mail. Thanks.<br><br>My comments inline.<br><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 8:50 PM, Martin Abente <span dir="ltr"><<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Probably the answer is that the start() method is not executed, which means there are different execution paths between reboot and resume.<br> </blockquote><div><br>Me thought the same. Thanks for the affirmation.<br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Same happened with powerd, we had to include the script I mentioned in the previous response, _maybe_ there is something similar to the powerd postresume.d in NM...<br> </blockquote><div><br>Thanks a ton for this light.<br>I will look up into it; and will get back to you.<br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>In any case, IIRC there was supposed to be a driver patch that would replace all these hacks for disabling the mesh (for good). Any clue what happened with it?<br></blockquote><div> </div><div>Well, that would be the ultimate cleanest solution.<br> However, I believe that is not present, since the issue is happening anyways.<br><br><br>Ccing dextrose.<br><br><br>Thanks again.<br><br><br>Thanks and Regards,<br>Ajay<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div class="gmail_quote"><div><div class="h5">On Tue, May 1, 2012 at 4:55 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">which actually brings me back to my original question ::<br><br>"""<br> Why is it so that putting the 'disable-mesh-script' in the 'start()' method of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works for resume-upon-suspend?<br> """<br><br><br>Regards,<br>Ajay<div><div><br><br><div class="gmail_quote">On Tue, May 1, 2012 at 8:07 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Paul.<br><br><div class="gmail_quote"><div><div>On Tue, May 1, 2012 at 8:03 PM, Paul Fox <span dir="ltr"><<a href="mailto:pgf@laptop.org" target="_blank">pgf@laptop.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><div>ajay wrote:<br> > Any ideas please, regarding the two latest queries :) ?<br> ><br> > Regards,<br> > Ajay<br> ><br> > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>> wrote:<br> ><br> > > Thanks Martin and Jon for the replies.<br> > ><br> > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <<a href="mailto:jon.nettleton@gmail.com" target="_blank">jon.nettleton@gmail.com</a>>wrote:<br> > ><br> > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente<br> > >> <<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</a>> wrote:<br> > >> > Are you guys still using this?<br> > >> ><br> > >><br> > <a href="http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post" target="_blank">http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post</a><br> > resume.d/disable_mesh.sh<br> > >> ><br> > >> > If so, you should remove it IF there is no way to guarantee that it<br> > >> will run<br> > >> > before NM picks up the device. At least it will avoid the crash...<br> > >> ><br> > >> > I would ask in the NM community if there is a better way to disable a<br> > >> > particular device, like banning a device(?).<br> > >><br> > >> Edit /etc/NetworkManager/NetworkManager.conf<br> > >><br> > >> Add a line to the [main] section like<br> > >><br> > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the<br> > >> mac-address of your mesh device.)<br> > >><br> > ><br> > ><br> > > This should be a lot cleaner solution.<br> > > However, two queries ::<br> > ><br> > ><br> > > a)<br> > > Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"<br> > > (no mesh device listed).<br> > > So, how can the mac address for the mesh device be found?<br> <br> </div></div>it's the same as that for eth0.<br></blockquote></div></div><div><br>Does that mean, that banning eth0-mac-address prevent the loading of wifi-hardware-device as well (in obvious addition to mesh) ?<br>This seems very pricky.<br> <br><br><br> </div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><br> > > b)<br> > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?<br> <br> </div>of course not. how would they tell one another apart?<br></blockquote></div><div><br>Alright.<br>But my first doubt (same mac address for mesh-hardware and wifi-hardware) has put me in topspin :~<br><br><br><br>Regards,<br> Ajay<br><br> </div><div><div><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> paul<br> <div><br> > ><br> > ><br> > > Looking forward to a reply.<br> > ><br> > ><br> > ><br> > > Thanks and Regards,<br> > > Ajay<br> > ><br> > ><br> > ><br> > >><br> > >> This does not stop NM from managing your device, but does stop it from<br> > >> auto-connecting the device. You would still be able to go into NM and<br> > >> manually enable the mesh network. If you want NM to completely leave<br> > >> the device alone you can go one more step.<br> > >><br> > >> Also in /etc/NetworkManager/NetworkManager.conf<br> > >><br> > >> change the plugins line to<br> > >><br> > >> plugins=ifcfg-rh,keyfile<br> > >><br> > >> Then add a section that looks like this.<br> > >><br> > >> [keyfile]<br> > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address<br> > >> of the device you want to ignore)<br> > >><br> > >><br> > >> Hope that helps, let me know if you have further questions.<br> > >><br> > >> -Jon<br> > >><br> > ><br> > ><br> </div> > part 2 text/plain 129<br> <div> > _______________________________________________<br> > Devel mailing list<br> > <a href="mailto:Devel@lists.laptop.org" target="_blank">Devel@lists.laptop.org</a><br> > <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br> <br> </div>=---------------------<br> paul fox, <a href="mailto:pgf@laptop.org" target="_blank">pgf@laptop.org</a><br> </blockquote></div></div><br> </blockquote></div><br> </div></div><br></div></div>_______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> <br></blockquote></div><br> </blockquote></div><br>