@Duane, thanks for this hint.

Does this mean any restriction in terms of software that could be installed on the chumby classic?! e.g. installing Python and running Python script?! Installing a web browser, etc.?!

I have a related question.  We (our robotics club) have got a hold of a few chumby classics.  We want to use various devices such as Pololu Maestro, Mbed, TI Launchpad off the USB ports, but those devices use ttyACMx for serial communication over the USB bus. 

I have a copy of cdc-acm.0 that may work, but the problem is that /drivers is a read only directory and as we know from the preceding discussion, you can't just do "mount -o remount,rw /" on the chumby classic. 

Any suggestions (other than use chumby one, etc...)?

I followed your directions, however the best I can get is that the chumby quits loading and reports:

[    3.000000] VFS: Mounted root (cramfs filesystem) readonly.
[    3.020000] Freeing init memory: 100K
[    3.030000] Warning: unable to open an initial console.
[    3.040000] Failed to execute /linuxrc.  Attempting defaults...
[    3.050000] Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
[    3.070000]  <7>Hub status changed

This happens whether I make my changes or not.

Great!  I left this tab open so I could give it a try again.  I know I've done it in the past, but wasn't sure what I did differently than the directions I gave you.

Two kernels and two RFS partitions is a chumby thing, not a linux thing.  They do it for the "Special Options Mode" for recovery and updates.

As for the kernel and rootfs being separate, that's just the way it is.  I'm not sure exact definitions of everything, but most people think of "linux" as a distribution, which is usually a root filesystem, bootloader, and kernel.

When you're dealing with embedded devices and getting lower down a software stack like this, they're very separate things and you should understand them all.

Bootloader - This is the first (for our purposes) piece of code that is run.  It's job is to initialize hardware, load the kernel from flash and jump to execution of the kernel.  In most Chumby hackery discussed here, we're not wanting to change this because we're not worried about changing boot parameters or low-level hardware initialization.

Kernel - The main process of an OS.  It is a bridge between applications and the actual data processing done at the hardware level.  It is in charge of accessing hardware directly based on what applications tell it.  It has a task scheduler to time-slice work being done, memory managers, code for specific hardware (touchscreens, mice, keyboards, DMA engines, rotory encoders, audio chipsets, etc.), and quite a bit more.

Root filesystem - This is something that contains all the files to make the OS usable.  It contains the user applications, configuration files, loadable kernel modules for additional hardware support, etc.

They're each very distinct things, so building the kernel as you've done, doesn't mean you're done since you built a module, not a piece of the actual kernel.  You still need to change the root filesystem.  If you had selected support for the "cdc-acm" as built-in instead of a loadable module re-flashing the kernel would have been all you needed to do.

Because of this separation, there are many solutions to "tie everything together."  Things like OpenEmbedded, buildroot, etc. are all projects that wrap kernel and root filesystem together in a more concise and easier to manage fashion.  I believe I asked Chumby a while back about their system and they use some custom rolled build scripts to package everything together.