301
edits
Changes
Jump to navigation
Jump to search
Line 22:
Line 22: − + − + Line 31:
Line 31: − + − + + + Line 43:
Line 45: + +
→Sticks are dieing a lot - Make sticks more robust
# 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> Restarting may 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.
# 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 doesn't help it still freezes on the same activity
# 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====
Fedora uses Squashfs file structure [http://en.wikipedia.org/wiki/SquashFS] for their live USBs. This is optimized for size not robustness.
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.
OpenSuse uses a different file structure.
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.
OpenSuse uses a different file structure that lets you browse the files.
Here is an idea for an alternative USB Format: [[http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format]]
Here is an idea for an alternative USB Format: [[http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format]]
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device [[http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device]]
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device [[http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device]]
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.
If we understood how to win and we had our own stick creation activity perhaps we would have less failures.