Re: Getting an XO connected to WLAN from commandline
Martin Langhoff mar...@laptop.org writes: If you are working on an XO from serial port or the commandline, and you want to drive NetworkManager to connect to your WLAN without using X, here's what you can do. [...] It's probably worth noting that you only have to jump through all these hoops for NM = 0.8 / Sugar = 0.94. For NM 0.9 / Sugar 0.96+ all you need to do is: nmcli con up id 'essid' Or if you inherited the connection settings from a pre-0.96 Sugar installation: nmcli con up id 'Auto essid' You can list the available connection settings with: nmcli con list Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpiq7FPQReUf.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Getting an XO connected to WLAN from commandline
On Wed, Aug 22, 2012 at 2:27 AM, Sascha Silbe si...@activitycentral.com wrote: It's probably worth noting that you only have to jump through all these hoops for NM = 0.8 / Sugar = 0.94. For NM 0.9 / Sugar 0.96+ all you need to do is: nmcli con up id 'essid' Hmmm? Freshly installed 12.1.0 ... bash-4.2# ls /etc/NetworkManager/system-connections/ bash-4.2# rpm -qi NetworkManager Name: NetworkManager Epoch : 1 Version : 0.9.4.0 Release : 9.git20120521.fc17 Architecture: armv7hl (...) bash-4.2# nmcli con up 'olpc' Unknown parameter: olpc Error: id or uuid has to be specified. bash-4.2# nmcli con up id 'olpc' Error: Unknown connection: olpc. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Tue, Aug 21, 2012 at 4:06 PM, Jerry Vonau jvo...@shaw.ca wrote: While working with Australia, we have found the need to have the AC plugged-in for a firmware update while not requiring AC for a image upgrade to be problematic in the field. You can start an OS upgrade then run out of battery leaving a incomplete upgrade, while an AC adaptor may not always be available to use while your employing charging racks. We make our signed firmware available for download outside of the image, to enable the firmware to be installed from a USB drive before updating the OS. We disable the AC check and force a minimum 50% battery level before either actions can occur with our custom olpc.fth script which is part of our One Education USB[1] project. To my knowledge we have not bricked any XOs in the field using this method. Is this driven because your OS update process is not resilient to power failure? Either way, I don't quite understand the situation involving the firmware here. (Maybe until now) there has been no driving need to upgrade firmware when upgrading OS releases - it can be done before, after, 3 weeks after, doesn't make a big difference. Or is there a reason I'm missing for why you go to special lengths to make sure the firmware upgrade is done first? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Wed, 2012-08-22 at 09:53 -0600, Daniel Drake wrote: On Tue, Aug 21, 2012 at 4:06 PM, Jerry Vonau jvo...@shaw.ca wrote: While working with Australia, we have found the need to have the AC plugged-in for a firmware update while not requiring AC for a image upgrade to be problematic in the field. You can start an OS upgrade then run out of battery leaving a incomplete upgrade, while an AC adaptor may not always be available to use while your employing charging racks. We make our signed firmware available for download outside of the image, to enable the firmware to be installed from a USB drive before updating the OS. We disable the AC check and force a minimum 50% battery level before either actions can occur with our custom olpc.fth script which is part of our One Education USB[1] project. To my knowledge we have not bricked any XOs in the field using this method. Is this driven because your OS update process is not resilient to power failure? No, once upon a time the official OLPC upgrade process was not resilient to power failures[1][2]. Either way, I don't quite understand the situation involving the firmware here. (Maybe until now) there has been no driving need to upgrade firmware when upgrading OS releases - it can be done before, after, 3 weeks after, doesn't make a big difference. Yes it did at one point, way back when sparse support was first added to the .zd files in order to gain the speed advantage offered the required firmware must be installed first. Or is there a reason I'm missing for why you go to special lengths to make sure the firmware upgrade is done first? After an OS upgrade we can't expect a teacher to boot each XO with an AC adapter plugged-in when there maybe only one adaptor available for the class or no AC at all because of the use of alternate charging methods. I wonder how this is handled in other deployments that are using solar-panels or hand cranks because there is no AC available. We have chosen to have the firmware installed from a USB drive as we can disable the AC check, and use the charge level of the battery to ensure there is enough power present to ensure success with the updating processes with our olpc.fth script. Jerry 1. http://lists.laptop.org/pipermail/devel/2012-April/034836.html 2. http://dev.laptop.org/ticket/11776 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On 23 August 2012 09:00, Jerry Vonau jvo...@shaw.ca wrote: On Wed, 2012-08-22 at 09:53 -0600, Daniel Drake wrote: Either way, I don't quite understand the situation involving the firmware here. (Maybe until now) there has been no driving need to upgrade firmware when upgrading OS releases - it can be done before, after, 3 weeks after, doesn't make a big difference. Yes it did at one point, way back when sparse support was first added to the .zd files in order to gain the speed advantage offered the required firmware must be installed first. We also wanted an easy way to get NANDblaster-compatible firmware out to all of our XOs in the field. As the first adopters of the XO-1.5, we had many units that could not receive a NANDblaster signal. We don't issue firmware updates very often at all. Or is there a reason I'm missing for why you go to special lengths to make sure the firmware upgrade is done first? After an OS upgrade we can't expect a teacher to boot each XO with an AC adapter plugged-in when there maybe only one adaptor available for the class or no AC at all because of the use of alternate charging methods. I wonder how this is handled in other deployments that are using solar-panels or hand cranks because there is no AC available. We have chosen to have the firmware installed from a USB drive as we can disable the AC check, and use the charge level of the battery to ensure there is enough power present to ensure success with the updating processes with our olpc.fth script. We use charging racks for classroom sets, not individual AC adapters. It is not practical to boot/use the XO while it is plugged in. Hence, firmware updates cannot occur if AC is required. Our workaround is to remove the AC check and institute a battery check. We understand that there are risks involved in this (e.g. the reported battery state may be different from the actual state), we decided that the benefits outweigh the risks. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Wed, Aug 22, 2012 at 06:00:21PM -0500, Jerry Vonau wrote: Yes it did at one point, way back when sparse support was first added to the .zd files in order to gain the speed advantage offered the required firmware must be installed first. That's not how I remember it. Sparse support worked but generated a minor warning. You wanted the firmware upgrade to avoid the warning. You might instead have suppressed the warning. http://wiki.laptop.org/go/User:Quozl/fs-update-skip-unused-blocks#Existing_Builds After an OS upgrade we can't expect a teacher to boot each XO with an AC adapter plugged-in when there maybe only one adaptor available for the class or no AC at all because of the use of alternate charging methods. I wonder how this is handled in other deployments that are using solar-panels or hand cranks because there is no AC available. We have chosen to have the firmware installed from a USB drive as we can disable the AC check, and use the charge level of the battery to ensure there is enough power present to ensure success with the updating processes with our olpc.fth script. We know the battery state of charge may be unreliable under certain conditions, and that's one reason why we also require external power, as well as a minimum voltage and charge state. I'm glad you've taken on that risk, but not all deployments have such a high level of technical support and literacy. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
