[Ouya Android Development] Trooper_Max:
I'm including some rough developer details here for now about how I did it.

Many thanks once again to the OUYA CWM recovery, I found it insanely useful: http://xdaforums.com/showthread.php?t=2295645

The main part was unpacking/modifying/repacking the boot.img (which contains the kernel/ramdisk/etc)

abootimg helped with this greatly:

http://manpages.ubuntu.com/manpages/precise/man1/abootimg.1.html

Then I followed instructions I found via google for unpacking/repacking the ramdisk:

http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

The partitions the OUYA uses are mostly defined in fstab.cardhu:

I found that I could use fastboot to boot into the CWM recovery and then use adb pull to dump images of the internal OUYA partitions, using the paths above, ex. "adb pull /dev/block/platform/sdhci-tegra.3/by-name/APP ouya-system.img" to dump the system partition. I did a regular clockwordmod backup first, but adb pull was useful here for pulling raw images.

So after backing up my OUYA stock system, I actually did flash the CM10 rom so that I could dump the partitions to my computer using adb. The main reason I did this was to ensure the system partition gets generated with the correct permissions. I didn't boot into CM10 though, though I was tempted. Instead I restored back to my backup to put my OUYA back in stock condition.

With the system image dumped into a file, I used resize2fs to shrink the file to the minimum size (resize2fs -fM ouya-system.img) This probably wasn't absolutely necessary since it would compress down in the zip, but this allows it to be written to smaller partition sizes.

http://manpages.ubuntu.com/manpages/precise/en/man8/resize2fs.8.html

Here is what I modified the fstab.cardhu to:

Pretty straightforward, except that I removed the encryptable part on /data (not sure how that bits work and if I might have broken it) and made system read/write.

Also note, that I removed the initial read/write mounting of system in init.cardhu.rc since I was having trouble with it mounting from there (I'm guessing because my usb hub/thumb drive weren't yet available when that tried)

Here's the relevant part of init.cardhu.rc:

Before:

After:

Basically I commented out the mount command - before it was mounting system read/write for a moment to insert the symlink and let the filesystem update itself before remounting read-only in the fstab. The way I do it now it is simply mounted read/write from the fstab and left that way (some may consider this unsafe, but it is good for development... not too hard to remount it read-only if you so desire) I also shifted the symlink command down below the mount all command so it would hopefully still work... not sure what that was for, but they made it sound really important! XD

I also commented out this part about the usb drive since it doesn't really make sense anymore:

I think those were all the changes I made before repacking it, though it did take me 5 attempts to get a working ramdisk so I may have lost track of something at some point. Those should be the key changes at least.

I also initially used raw dumps of the data and cache partitions on my thumb drive as well to make sure it would work. Then I tested to make sure it would work if they were empty ext4 partitions, which they do - Android fills them in as necessary. So only the system image was necessary to include. (and of course the boot.img for fastbooting)

This was a little bit harder than I had anticipated because I'd previously only looked into this type of thing for Gingerbread devices which aren't set up the same way. I'd kinda been hoping to get a solution where the user could just drop a system.img and data.img onto a fat32 usb thumb drive and the boot.img would loop mount them off the thumb drive. I haven't tried this for Gingerbread, but it seems pretty straightforward. It's not straightforward anymore here since fat32 sdcards aren't used anymore. Being familiar with Linux though, I am happy they are using ext4 everywhere and using the same space alloation for /data and /sdcard so you don't have to worry about which one to make big, but it does make some things more complicated for more average users. It's probably still possible to get the OUYA to do what I wanted, but more complicated and not sure it's worth pursuing over other methods which may be more fruitful.

Hope that's enough details to enlighten some people who may be wondering about the methods used here. My goal is to not only develop new ways of booting the OUYA, but also to share how I accomplished things so that others can learn from it.

~Troop