Sugar on a Stick/TODO: Difference between revisions

Line 22:

# 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 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.

# 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:

====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]]

Line 42:

Line 45:

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====

@@ Line 22: / Line 22: @@
 # 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 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.
 # 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====
-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]]
@@ Line 42: / Line 45: @@
 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====