Running ChromeOS District Wide

[ This is a guest post from Dan O’Boyle, who I met at a LOPSA-NJ meeting. I asked him to do a guest post about this subject because I thought the project was something other schools would find useful ]

I’m a systems engineer for a moderately sized school district in NJ.  We own a number of different devices, but this article is specifically about the AcerOne line of netbooks.  I was recently tasked with finding a way to breath new life into about 500 of these devices.  The user complaints on using these models ranged from “constant loss of wireless connectivity” to the ever descriptive “slow”.  The units have 1 gig of ram, and our most recent image build had them domain joined, running windows 7N 32bit.  

These machines were already running a very watered down Windows experience.  I considered what the typical user experience was - They would boot the device, login to windows, login to Chrome (via Google Apps for Education accounts) and then begin their browsing experience.  Along the way they would lose wireless connection (due to a possibly faulty Windows driver), experience CPU and memory bottlenecks due to antivirus and other background windows processes, and generally have a bad time.  The worst part was I couldn’t see a way to streamline this experience short of removing windows.  It turns out that was exactly the solution we needed.

Chromium OS is the open source version of Google’s ChromeOS operating system. The project provides instructions on how to build your own distro and a fairly responsive development community.  Through the community, I was able to find information on 2 major build distributors - Arnold the bat and Hexxah.  Hexxah’s builds seem to get a bit less attention than Arnolds, so after testing both I decided to use one of Arnolds most recent builds.

The AcerOnes took the build without issue.  A few gotcha’s to be aware of are hard drive size, unique driver needs and method of deployment.  Before I describe those problems, I’ll need to explain a bit about our planned method of deployment.

Individual Device configuration:

Configuring the OS on one device took about an hour from download to tweaking.  After copying the build to a USB stick, I installed it to the local HDD of my AcerOne.  I noticed that the wireless card was not detected by default.  This is typically due to a driver issue, and can often be solved by adding drivers to the /lib/firmware directory.  With the wireless card up and running, I added flash/java/PDF/mp3 support with this script (Note that the script is listed to work with Hexxah’s builds but also works with Arnolds.  The default password on arnold’s builds is password.)

Deployment:

Finally, I was ready to try cloning my machine to distribution.  My first successful attempt was using Clonezilla to make a local Clonezilla repo to USB.  This was effective, but it wasn’t pretty.  To distribute this build out to multiple buildings I needed to boot the ISO created by clonezilla over PXE, and given that some of my AcerOnes had 2gig of ram, and some only had 1 many of the devices wouldn’t be able to load the ISO locally into RAM to perform the install.

The next attempt I made was using FOG.  FOG was able to capture the image and store it on a PXE server.  FOG boots machines into a small linux kernel, then issues commands through that kernel to perform disk operations.  This method would work even on my 1gig machines.  At this point I discovered the hard disk problem mentioned earlier. I had originally build my image on a 250gig HDD.  some of my machines only had a 160gig drive.  Even though the image is much smaller than that, (about 4gig) FOG felt that the smaller HDD wouldn’t be able to handle the image and refused to deploy.  This can be solved by ensuring that your build machine has a smaller HDD than any machine you intend to deploy to.

Final Deploy time:

Overall I was able to take the 1 hour configure time it took for me to setup 1 machine, and cut it down to about 5min for a technician in the field.  Stored information about the wireless networks I pre-configured on the master device seems to be in a protected area on the disk that FOG couldn’t read.  The end result is that a technician must image a unit, then enter wireless key information after it’s deployed.

The user experience on the new “ChromiumBooks” has been right on target so far. The devices boot in about 40 seconds. Most of that time is the hardware boot process. Once that is complete ChromiumOS still loads in under 8 seconds. Users are immediately able to login to their Google Apps for Education accounts and begin browsing.

The linux driver for the wifi cards seems to be more stable than the windows driver, and I have much fewer reports of “wifi drop offs”.

Overall, getting rid of windows has been great for these devices.

If you liked this story, or want to shoot me some questions feel free to find me at www.selfcommit.com.