Difference between revisions of "Sugar on a Stick/TODO"

From Sugar Labs
Jump to navigation Jump to search
Line 22: Line 22:
 
# Gets stuck at Fedora Login
 
# Gets stuck at Fedora Login
 
## With liveuser prefilled <br>I was able to repeatably create this failure when I was testing a version of schoolserver.py that had a typo in it.
 
## With liveuser prefilled <br>I was able to repeatably create this failure when I was testing a version of schoolserver.py that had a typo in it.
## With nothing prefilled <br> Restarting may precipitate this type of failure.  
+
## With nothing prefilled <br> This error has successfully been replicated by Restarting multiple times.
 
# Bug in initramfs /init detected. Dropping to a shell. Good luck! bash: no job control in this shell. <br> Stick abuse, like putting it through the washing machine, seems to precipitate this type of failure.
 
# Bug in initramfs /init detected. Dropping to a shell. Good luck! bash: no job control in this shell. <br> Stick abuse, like putting it through the washing machine, seems to precipitate this type of failure.
 
# Freezes during use of an activity. Rebooting on the same computer doesn't help it still freezes on the same activity. One time we rebooted on a different computer and it worked.
 
# Freezes during use of an activity. Rebooting on the same computer doesn't help it still freezes on the same activity. One time we rebooted on a different computer and it worked.
Line 31: Line 31:
 
====We need a more robust files system====
 
====We need a more robust files system====
  
Gary's Random Theory - I'm no expert in the live image process but here's my current random theory for the login screen case anyway (to be proven wrong so we can move on please :-) A live image has a kind of overlay file where the actual users changes are being written, if a kid unplugs too early, or hits some other media write issue, that overlay could be corrupted. Likely loosing all user changes to the original base image (and some), the stick would still boot, but bail out when it hits the corrupt overlay. Dropping the user at a login prompt (but with nothing to login to as that part is corrupt). End of random theory.
+
It has been shown that if you take a stick that is stuck at login and you copy over a fedora-overlay file from a working stick, the stick will boot again. Thus we are confident that the problem is corruption of the overlay file.
  
Fedora uses some magical file structure  for their live USBs. Right now no one seems to understand it or be able to find documentation for it.  Right now we have no idea why it was choosen. It seems unlikely that it was optimized for size not robustness.  Its not the only way to do it.
+
''Next Steps'' - Try some alternate file structures.
OpenSuse uses a different file structure that lets you browse the files.
 
  
 +
Create a Fedora Full Install USB Stick, restart it a bunch of times and see if it does better.  How much space will the Fedora Full Install take?
 +
Create an Open Suse USB Stick, restart it multiple times and see if it fails. How much space does it use?
 +
 +
''Background Links''
 
