[Sugar-devel] Reducing Stick Failures - Was Re: [Marketing] press release opportunity...

[James Cameron]

On Fri, Jul 31, 2009 at 08:41:29AM -0400, Caroline Meeks wrote:
> 
> 
> On Fri, Jul 31, 2009 at 8:34 AM, James Cameron <quozl at laptop.org> wrote:
> 
>     I've arrived late.  I've been listening to this discussion for a week.
> 
>     A general comment ... if any state is preserved by the children on the
>     USB sticks, and there is no copy of the state kept elsewhere, and there
>     is a possibility of power failure, premature removal, or other
>     interruptions, then every software component that uses the saved state
>     must be either capable of detecting corruption of the saved state, or
>     graceful recovery from apparently invalid state.
> 
> 
> Nod.
> 
> Note further down on this page backup and file recovery is listed. That is in
> progress.

There's also a risk that a corrupted saved state could be backed up, in
such a way that a restore would return the "system" to a non-working
state.

> Interestingly enough I have seen kids pull the stick out at the wrong
> time and that does not see to correlate with the stick failures based
> on observation not strong data collection.

Yes, I'm worried that the cause may be more complex, and without
analysis we might all be relying on hope.

> I have both working and nonworking sticks.  I could post images of them.
> 
> Can you send me instructions on how to create images from MacOSX?

Sadly, no.  While I have a Mac OS X system here, I don't yet know how to
access a USB device at a raw block level.

However, it is easy for me to explain on Linux:

1.  while the device is not plugged in, identify the last block device
listed in /proc/partitions,

2.  plug the device in, allow five to ten seconds for settling delay,
and identify the new block device listed in /proc/partitions, for
instance it may appear as /dev/sda and /dev/sda1, the former is the
whole device, the latter is the first partition,

3.  copy the data from the whole device, using a compression program,
for instance:

	# gzip < /dev/sda > usb-stick.img.gz

... where you should replace /dev/sda with whatever the result was from
step 2 above.  This creates an image of the whole device, which is
compressed, and can be used for analysis.

The ideal data set would be a working and non-working image from exactly
the same version ... and as small a stick as possible ;-).

-- 
James Cameron
http://quozl.linux.org.au/