Technical Tour-de-Stick

If you are not interested in the technical underbelly of this project, it would be best if you skipped this post. Also, use the information below at your own risk. I've done my best to make sure that it is correct and up-to-date, but there may be places where I'm off-base.

Before I delve into initrd and casper, I figure I'd best post an explanation of the files on the stick. To do this, I'll explain what's on my development stick at present.

I ran the command "find -maxdepth 3" from the root of my stick and pasted the result below. 
I annotated the paste with comments above the file/folder they describe.


#used by syslinux for first-stage booting
./ldlinux.sys
./casper/
#a list of the installed packages
./casper/filesystem.manifest
#a list of the installed packages discounting those used for installation
./casper/filesystem.manifest-desktop
#a compressed, read-only filesystem containing a copy of the O121 image
./casper/filesystem.squashfs
#the initial ramdisk image, compressed. more about this below
./casper/initrd.gz
#the linux kernel
./casper/vmlinuz


#a folder containing an extracted copy of the the initial ramdisk
./casper/initrdMod/
#contains shared files and application libraries used in the boot process
./casper/initrdMod/usr/
#contains the casper boot scripts. This folder deserves(and will get!) its own blog post.
./casper/initrdMod/scripts/
#contains the binaries used in the boot process
./casper/initrdMod/bin/
#contains more esoteric binaries used in the boot process
./casper/initrdMod/sbin/
#contains low-level drivers, libraries, and kernel modules
./casper/initrdMod/lib/
#contains configuration files for the boot process
./casper/initrdMod/conf/
#contains configuration files for the kernel and programs used in the boot process
./casper/initrdMod/etc/
#the main boot script
./casper/initrdMod/init


#the scripts used to extract and rebuild the initrd image
./casper/modScripts/
#gzip -dc ../initrd.gz | cpio -id

./casper/modScripts/extract
#mv ../initrd.gz ../initrd.$(md5sum ../initrd.gz | awk '{print $1}').gz


#find . | cpio --quiet --dereference -o -H newc | gzip -9 > ../initrd.gz
./casper/modScripts/rebuild
#the initial initrd file, kept around for good luck and occasional versioning
./casper/initrd.da1cb8c239c5130882ffa888e128639d.gz
#a previous version of the initrd file
./casper/initrd.5c6912e1d862a9cb67e3e0a833dcc260.gz


./install/
#a version of the Linux kernel designed to test ram
./install/memtest
#smart boot manager - http://linux.simple.be/tools/sbm
./install/sbm.img
#a large file containing an ext3 filesystem, used as a boot-time overlay for persistence 
./casper-rw
#contains misc metadata files
./.disk/
./.disk/base_installable
./.disk/cd_type
./.disk/info
./.disk/release_notes_url
./md5sum.txt
./README.diskdefines
#empty file used to claim this image as an ubuntu derivative
./ubuntu


./syslinux/
./syslinux/boot.cat
#the isolinux bootloader
./syslinux/isolinux.bin
#the isolinux config file - isolinux is called "syslinux" when used on a USB drive
./syslinux/syslinux.cfg


For more information, a full "find" tree of my development drive can be found here. 

Best!

--

Ian

Progress!

Made tons of progress yesterday.

The Main Stick Image

• now boots fully on the Haitian Coalition machines with wonky graphic cards
• doesn't block login on consoles 1-6
• shutsdown cleanly
• doesn't probe the floppy drive on boot

All of these changes were made by modifying the initrd.gz image, except for the graphics issue, which was resolved by disabling 3d hardware acceleration.

I'll be posting the casper hacks I made to the comments section of this blog in the next few days.

The Fastswitch Image

• needs work, but progress is no longer being blocked by the above

The Boothelper Image

• no longer requires userinput to boot, this eliminating any need for USB keyboards to work 

Backup

• was proof-of-concept'ed yesterday as I programatically installed dropbox on a One2One2Go drive with the sync directory set to /home

Keep an eye out for an ISO containing the main-image fixes in the next few days!

Summary of Technical Work

The software for the upcoming pilot with the Haitian Coalition has four main pieces.

 

The Main Stick Image

The software for the stick is largely completed, as the build scripts to create an image from the open1to1 harddrive files have been written. However, there are bugs with our implementation of casper and with the video drivers for the donated computers. The casper bugs are related to casper's autologin and autohardware check. Both of these interfere with a normal use case and slow boot time. 

There are four possible kernel arguments to resolve the driver issues, and the best approach to fixing this problem appears to be a syslinux.conf file which poses all of the options as selectable items. This means I won't have to rebuild every time I want to try a new approach.

The casper problems are more challenging. I haven't found good documentation for the purpose and contents of the scripts involved, and while they're written in BASH, this does not mean they are easy to read. Fortunately, other individuals on the internet have encountered similar problems, and there are some solutions posted. However, due to casper's role in the initial ramdisk image, modifying casper necessitates a lengthy rebuild from scratch.

 

The Fast Switch image.

Luke Faraone and I worked together to design a solution to allow for students to switch between computers in a lab very quickly. The basic premise is that as the students don't have access to modify the stick past their /home directory, a simple over-mounting of the /home from the persistent file should function to allow students to access all the files on their stick in a transparent manner.

For more information, see my notes at on SVN at http://open1to1.org/svn/trunk/build-scripts/fastswitch_notes.txt.

 

The Boothelper image.

As the BIOS of older machines, like many of the P4s we're using in our pilot, don't support booting from USB, some form of alternate bootloader is needed. For this purpose, we're using the "PLOP" Bootmanager, customized to detect USB devices and attempt to boot off them in a mostly-silent manner. The ISO image for this is available here.

