Changes

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

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

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

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.

 

 

The GPA Computers are older and have USB1, thus they may be more likely to have write failures then a faster newer machine?

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