Re: Reflashing over a network
Has anyone tested the fix to #12740 for installing over network? -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reflashing over a network
On Thu, Aug 29, 2013 at 11:52:48AM -0400, Kevin Mark wrote: > My one attempt to use Nandblast made me realize that even in a > developed country, you needed N power outlets to flash N XOs, and > the room I was in at the time had like 3 outlets and thus, it was > not possible to use it for more. (Unless I missed something) You're probably missing that you don't need a power outlet most of the time; you're conflating the release notes recommendations to developers and individual users with the process that would be used by a deployment. A NANDblaster party should use battery power most of the time. This is how I do it. If any laptops show red battery indicator, they can be selected for extra powering. It safe for a laptop to power off during NANDblaster; but it has to be started again. The only reason for needing external power is to commit a firmware upgrade, but we made this upgrade so safe that the child can experience it instead. I don't think there have been any OLPC OS releases made that _require_ a firmware upgrade to complete before the first boot, but if there are it should be in the release notes. Laptops are shipped with batteries holding a charge. If the laptops have been stored for a long time, or have been in use by children, yes, the NANDblaster party would need to include some charging. Depending on the state of charge distribution across the population, this _might_ make the party longer. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reflashing over a network
(another composite reply) On Thu, Aug 29, 2013 at 10:45:29AM +0200, Tony Anderson wrote: > I believe the 'boot net' would require only moments more per laptop > than the 4-key approach. Yes, about 10 seconds, but the laptop would have to be unlocked. Also an added benefit of testing the b, o, o, t, space, n, e, and enter keys on the laptop. > The real advantage of wireless 'flashing' could be that a roomful of > laptops could be flashed concurrently as in NandBlast. I assume that > NandBlast is using the broadcast capability of the network. This is > getting beyond my understanding of networking, but wouldn't it be > possible to implement the 'sender' side of NandBlast on the server > and have it start broadcasting the image. Yes. However, there's no protocol for asking for the broadcast, the broadcast has to be already happening. If you consume one wireless channel at the site for this broadcast, that's one less channel you can use for collaboration and other client services. On Thu, Aug 29, 2013 at 10:45:29AM -0400, Richard A. Smith wrote: > Again I'm hazy on the current state of nandblaster so someone else > will have to tell you how much effort is needed in the XO firmware > to make that something that might be compatible with an XS > broadcaster. Could probably be done for XO-1.5, XO-1.75 and XO-4. The code is in C, in the multicast-nand git repository. It would need a week or two. I really don't think it is a good idea, because I can't imagine wanting to consume that server connected radio spectrum for something that rare. (A NANDblaster party can happen away from the server connected access points, using one of the laptops being deployed.) On Thu, Aug 29, 2013 at 05:26:51AM -0500, Jerry Vonau wrote: > On Thu, 2013-08-29 at 18:19 +1000, James Cameron wrote: > > On Wed, Aug 28, 2013 at 03:52:46PM +0200, Tony Anderson wrote: > > > This is getting interesting but I am still not sure I understand > > > the process. > > > [...] > > > There is an alternative via > > > > > > boot net > > > > > > which invokes a different firmware process that is working in > > > all XO models. This process uses tftp. The server would respond > > > to a tftp request from the XO by sending the fs.zip and .img > > > files. > > Is tftp used just to retrieve the fs.zip file? No. For "boot net", the firmware opens the network, then uses TFTP to GET a file named OLPC. This is a Forth script. It can do what it likes. I guess you might use a Forth script inside an fs.zip file, but I don't see why that would be necessary. Typically, the Forth script would then use HTTP, FTP, CIFS, or NFS for the next step. > Is there a speed advantage over http with tftp? Given the data fetched with TFTP is tiny, the size of a script, I don't understand why you ask. Perhaps you thought the bulk of the data would be fetched using TFTP, but it would not necessarily be so. TFTP is faster than HTTP for small files, because the number of network packets exchanged is smaller. HTTP is faster than TFTP for large files, because there can be multiple packets in flight. TFTP might not saturate a shared network as much as HTTP. Open Firmware uses TFTP for "boot net" because of requirements prior to OLPC. > > No point, 'cause the time you waste getting a Forth program into > > the laptop is better spent getting the install data into the > > laptop. > > The old recipe called for NN PP tags to be added that to OFW, not > needed if you use OLPCOFW now. I'm confused by the context. In the absence of a USB ethernet adapter, and the absence of NN and PP tags, the firmware uses the SSID of OLPCOFW. Otherwise it uses the SSID from the NN tag, and an optional WPA passphrase from the PP tag. > > Yes. It works here, I just tried it with Q4D34JE with the web > > server on 172.18.0.1 loaded with 32013o2.zd and fs2.zip. > > 172.18.0.1 would need to be available/aliased on the server for this > as that is coded as the default for the http transfer? Yes. In try-fs-update. Either DHCP needs to hand out addresses in 172.18.x.x, or 172.18.0.1 needs to be routable by the host that owns the default route. I added an alias to the host that is my DHCP server. > In contrast tftp would rely on the DHCP server for the server to > contact and doesn't have this limitation. That's one way to put it. Another way is: Use of TFTP requires a DHCP server and a TFTP server. Using an HTTP server configured for 172.18.0.1 doesn't have this limitation. > > > suppose if we craft an olpc.fth script to setup the wifi > > > networking that could be used in place of the 4 button boot? > > > > I don't understand the question, sorry. > > > > I'm was just wondering if we can override what is defined in > firmware by booting a usb flashdrive with the same commands that you > would use for initializing the wireless for example flashing of > firmware. I mean setting of the SSID(MM), wep/wpa(PP), that sort of > thing. Much easier to just configure an open access p
Re: Reflashing over a network
Hi James, On Thu, 2013-08-29 at 18:19 +1000, James Cameron wrote: > On Wed, Aug 28, 2013 at 08:53:33AM -0400, Tim Moody wrote: > > I have been interested in this approach for some time, but was told > > that the XO boot process that looks for a particular network name or > > SSID is not implemented on recent XOs. Bug or design choice, what > > is the likelihood that this will be an option going forward? > > It was a bug. It is now fixed. It is 95% likely to be "an option > going forward", but you must upgrade the firmware on XO-1.5, XO-1.75 > or XO-4. See below for the upgrade. Sorry I've known about the different behaviours since I've been involved. Didn't know that it was considered a bug, just a reduced feature set in favour of NANDBlaster is what I thought when I first got involved. Didn't want to upset the apple cart. > On Wed, Aug 28, 2013 at 03:52:46PM +0200, Tony Anderson wrote: > > This is getting interesting but I am still not sure I understand the > > process. > > > > As I understand it, the XO will attempt to download the > > > > fs.zip (appropriately named) > > > > and then the > > > > os.img > > > > from 172.18.0.1 using http protocol. > > Yes. > > > However, this currently only works for XO-1 because of a bug in the > > firmware. > > Yes. The bug number is #12740, and the fixes are available in > > http://dev.laptop.org/~quozl/q3c16je.rom > http://dev.laptop.org/~quozl/q4d34je.rom > http://dev.laptop.org/~quozl/q7b37je.rom > > > There is an alternative via > > > > boot net > > > > which invokes a different firmware process that is working in all XO > > models. This process uses tftp. The server would respond to a tftp > > request from the XO by sending the fs.zip and .img files. > > Is tftp used just to retrieve the fs.zip file? Is there a speed advantage over http with tftp? > No point, 'cause the time you waste getting a Forth program into the > laptop is better spent getting the install data into the laptop. > The old recipe called for NN PP tags to be added that to OFW, not needed if you use OLPCOFW now. > Yes. It works here, I just tried it with Q4D34JE with the web server > on 172.18.0.1 loaded with 32013o2.zd and fs2.zip. > 172.18.0.1 would need to be available/aliased on the server for this as that is coded as the default for the http transfer? In contrast tftp would rely on the DHCP server for the server to contact and doesn't have this limitation. > > I can't seem to find /packages/obp-tftp on dev.laptop.org/git/. In Lession 12 Automatic Net Booting refers to obp-tftp, I miss-took that as a different/separate project, it's a sub-package build into OFW. > I > > suppose if we craft an olpc.fth script to setup the wifi networking > > that could be used in place of the 4 button boot? > > I don't understand the question, sorry. > I'm was just wondering if we can override what is defined in firmware by booting a usb flashdrive with the same commands that you would use for initializing the wireless for example flashing of firmware. I mean setting of the SSID(MM), wep/wpa(PP), that sort of thing. Much easier to just configure an open access point with OLPCOFW. > Here's what happens if the four game key boot method is used: > > In the absence of USB drive, SD card, or a nearby NANDblaster, the > firmware will open the network, which means one of either: > > - initialise the USB ethernet device, or > > - associate with either OLPCOFW or the SSID identified by the NN tag, > > and then send an HTTP GET to 172.18.0.1 asking for the file fsN.zip, > which it then validates against the security system, before executing > it as normal as if it had been found on USB drive. > I take it this would be for signed build only or can the image be unsigned if the XO is unlocked? Thank you for the detailed explanation, Jerry ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Reflashing over a network
Warning: this is a composite reply to many people, with context, so read to the bottom. There are several methods to reflash; USB drive, SD card, wireless, and USB ethernet. These methods vary in how fast they are, how well they scale, what equipment is needed, and what expertise is required. Think about the problem; you have between 512 MB and 1 GB of data to move from outside the laptop to inside the laptop. Regardless of where it comes from, it will take about five minutes to write the data to the internal storage of the laptop. The internal storage is not as fast as a hard drive. Now, where does the data come from? An SD card or USB drive is usually the fastest, hence the typical five minutes. All other reflash methods _will_ be slower. Wireless reflash should only be considered if there is wireless spectrum available (e.g. school's out), and there's some advantage to doing it (e.g. quantity of laptops much greater than quantity of USB drives). Not having enough USB drives is a good reason to select wireless. (e.g. theft, resource limitations). Wired reflash should only be considered if there is wired access available. NANDblaster outperforms HTTP because there is no reverse data channel. NANDblaster performs poorly in a noisy environment. On Wed, Aug 28, 2013 at 08:53:33AM -0400, Tim Moody wrote: > I have been interested in this approach for some time, but was told > that the XO boot process that looks for a particular network name or > SSID is not implemented on recent XOs. Bug or design choice, what > is the likelihood that this will be an option going forward? It was a bug. It is now fixed. It is 95% likely to be "an option going forward", but you must upgrade the firmware on XO-1.5, XO-1.75 or XO-4. See below for the upgrade. On Wed, Aug 28, 2013 at 03:52:46PM +0200, Tony Anderson wrote: > This is getting interesting but I am still not sure I understand the > process. > > As I understand it, the XO will attempt to download the > > fs.zip (appropriately named) > > and then the > > os.img > > from 172.18.0.1 using http protocol. Yes. > However, this currently only works for XO-1 because of a bug in the > firmware. Yes. The bug number is #12740, and the fixes are available in http://dev.laptop.org/~quozl/q3c16je.rom http://dev.laptop.org/~quozl/q4d34je.rom http://dev.laptop.org/~quozl/q7b37je.rom > There is an alternative via > > boot net > > which invokes a different firmware process that is working in all XO > models. This process uses tftp. The server would respond to a tftp > request from the XO by sending the fs.zip and .img files. > > I am not familiar with tftp. Server-side, I would assume the > necessary files would be in a known directory (e.g. /library/xo-1.5) > and the XO would request 'get' on the files. Yes. > Does tftp from the XO also address 172.18.0.1? No. It addresses the boot server identified by the DHCP server, or if no boot server is identified it attempts TFTP against the DHCP server. (Reminder: this is the manual "boot net" scenario, not the automatic four game key boot scenario). On Wed, Aug 28, 2013 at 10:46:05AM -0400, Tim Moody wrote: > Tony Anderson wrote: > >There is an alternative via > > > >boot net > > > >which invokes a different firmware process that is working in all > >XO models. This process uses tftp. The server would respond to a > >tftp request from the XO by sending the fs.zip and .img files. > > > > to be clear, this command must be issued by the user after a 4 > button boot lands in the firmware? No. > could Jerry's forth module do it? No point, 'cause the time you waste getting a Forth program into the laptop is better spent getting the install data into the laptop. On Wed, Aug 28, 2013 at 11:46:15AM -0500, Jerry Vonau wrote: > James, > If you use a usb cat 5 network dongle, would that be auto detected > in place of using wifi? Yes. It works here, I just tried it with Q4D34JE with the web server on 172.18.0.1 loaded with 32013o2.zd and fs2.zip. > I can't seem to find /packages/obp-tftp on dev.laptop.org/git/. I > suppose if we craft an olpc.fth script to setup the wifi networking > that could be used in place of the 4 button boot? I don't understand the question, sorry. Here's what happens if the four game key boot method is used: In the absence of USB drive, SD card, or a nearby NANDblaster, the firmware will open the network, which means one of either: - initialise the USB ethernet device, or - associate with either OLPCOFW or the SSID identified by the NN tag, and then send an HTTP GET to 172.18.0.1 asking for the file fsN.zip, which it then validates against the security system, before executing it as normal as if it had been found on USB drive. On Wed, Aug 28, 2013 at 12:07:46PM -0500, Anna wrote: > A few years ago, I experimented with flashing an XO-1 over the > network from my XS 0.6. I named the AP "OLPCOFW" and put the .img > and fs.zip files in the document root of