One issue with this is that the boothelper does not support USB keyboards. As, in normal operation, no keyboard entry should be needed, this isn't really a problem. However, this makes debugging difficult.

Backup.

The backup solution designed for this pilot is dropbox-based. Keep an eye out for a blog post about that soon!

In other news, the most recent image can be downloaded as an ISO from my sugarlabs page. This file has both Spanish, French, and Haitian creole language packs, as well as a plethora of educational software. The md5sum for this file is f6d8724693c90ac9b2b758b7730a5604.

Best!

--

Ian

Maple Syrup v3 Ready for Download

Hi Guys,

I'm happy to announce the release of v3 of Maple Syrup in ISO format. ISO packaging allows one to use Maple Syrup as a live USB disk or DVD.

The image contains numerous fixes in form and function and will make this Open-1-to-1 / Sugar fusion even more enjoyable to use.

To make a bootable USB stick from an ISO image, follow the instructions contained in section two of the Ubuntu USB Stick Instructions.

Grab the image here. The md5sum of the file is 07d5470e61fe7deefa5507aee5764da7.

Best!

--

Ian

Announcing Maple Syrup Alpha!

The first version of "Maple Syrup" is available!

Built on Release-Candidate 1 of Maine's Open 1-to-1 project and Sugar, the educational software stack maintained by sugarlabs, the Maple Syrup image provides a teacher and classroom tested collection of educational software for grades K-12.

The alpha is available as an ISO image allowing use as a LiveCD or as a bootable, persistent, USB stick. This means you can try it out without making changes to the host computer.

Grab the file here. The MD5 checksum is 0985e4abfebb790d8008b1c82c8b68aa.

When downloading, keep in mind that the ISO is a large file - it may be best to let it run overnight!

As always, feedback and bug reports are appreciated!

Enjoy!

Google for Classroom Collaboration

The OLPC project has proven value to a one-to-one computing approach facilitating collaborative learning. 

Similar projects, from first-world XO deployments, to the open 1-to-1 project in Maine, are following suite. 

The XO's mesh networking and collaboration functionality is buggy at times, but quite useful in a rural setting where infrastructure is unavailable. 

In my life, I have found collaboration to be best done via Google's web apps, with Gdocs and Gwave a staple of my business and scholastic life, providing real-time, multi-media collaboration anywhere with internet. Any document created with Google Docs are automagically stored in the cloud, where they are available for download or remote editing. Taking advantage of these free services makes tons of sense in an educational computing setup.

In stick-based 1-to-1 education, where the kids carry all of their files and programs around on a bootable flash drive, GDocs would provide a full backup in case of loss of stick. Storing editable files in the cloud would also let kids work on school projects, or parents/teachers monitor school projects, from home computers, without needing to boot into the stick OS.

In first-world educational laptop deployments, Google apps act as a "path of least resistance" for collaboration. Rather than having the IT staff install a custom Jabber server, simply configuring Google apps for school use accomplishes very nearly the same goal.

In very small schools or very large schools, Google apps acts as a "path of least resistance" for collaboration. Small schools often lack the resources necessary for internal collaboration servers. Google Apps for Education is free, and easy to set up. For larger institutions, it's a significant strain on internal resources to provide real-time collaboration via traditional methods. Google scales up excellently. 

There are obvious failings with this proposal. Right now, the primary interface for Google Docs is via web browser. In a modern educational setting, the last thing you want your students doing is having a web browser up in a classroom setting. Facebook and Flash games provide a powerful distraction from note-taking and group work.  Also, using a web browser as the primary text processor leads to issues when internet is unavailable.

Fortunately, there are solutions. HTML5, an upcoming web standard, will allow for GDocs to be used offline. Additional coding using the Abiword engine, used in the "Write" activity, with the GDoc API, would produce a platform-and-web-independent word processor with local and cloud file storage.

What do you think? In what other situations would cloud-based collaboration pay off? What sort of scenarios should software like this be designed for?

Open 1-to-1, "Maple Syrup," and customization.

Last Friday saw the conclusion of the FOSSed conference in Bethel, Maine. The conference was a hugely influential experience for the project and provided me with faces to go with three usergroups I've been designing for, Administrators, Students, and Teachers. I have quite a few thoughts I'd like to get on paper.

After my introduction to the Open One-to-One computing project running in Maine, Caroline and I have come to the conclusion that it may serve as an excellent platform to base the USR Bootable Flashdrive off of. With this in mind, I'm helping to evolve the O121 image development system using the LiveCD customization process used by the USR project to create a live O121 flash drive. Nicknamed "Maple Syrup," named after the popular sugar product of New England, this system will serve as a technological tool for K-12 education.

Right now, the Open 1-to-1 image is created manually, by modifying a fresh install of Ubuntu Netbook Remix on the target hardware. This approach produced a disk image implemented in several schools across Maine to great success. While making deployment quite easy, this approach makes virtualization and live-CD / live-USB creation nearly impossible.

To fix this, I found a means of converting the write-to-disk only image provided by O121 into a more useful form. The program Remastersys allows one to create a bootable ISO image from a running Ubuntu system. From a bootable CD ISO, I can use my existing ISO-USB script to create a persistent flash drive install.

As a refinement of the above procedure, I intend to use a few scripts written by David Farning to create a bootable and installable disk image entirely programatically, from scratch. Modifying his shell scripts  for use with the O121 & "Maple Syrup" project will greatly simplify the build process and expand the usability of the resultant image. Alternatively, there exist several alternate procedures to develop a bootable & installable disk image based on an existing LiveCD.

My next step is to flash the most recent O121 image to a spare netbook, install, configure, and run Remastersys, and debug / modify the resultant ISO.