Thread from the Fedora Forum: [[http://forums.fedoraforum.org/showthread.php?t=221719]]
 
Thread from the Fedora Forum: [[http://forums.fedoraforum.org/showthread.php?t=221719]]
  
Line 42: Line 45:
 
Also see Ticket 907 [[http://dev.sugarlabs.org/ticket/907]]
 
Also see Ticket 907 [[http://dev.sugarlabs.org/ticket/907]]
  
A 2 GB USB is about $.60 more then a 1GB stick. If we need to compress less to get robustness its ok for us to require a 2GB USB.
+
A 2 GB USB is about $.60 more then a 1GB stick. If we need to compress less to get robustness its ok for us to require a 2GB USB. A 4GB stick is about $2.50 more then a $1GB Stick.
 +
 
 +
''Theories that have evidence against them''
 +
 
 +
Dave Bauer was able to replicate the failure easily by restarting a Sugar stick. This means its probably not:
  
The GPA Computers are older and have USB1, thus they may be more likely to have write failures then a faster newer machine?
+
* The Bulk Copier, Dave doesn't have one.
 +
* The older slower computers and USB 1 ports we are using at the GPA.
  
 
====Sticks are damaged during formatting or burning====
 
====Sticks are damaged during formatting or burning====

Revision as of 15:08, 30 July 2009

Project Home   ·   Join   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings


Sugar on a Stick Improve Deployability

Make it easier for a teacher or school to customize a spin and then copy it for a hundred kids

Tickets on this topic:

Red Hat - https://bugzilla.redhat.com/show_bug.cgi?id=448030 - RFE: create a bootable Live USB stick from the running livecd SugarLabs Ticket 74 - http://dev.sugarlabs.org/ticket/74

Use Case A teacher should be able to create a USB stick, add activities, add some content, change the language, change the jabber server etc. Then create new sticks that reflect these changes but do not copy the name, color or collaboration key.

It would be great if the teacher could use an inexpensive USB hub to burn more then one stick at a time.

Sticks are dieing a lot - Make sticks more robust

Failure Modes

  1. Gets stuck at Fedora Login
    1. With liveuser prefilled
      I was able to repeatably create this failure when I was testing a version of schoolserver.py that had a typo in it.
    2. With nothing prefilled
      This error has successfully been replicated by Restarting multiple times.
  2. Bug in initramfs /init detected. Dropping to a shell. Good luck! bash: no job control in this shell.
    Stick abuse, like putting it through the washing machine, seems to precipitate this type of failure.
  3. Freezes during use of an activity. Rebooting on the same computer doesn't help it still freezes on the same activity. One time we rebooted on a different computer and it worked.


We don't know the root cause but we have plenty of theories.

We need a more robust files system

It has been shown that if you take a stick that is stuck at login and you copy over a fedora-overlay file from a working stick, the stick will boot again. Thus we are confident that the problem is corruption of the overlay file.

Next Steps - Try some alternate file structures.

Create a Fedora Full Install USB Stick, restart it a bunch of times and see if it does better. How much space will the Fedora Full Install take? Create an Open Suse USB Stick, restart it multiple times and see if it fails. How much space does it use?

Background Links Thread from the Fedora Forum: [[1]]

Here is an idea for an alternative USB Format: [[2]]

Also see Ticket 907 [[3]]

A 2 GB USB is about $.60 more then a 1GB stick. If we need to compress less to get robustness its ok for us to require a 2GB USB. A 4GB stick is about $2.50 more then a $1GB Stick.

Theories that have evidence against them

Dave Bauer was able to replicate the failure easily by restarting a Sugar stick. This means its probably not:

  • The Bulk Copier, Dave doesn't have one.
  • The older slower computers and USB 1 ports we are using at the GPA.

Sticks are damaged during formatting or burning

http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device [[4]]

There was a detailed discussion thread back in February at: http://lists.laptop.org/pipermail/devel/2009-February/022987.html

If we understood how to win and we had our own stick creation activity perhaps we would have less failures.

Sticks are of poor quality

Here is an explanation of two processes used to create USB sticks: http://www.solutiongrove.com/blogger/2008/09/08/there-are-two-type-of-usb-flash-memory-slc-and-mlc [[5]]

Sticks are being improperly removed

Yes they are, but its not at all clear to me that that correlates with the sticks that are failing.

There is a bug around restarting

It is very common to fail after a restart, the system forgets its supposed to go to Sugar. See ticket 1069 [[6]]

Backup and recovery

Ham and Dave from Solution Grove are making progress on this. You can track progress on ticket 916 [[7]]

What is a reasonable expectation for the role of the XS in Sugar on a Stick deployments in the next 6 months?

Collaboration is unreliable and thus frustrating

Its working fairly well in the wired network at the GPA lab, but no other use case seem to work reliably.

Using a CD helper takes a lot of prep time before and after class

A floppy helper would reduce it. A VM solution might also reduce it.

Tickets

* Ticket 598   Boot Helper Virtual Machine [[8]]
* Ticket 907  change the format we use for the USB stick [[9]]
* Ticket 597 Floppy Boot Helper [[10]]


See also Sugar on a Stick/Goals.

This is an the general todo list for SoaS. If you've any ideas or requests, please add them here.


Task Name Priority Status/Notes
solicit USB key donations from companies 1 info needed
allow direct recreation of USB keys (cloning) 2 needs testing [11]
add additional activities, if requested 3 get them on a.sl.o
work on a keyboard layout control panel 3 work in progress [12]
be able to backup and restore from a School Server 3 to be worked out
support printers, scanners, cameras 3 to be worked out
activity for cloning USB Sticks and .iso files (cloning) 3 to be worked out [13]

Here's a list with completed tasks; feel free to move them from the table above.

Task Name Status/Notes
get SoaS included in liveusb-creator done
create a virtual appliance (builds) done [14] [15]
release a helper CD for boot from USB done [16]
add sample content done - add more if needed
fix blockers for release most important point, check rawhide, as it progresses towards beta
update remaining RPMs good progress done so far
check localization support done
get artwork and branding together done
change default Browse location done