Enable recovery or installation from school server or another laptop

[jg]

OFW can now use the Marvell wireless hardware to boot or potentially install an image.

We need two abilities:

1. fresh installation from the school server
2. installation from another existing laptop

The second requirement is so that a laptop can be recovered if a child is no where near a school, say, on vacation.

Exactly what the best way to achieve these ends is TBD.

[wmb@…]

If the school server were running an NFS server, you could do:

ok copy-nand nfs:\nandXXX.img

That should work right now. The school server would have to respond to DHCP requests from the laptops.

Installing from another laptop would be a bit trickier. If the good laptop had additional mass storage, you could do the NFS thing. But if we assume it has to be a base-case XO with nothing extra, the best you could do is clone its NAND image into the other XO. Cloning an active JFFS2 filesystem would be dodgy, so you would either have to use a kernel that is running completely from RAMdisk, or else use OFW.

OFW does not have an NFS server, but it can serve HTTP. We could fiddle with the OFW HTTP client so that copy-nand could stream from HTTP to NAND, and set up an HTTP server on the good XO to dole out its NAND image. We would have to work out some sort of rendezvous mechanism. Maybe when you start the server it could display some sort of rendezvous key.

Afterwards, the cloned XO would have to do something to erase the personalization info (host keys, user files, etc) that it inherited. Perhaps that could be added to the Linux startup scripts, so that the system would re-personalize if the serial number doesn't match the one it was first personalized on.

[wmb@…]

Reassigning to Mitch for tracking purposes.

[wmb@…]

This isn't going to make the B4 cut; we don't have a clear enough spec yet.

[jg]

There is another solution here: use a more typical bootp request and load an initrd with a system that does the heavy lifting. We've already been working on this for/with Quanta manufacturing. The feature of doing it there rather than in OFW is we can do some serious high performance crypto easily; the tools are much easier and don't have to be done ourselves.

It is the case I'd like to see soup-to-nuts installation via wireless possible via wireless network. The logistics in the field of USB keys or USB wires, or anything else, seems very poor.

I'm making this a blocker against Trial-3 to ensure we discuss and plot a strategy.

[wmb@…]

Current releases of OFW (q2c20 and later) support copy-nand from http.

We can add an OFW feature whereby, if the user holds down a particular game key, OFW will do a copy-nand from a default URL, e.g. http:\\schoolserver\olpcnand.img

The schoolserver will need to respond to DHCP requests, supplying a client IP address and a nameserver IP address. The nameserver will need to resolve the name "schoolserver" with the IP address of a web server that contains the file "olpcnand.img".

The final issue is the wireless SSID. OFW currently has a built-in default SSID of "OLPCOFW". We can either make the schoolserver respond to that SSID, or add something in the manufacturing data that tells OFW the SSID of the schoolserver that it is assigned to, or invent some search heuristic for choosing an SSID from the access points that are available.

[dwmw2]

http:\\schoolserver\olpcnand.img isn't a URL. Please use forward slashes for this.

How much more work is needed in OF before we can do this over IPv6 instead of IPv4? And/or use the mesh instead of infrastructure mode?

[wmb@…]

Replying to dwmw2:

http:\\schoolserver\olpcnand.img isn't a URL. Please use forward slashes for this.

The backslashes don't appear on the wire; in the HTTP GET request, they appear as forward slashes. The backslashes appear only internally within OFW code, and in this case, the user will never see them.

As I have stated many times, changing OFW to use forward slashes in the filename part of device specifiers is a wide-ranging and dangerous change that I am not willing to undertake.

How much more work is needed in OF before we can do this over IPv6 instead of IPv4?

We are probably pretty close to being able to use IPv6 on a local network. We will have a preliminary version for testing within a few days.

And/or use the mesh instead of infrastructure mode?

I don't know enough about the mesh to answer that one yet.

[gregorio]

Is this really a blocker for 8.2.0?

If so, can we get a design proposal and lead customer ASAP?

If not please reset the target release and add it to the 9.1.0 tracking page at: <br> http://wiki.laptop.org/go/9.1.0#Priorities_from_Engineering