[Server-devel] XSCE Sprint

Tony Anderson tony at olenepal.org
Wed Jul 10 04:11:14 EDT 2013


Hi,

Thanks for the update.

The 'locked' XO problem derives from XOs distributed in the minimum 100 XO
purchase - many of these are locked. Also, in Rwanda the policy is to 
keep the laptops locked even though they have indefinite leases.

My current plans are to visit these schools in December and so I may be 
able to get them unlocked then.

What I would really love is a 'Nandblast' capability in the firmware 
that gets it's image from the schoolserver. That probably would work 
(how does an XO know an image is coming over wifi from an XO or a school 
server?).

The normal flash problem is that several XOs need to be reflashed at one 
time, so the usb key approach is time-consuming. My experience is that a 
reflash from usb key takes 15min. Naturally, one key to this process is 
the ability to reload the backed up (hopefully) Journal.

Tony


On 07/10/2013 10:02 AM, James Cameron wrote:
> On Wed, Jul 10, 2013 at 09:33:29AM +0200, Tony Anderson wrote:
>> The flash level needs to be handled by the firmware. I believe the
>> firmware is capable of obtaining the image from a network. This is
>> where the 'lock' is invoked so the trick will be to find out how to
>> do this for locked XOs.
> Yes, the firmware is capable of obtaining an image from wireless or
> USB ethernet, but this is not a very efficient use of time.  A USB
> drive easily outperforms network reflash.
>
> To do it for locked XOs requires signing the build with your
> deployment keys, and honestly we haven't tested secure network reflash
> feature for a long time, so the community should test it before
> recommending it.  If I recall correctly, it was not in scope for
> XO-1.75 and XO-4 engineering.
>
> (p.s. I salute the bravery of any deployment that uses locked XOs
> without a deployment key injected on the laptops ... but I recommend
> that this be avoided because of the numerous pitfalls ... ensure a
> deployment key is injected, or unlock the laptops).
>



More information about the Server-devel mailing list