Database Develop

[ROOTING] Finding a hole in Tattoos kernel to get root

This little gem of a phone is a tough little thing to custom install apps on, but that didn't stop the Coburn from being able to get busybox installed.
Therefore, introducing Busybox for your HTC Click/Tattoo!
FOLLOW THIS TUTORIAL CAREFULLY. This guide may brick or NOT brick your Tattoo (most likely the latter), however I cannot assure you that it's 100% fail proof. I have installed it successfully. IN OTHER WORDS: THIS IS NOT FOR THE FAINT HEARTED! IF YOU DO NOT KNOW WHAT 'FLASH','ADB' OR 'HACK' MEANS, PLEASE DO NOT CONTINUE.
Requirements:
1 HTC Tattoo (The Victim)
1 MS Windows Powered Computer (I used Win7 64Bit)
1 HTC Tattoo -> USB Cable (Included with phone... Well, it was in the box).
Download the package attached to this post. Extract all files to a directory like C:\BUSYCLICK . (Actually, please extract them there).
Installation
Connect your Tattoo to your phone, make sure USB Debugging is enabled (Settings -> Applications -> Development) and sit back. Windows should say "New Hardware! OMG!" and ask "What is this piece of tech?" (aka New Hardware Install Wizard). On XP, allow to search Windows Update. On Vista/7, I'm going to have to get back to you on that. The installed driver will be like "HTC Dream blah blah blah ADB Interface" or something. Odd why it says it's a HTC Dream...
Anyway, go to the folder where you extracted the files, and run the Installation.bat file. It's the one that says "Installation" With the cogs icon.
You'll get a DOS Prompt and some text, PAY ATTENTION! My installer will hold your hand and explain what's happening. Should any errors occur, you may be out of space on your Tattoo's internal memory or something. If you do get errors, please post them here! I'll try to fix them for you guys and girls.
Post-install tasks
When complete, run the TestBusybox.bat script in the same folder where you extracted the BusyBox files, and you should get some output. If not, busybox failed to install... Let me know what the error is and I'll try to fix it.
Notes:
You can use the busybox commands in /data/local/bin from "adb shell" or a terminal emulator on the phone itself... /data/local/bin/sh DOES NOT work from adb shell, I don't know why. It will work using a terminal emulator. Try "/data/local/bin/free" and such for some memory read outs, etc, etc.
Feel free to love/like/hate/kill/shoot my work, you can expect to see ROMs and the like in the near future as I love hacking devices.
Cheers,
Coburn64

What about this one?
I have no experiences in Android-Developing, I'm just a normal long-term Linux-User.
What is about that?
http://www.milw0rm.com/exploits/8678
It's an exploit for Kernel 2.6.29 - my be this could work for us or is it patched in Tattoos 2.6.29?
I wish I would find the time to dive in the Android-SDK and cross-compiling a little bit but it won't happen until April :-(
So just for your personal motivation: There are thousands of people out there watching this forum and crossing fingers! So keep up your work and don't stop trying!
Good luck!
Bastian
Moderatoredit: Link repaired - have a nice day

My fingers are crossed

+1 Can't wait till the Tattoo gets rooted.

Yeah, crossing fingers for you - nothing more cool than wifi tethering

Wooh, how fast it can be april...
But until now I'm even unable to sucsessfully compile the exploit. I set up a cross-compile-environment on my laptop, but all I get is:
[email protected]:~/Desktop> /opt/cross/bin/arm-linux-gnueabi-gcc -static -o shoryuken shoryuken.c
shoryuken.c:49:24: error: linux/user.h: No such file or directory
I don't get it, there is a user.h in the cross-compile-environment in gnueeabi's searchpath. Sorry, semes to be a job for real developers if I already got my problems before real problems begin.
And my girlfriend has innumerable methods in killing me in cruel ways if I don't pay her more attention in exactly 2 minutes. Strange. "I want to root my tattoo! Thats very important!" doesn't seem to make any differences, she arguments that I could not even have a tattoo, she sees me naked periodically and she had never seen one...
So real experts, the fields of war belongs to you!
Bastian

The first step is finding the patch that closes this bug. Then, verify if has been aplied in the source that HTC released a couple days ago (very likely, since the exploit is dated from April and our kernel was compiled in November).
If it is not patched, we would need some ARM shellcode, but that is probably easily obtainable in the usual places. Worst case, we would need a ARM dev to write it.

I did my best to help. Because as i already said I'm not a developer I will describe what I did to prevent starting someone to work on something that could never work.
I searched for the patch that closes this hole:
Code:
CVE-2009-1527 :
Race condition in the ptrace_attach function in kernel/ptrace.c in
the Linux kernel before 2.6.30-rc4 allows local users to gain
privileges via a PTRACE_ATTACH ptrace call during an exec system call
that is launching a setuid application, related to locking an
incorrect cred_exec_mutex object.
---------
and in the Changelog for Kernel 2.6.29.3
Code:
commit 2c9ca2baf3f368a2b747124d39bf31b779eb7571
Author: Oleg Nesterov
Date: Mon Apr 27 01:41:34 2009 +0200
ptrace: ptrace_attach: fix the usage of ->cred_exec_mutex
commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb upstream.
ptrace_attach() needs task->cred_exec_mutex, not current->cred_exec_mutex.
Signed-off-by: Oleg Nesterov
Acked-by: Roland McGrath
Acked-by: David Howells
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman
So I looked for commit cad81bc2529ab8c62b6fdc83a1c0c7f4a87209eb and there is the .diff:
Code:
kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -186,7 +186,7 @@ int ptrace_attach(struct task_struct *ta
/* Protect exec's credential calculations against our interference;
* SUID, SGID and LSM creds get determined differently under ptrace.
*/
- retval = mutex_lock_interruptible(&current->cred_exec_mutex);
+ retval = mutex_lock_interruptible(&task->cred_exec_mutex);
if (retval < 0)
goto out;
@@ -230,7 +230,7 @@ repeat:
bad:
write_unlock_irqrestore(&tasklist_lock, flags);
task_unlock(task);
- mutex_unlock(&current->cred_exec_mutex);
+ mutex_unlock(&task->cred_exec_mutex);
out:
return retval;
}
Then I downloaded and extracted the Tattoo-Kernel-Source from HTCs Website. The patch is small so I looked into ptrace.c by myself. And what should I say, I think HTC missed to close that hole. From HTC's ptrace.c:
Code:
retval = mutex_lock_interruptible(&current->cred_exec_mutex);
if (retval < 0)
goto out;
and:
Code:
bad:
write_unlock_irqrestore(&tasklist_lock, flags);
task_unlock(task);
mutex_unlock(&current->cred_exec_mutex);
out:
return retval;
}
If the patch would have been applied, it should be &task->cred_exec_mutex but it is still &current->cred_exec_mutex.
Am I right? Could that realy be our chance? If yes, it is on you or someone else to go one, I could only help testing things later one.
Bastian

The implementation is full of mutex ... The problem is that they function as a lock if a process is in a mutex, other processes can not enter.
If the root process closes a mutex (mutex_lock), the rest of the processes are kept waiting has to open the mutex (mutex_unlock). Just why we can not access to root processes with another process.And we can not get the root of the tattoo
thx

-bm- said:
I did my best to help. Because as i already said I'm not a developer I will describe what I did to prevent starting someone to work on something that could never work.
Click to expand...
Click to collapse
Well, I think you did a wonderfull job I also confirm your findings, I've checked ptrace.c in the HTC released source and the patch that you refer to as not been applied.
I've long forgotten allmost everything I knew about writing shellcode and x86 asm and never had any experience with arm, but I'll try to take a closer look at this during the weekend. I hope someone else will look into it too

@loen1984
That is over my technical horizon... ;-)
In my limited understanding, for the exploit we need a process that already runs with root-privileges to channel in, right?
I don't know anything about Androids architecture, is there nothing running with root-privileges in the background, no process, no daemon?
@mainframe3
I don't know anybody who's firm with arm developing, I hope you do
we would need some ARM shellcode, but that is probably easily obtainable in the usual places
Click to expand...
Click to collapse
And I think we should move this in a separate thread, it has not so much to do with Coburns BusyBox hack!

I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
thx
PD:Sorry for my english I'm Spanish ..

leon1984 said:
I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
Click to expand...
Click to collapse
I think that is what happens after the posted security patch is applied, but HTC didn't do that. But I will leave that field for the experts and cross fingers...
PD:Sorry for my english I'm Spanish ..
Click to expand...
Click to collapse
I'm german, mine won't be much better ;-)
Bastian

leon1984 said:
I think that all processes in the root before running, close access to the processor, so running in privileged mode as well tell you.
Should be found in the code, when running a root process,that not close the execution of other processes.
thx
PD:Sorry for my english I'm Spanish ..
Click to expand...
Click to collapse
I really can't spend any more time with this, or my boss will probably fire me
Quick look at the exploit, we need a setuid program for this to work. Guess what ?
Code:
$ ls -l /system/bin/pppd
ls -l /system/bin/pppd
-rwsr-xr-x root shell 147648 2009-10-14 10:39 pppd
Also, someone else has already ported this to arm:
http://forum.xda-developers.com/showthread.php?t=619003
I couldn't download the modified code, because of permission problems, but I contacted the author to see if he will send it to me
PS - Yes, we should move this discussion out of this thread

Then you should really get back to work
Mod is already contacted!

So here you are, dudes. Dunno why the first post remains, but it does.

Here is the arm port, I could download the file with bubisch's help. I also uploaded it here:
http://www.fileuploadx.de/673586

I could'n get my fingers completly of from this (even there is many other work to do...) that day so I set up and compiled a local Android-SDK on my Laptop and crosscompiled the exploid for the Tattoo (I hope). This should be a ready-to-run binary:
http://www.fileuploadx.de/755003
Even if I want to satisfy my curiosity there is no time for me left to do it today. I will get on it again later, but if anybody wants to give it an early try feel free. Instructions how to push it on your phone in an executable directory you will find here in the second half of the first post: http://forum.xda-developers.com/showthread.php?t=619003
In the sourcecode of the exploid there is the explanation on how to use it:
Code:
[email protected]:~$ while `/bin/true/`;do ./shoryuken;done
* [... much scroll removed, go make coffee, get a job, do something while running ...]
* /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
* proc on /proc type proc (rw,noexec,nosuid,nodev)
* /sys on /sys type sysfs (rw,noexec,nosuid,nodev)
* varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
* varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
* udev on /dev type tmpfs (rw,mode=0755)
* devshm on /dev/shm type tmpfs (rw)
* devpts on /dev/pts type devpts (rw,gid=5,mode=620)
* securityfs on /sys/kernel/security type securityfs (rw)
* gvfs-fuse-daemon on /home/matthew/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=matthew)
* [ WIN! 18281
* [ Overwritten 0xb8097430
* # id
* uid=0(root) gid=1000(matthew) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),
* 44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),1000(matthew)
* #
As mainframe3 posted, pppd ist setuid. Maybe we have to do something to make pppd doing something to be running if it doesn't already.
So cross fingers again everybody - this could break the wall or make us sitting back in tears.
I hope some experts could use this, I will also give it a try later on.
Bastian

No questions about where I got the time an what about my motivation about the books I have to read.
Just some short lines about how far I get for the rest to go further.
I pushed my posted binary to the tattoo:
Code:
adb push shoryuken /data/local/shoryuken
In that location it is executable! The rest I don't understand realy. In general: I'm able to run the program in a shell:
Code:
$ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$ ./shoryuken
[ WIN! 3347
Wrote shellcode 9148 line 0
Wrote shellcode 914c line 4
Wrote shellcode 9150 line 8
[ Overwritten 0xb001049c
$ rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
$id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)
$
When I start shoryuken it returns what you see above without any delay. I'm not sure but shouldn't he say "WIN" when the exploit was successful? As you can see my priviliges didn't change. In his sourcecode shoryuken is run with "while `/bin/true/`;do ./shoryuken;done" That generates an endless loop, doesn't it? Or am I getting something wrong? I wonder how it might terminate somehow...
/bin/true doesn't exist on tattoo, so I generated an endless loop with "while i=1; do ./shoryuken; done"
As expected much text scrolls by on the screen, after a minute the output freezes. I hit ^C and got my prompt back, but when I ran "id" it shows that nothing changed.
So do I understand shoryukens function totaly wrong? What's going wrong and does that mean shoryuken is not working as it should because it says "WIN" every time I run it?
I already said it 5 times, but now I realy can't do anything more with my simple homeuser knowledge and will leave the field for the developers.
Good night!
Bastian

I've been searching... and pppd is on /system/bin/pppd
But now... I've no idea... what I can test? I have to run pppd in order to get xploited?

Ubuntu on droid incredible - SUCCESS!

Hi guys,
As I'm sure most of you already know, some super-smart devs have already gotten ubuntu running on evo and nexus 1. I haven't heard any news of anyone doing this on the incredible.
I would love this functionality, but I'm no dev and have no experience building kernels. Anyone with the appropriate know how interested in having a look at the evo forum, and see if they can compile a kernel that will allow us to run ubuntu on or incredibles?
Just fyi: feedback from evo users suggest that all ubuntu functionality is working, including full flash support and even hulu.com!
Are you as excited as I am? Lets get to work on this- let me know and I'll help anyway I can.
Sent from my ADR6300 using XDA App

Ok, hadn't done this before, but it turned out to be pretty easy. I have compiled the kernel, and packaged it into an update.zip file signed with test keys. You can flash this straight from CW recovery.
If anyone is interested, this "kupdate-signed.zip" will update the kernel to the one I have compiled.
This kernel is completely identical to the stock htc kernel, except that it has the
CONFIG_BLK_DEV_LOOP=y
set so that we can run Ubuntu.
FInd it here: www<dot>4shared<dot>com/file/-kxtUfIw/kupdate-signed<dot>html
--samwathegreat

Ok, so the kernel seems to work perfectly for me, however I am unable to get ubuntu running.
I'm not sure where the problem lies, but I think it has to do with our restricted access to /system and /data.
Hopefully someone here can figure out what it is that I'm missing......I've tried following the instructions while booted into recovery and mounting /system and /data > everything works fine when I run the ubuntu.sh file, but I can't run the bootubuntu file under recovery........so after rebooting phone and trying to run bootubuntu, I get all kinds of errors and ultimately it fails.
After viewing the contents of bootubuntu file, I noticed that once again, it's trying to mount the /system partition......
If this is indeed because of the nand lock, then why does the procedure work on the evo 4g? I was under the impression that it incorporated the same nand lock as the incredible?
Any ideas?
Thanks

Edit:
The nand lock is indeed the culprit...just found out that evo users have full nand unlock available. I wasn't aware of that -hopefully we have the same soon on the incredible.
Patiently waiting...
Sent from my ADR6300 using XDA App

I was looking through the
bootubuntu a few days ago and if I remember correctly it was just moving some if the scripts into the system partition. We could probably boot into recovery and move the files in manually then edit the scripts to remove the system access.
Think its possible? I haven't looked at the scripts in a few days...
Sent from my ADR6300 using XDA App

If you need someone to test let me know.
Sent from my HTC Incredible using Tapatalk

I posted a thread about chroot earlier with no reply. No true nand unlock means no chroot which means no dual booting into ubuntu/debian/meego etc. Also no response from unrevoked if they plan on releasing a true nand unlock.
Other big problem is input.
http://forum.xda-developers.com/showthread.php?t=631389
That's about putting debian on the nexus as well using adb which might be possible but ending the session might have to be a battery pull. The big problem are sound drivers, GSM radio/modem drivers and on screen input.

Dvdivx:
Thanks, we're on the right track, however fastboot won't work on our devices either...again because of nand (that's why I had to make my kernel into an update.zip and sign with test keys - the evo boys just use fastboot to update their kernels). MAYBE we could get one of the distros installed in recovery with update.zip, but I don't see how we could boot android too if we go this method.
Shame I went to all the trouble of building that kernel....oh well. Maybe we will have nand unlock soon and get to use it yet.
Keep me posted if you find something out that hasn't been mentioned here. Thanks.
Sent from my ADR6300 using XDA App

I've been trying this for the last few days and stumbled uppon this thread when trying to get around the problem of mount -o loop.
I'm using http[://]nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/ as my guide and running through the two scripts manually adjusting as needed.
Thanks to your kernel i was able to get the ubuntu.img mounted. Here is what I've done so far...
#running jager chocolate rom with
#reboot recovery
mkdir /tmp/system
mount -o rw -t yaffs2 /dev/block/mtdblock3 /tmp/system
cd /tmp/system
cp /sdcard/ubuntu/fsrw .
cp /sdcard/ubuntu/bootubuntu .
cp /sdcard/ubuntu/unionfs .
cp /sdcard/ubuntu/mountonly .
chmod 4777 fsrw
chmod 4777 bootubuntu
chmod 4777 unionfs
chmod 4777 mountonly
#reboot and connect with adb shell
export kit=/sdcard/ubuntu
export bin=/system/bin
export mnt=/data/local/ubuntu
export PATH=$bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
mkdir /data/local/ubuntu
mount -o rw,loop -t ext2 $kit/ubuntu.img $mnt
busybox mount --bind /dev/pts $mnt/dev/pts
busybox mount --bind /proc $mnt/proc
busybox mount --bind /sys $mnt/sys
sysctl -w net.ipv4.ip_forward=1
echo "nameserver 8.8.8.8" > $mnt/etc/resolv.conf
echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf
echo "127.0.0.1 localhost" > $mnt/etc/hosts
chroot $mnt /bin/bash
So.... now I've got "[email protected]:/#"
And...
# uname -a
Linux localhost 2.6.29 #1 PREEMPT Sun Jul 11 03:35:47 EDT 2010 armv7l GNU/Linux
# chroot $mnt /bin/bash
[email protected]:/# cat /etc/issue
Ubuntu 9.10 \n \l
I think I'd call that a success.... Someone care to confirm?

Done with the following:
apt-get update
apt-get install tightvncserver
apt-get install lxde
export USER=root
vncserver
Over to androidVNC... The connection is taking forever to go through
When i go back to the terminal and cat /root/.vnc/localhost:1.log I see the following:
xrdb: No such file or directory
xrdb: can't open file /root/.Xresources
Segmentation fault
Edit: Nevermind... it works. When I entered the address in androidvnc, localhost was autocorrected as locals and I didn't notice.

The following script I saved as ubuntu.sh to handle creating the environment variables and such that is required each time you launch ubuntu. i call it with sh ubuntu.sh since I cant make it executable on the sdcard and don't feel like booting into recovery to put it in /system/bin until I work out the little issues. The only problem with below is that it is not un mounting the ubuntu image... Any ideas?
#####BEGIN ubuntu.sh#####
export kit=/sdcard/ubuntu
export bin=/system/bin
export mnt=/data/local/ubuntu
export PATH=$bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
export USER=root
mount -o rw,loop -t ext2 $kit/ubuntu.img $mnt
busybox mount --bind /dev/pts $mnt/dev/pts
busybox mount --bind /proc $mnt/proc
busybox mount --bind /sys $mnt/sys
sysctl -w net.ipv4.ip_forward=1
echo Running ubuntu!
chroot $mnt /bin/bash
#After exit, cleanup
umount $mnt/dev/pts
umount $mnt/proc
umount $mnt/sys
umount $mnt
#####END ubuntu.sh#####
Also, I was able to launch a few applications inside my VNC session including firefox. It was really really slow (i guess as expected). i would be interested in a performance comparison from someone who has both an incredible and one of other devices people have made run ubuntu in this fashion.

Ok so I've wiped my phone and started from scratch to come up with an easy procedure...
All that you need is the kernel samwathegreat posted, ubuntu.img (in /sdcard/ubuntu) and the following script. You only need to boot into recovery to do a nandroid backup and to install the kernel.
###### BEGIN ubuntu.sh ######
export PATH=/system/bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
export USER=root
mkdir /data/local/ubuntu
mount -o rw,loop -t ext2 /sdcard/ubuntu/ubuntu.img /data/local/ubuntu
busybox mount --bind /dev/pts /data/local/ubuntu/dev/pts
busybox mount --bind /proc /data/local/ubuntu/proc
busybox mount --bind /sys /data/local/ubuntu/sys
sysctl -w net.ipv4.ip_forward=1
echo waiting for things to settle...
sleep 5
echo Running ubuntu!
chroot /data/local/ubuntu /bin/bash
#After exit, cleanup
umount /data/local/ubuntu/dev/pts
umount /data/local/ubuntu/proc
umount /data/local/ubuntu/sys
umount /data/local/ubuntu
###### END ubuntu.sh ######
Here is everything in one zip file: www megaupload com/?d=WO094E5Q

FANTASTIC!
pez:
Thanks so much!
I'm thrilled that my kernel did indeed go to some good use. You obviously have greater linux knowledge than I, as i would not have been able to do the scripting myself.
In the true spirit of teamwork, we've accomplished this WITHOUT having nand access. To me, this is quite an accomplishment.
Thanks to everyone that worked on this! Also - Although I did build the kernel myself, I feel that credit must also go to "Koush", who provided the means and instructions to package the kernel into an update.zip file, and sign with test keys.
Good Luck everybody, and have fun playing with ubuntu on your Incredible!!!
-samwathegreat

Here is a really crappy video I recorded. I open the browser at the start to show I disabled all network access and am indeed connecting to localhost.
http://www.youtube.com/watch?v=HMYvQ5r_OyA
If someone else could replicate my success and post a better video I'd appreciate it.
Edit: Just saw your reply samwathegreat. Did you get a chance to try it yourself? I wrote a little howto on androidforums.com (http://androidforums.com/all-things...-run-ubuntu-droid-incredible.html#post1127643) hoping that others would be able to confirm they were successful too.
Also, the key mapping is messed up when connecting with VNC, but I haven't had time to find out why.

This is pretty awesome. I'll have to try this later just for the hell of it.

Too cool. My ROM has a kernel capable of this. I'm gonna try!

ihtfp69 said:
Too cool. My ROM has a kernel capable of this. I'm gonna try!
Click to expand...
Click to collapse
Hell, you should package this in with your rom.

Gimpeh said:
Hell, you should package this in with your rom.
Click to expand...
Click to collapse
Seconded!
Vote called motion carried, the I's have it.

Gimpeh said:
Hell, you should package this in with your rom.
Click to expand...
Click to collapse
Wouldn't having something like this in your sky raider rom bloat it and cause more battery use having it run in the background?

kentoe said:
Wouldn't having something like this in your sky raider rom bloat it and cause more battery use having it run in the background?
Click to expand...
Click to collapse
If it's running all the time. As long as you have a kill command it should be fine.

[SOLVED] install-recovery.sh - The undeletable script from the dark side...

Greeting all,
First of, I would like to thanks all of you for the amount of info I have found in this forum.
This is trully amazing and, so far, allowed me to sucessfully:
- Unlock my phone
- Root my phone
- Install a custom recovery image
I know that I am creating a new post on a very known and discussed subject BUT after 2 days of google seach nothing I have tried has permitted me to sucessfuly delete this £$%^&*() of script.
As you all know, it needs to be deleted to launch the custome recovery image (at the moment, I am stucked with the exclamation mark with the little Droid when I try).
IMPORTANT: I currently run the Froyo android 2.2 official ROM.
To delete this scipt, I have tried 2 approaches:
- Console mode from windows using ADB
- directly form the phone using a File explorer
#1: From the console:
As mentionned in many previous posts, I have tried the following commands once connected to the nexus
adb shell
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
I beleive this command is either incorrect OR no longer working with Froyo 2.2 as I get the following message which looks fishy (I am not a Linux specialist...):
Usage: mount [-r] [-w] [-o options] [-t type] device directory
When I try to delete the scripe with the commande below, I am kindly informed that it failed as it is still a read only file system
rm /system/etc/install-recovery.sh
#2: From the phone
I read that SUFBS, a very nice file explorer was available on the market allowing to mount both system AND data in RW would allow me to do it.
I have had several try at it enabling RW at different moment (System then etc then directly when I am in the folder and see the script I want to delete) and whatever I do, each time I select the command delete, it looks like it works (little pacman eating) but the script from the dark side is sill there like nothing happened...
As I am close to give it the microwave treatment to see if it works better ;-) I thought I give it a try on the forum to see if any Android/Linux god would spend 5 minutes to explain to me what I am doing wrong...
Thanks a lot in advance!
BooToo

Try this:
mount -o rw,remount /system
I can't guarantee that works with Froyo but it's all I've ever used and I don't remember it giving me any problem when I used Froyo.

Umm I think it should be mount -o remount,rw then type the rest
You can also try this mount -o remount,rw /dev/block/mtdblock3 /system
Sent from my Nexus One using XDA App

adb is supposed to have it's own remount command for doing this, but I've only used adb once when I rooted so I'm no help there.
Other than that, try doing: ls -l /system/xbin/mount to see if mount is a link to busybox. If it is, the last part of the output will look like this: /system/xbin/mount -> busybox
If it is, type busybox | head -n1 to see what version of busybox you have.
ilostchild said:
Umm I think it should be mount -o remount,rw then type the rest
Click to expand...
Click to collapse
Heh, I never realized I had those backwards compared to how people usually do it, but the order doesn't actually matter. It's not necessary to specify the device as the remount option doesn't change the mount point or device.
# mount | grep system
/dev/block/mtdblock3 on /system type yaffs2 (ro,relatime)
# mount -o rw,remount /system
# mount | grep system
/dev/block/mtdblock3 on /system type yaffs2 (rw,relatime)

Well...
I am an ass...
I did not have enabled the "USB debugging" on the phone...
Problem soved with the exact command lines I put at the beginning...

After rooting, flashing clockworkmod through ROM manager it was still going into stock recovery mode. Then I deleted /system/etc/install-recovery.sh and got my phone(HTC magic - 32A) bricked. Now it starts, shows rogers logo for 5-6 seconds and restarts and repeats untill i take out battery. I tried all combinations(power+back , power+home, Power+volume, Menu+home+power, menu+call+power) for quickboot and recovery mode but no success. Anyone has any idea about this issue?

If you have an HTC Magic, you're in the wrong forum...
Sent from my Nexus One using XDA App

just rename the script and you're done!

1) Bump 6 month old thread
2) Post in the completely wrong forum
3) Posts: 1 Join Date: Feb 2011
UGH.

error while loading new compiled Linux kernel image into the android emulator(1.5)
I am sorry, that i am asking my question in "reply" but i am not able to make a new post.
I have successfully compiled Linux kernel for android:
[email protected]:~/common# ARCH=arm CROSS_COMPILE=~/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
.
.
.
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
<stdin>:1097:2: warning: #warning syscall fadvise64 not implemented
<stdin>:1265:2: warning: #warning syscall migrate_pages not implemented
<stdin>:1321:2: warning: #warning syscall pselect6 not implemented
<stdin>:1325:2: warning: #warning syscall ppoll not implemented
<stdin>:1365:2: warning: #warning syscall epoll_pwait not implemented
CHK include/linux/compile.h
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 157 modules
[email protected]:~/common#
but i get the following error while loading this images in the emulator:
[email protected]:~/android-sdk-linux_x86/tools# ./emulator -avd avd1.5 -kernel ~/common/arch/arm/boot/zImage -show-kernel -verbose
emulator: found SDK root at /home/preetam/android-sdk-linux_x86
emulator: root virtual device file at /home/preetam/.android/avd/avd1.5.ini
.
.
.
yaffs_read_super: isCheckpointed 0
sh: can't access tty; job control turned off
# init: cannot find '/system/bin/playmp3', disabling 'bootsound'
init: cannot find '/system/bin/dbus-daemon', disabling 'dbus'
eth0: link up
init: untracked pid 578 exited
init: untracked pid 579 exited
warning: `rild' uses 32-bit capabilities (legacy support in use)
init: untracked pid 601 exited
init: untracked pid 592 exited
init: untracked pid 605 exited
init: untracked pid 602 exited
init: untracked pid 609 exited
init: untracked pid 606 exited
init: critical process 'servicemanager' exited 4 times in 4 minutes; rebooting into recovery mode
save exit: isCheckpointed 1
save exit: isCheckpointed 1
Restarting system with command 'recovery'.
Reboot failed -- System halted
and the emulator didn't start with the new kernel image(emulator didn't reboot). what is the problem here..?? and how can i replace my emulator's image with newly compiled Linux permanently??
please help. thank you!

I did everything as the guy who initiated this post under windows vista, and I have the same problem. However, I don't know how to go about deleting or renaming that scrip. Can you, give me a step by step procedure? Thank you

Flash this through recovery to delete the script...
http://db.tt/ooDaCnU

Hi,
I am sort of new to this. how do I flash using the above script?

[DEV][BUILD0 - PREALPHA]HW TEST: OMAPZoom AOSP 4.1.2 JZO54K

Hi Folks, Not to be left out of all the 4.1.2 Fun, Here's a little teaser of what's to come!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
ROM STATUS: BUILD0 PREALPHA - OFFLINE - AWAITING UPDATE
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DETAILED ROM INFORMATION
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DEVELOPMENT INFORMATION
Click to expand...
Click to collapse
Now Go! We Make Rom Now!
NOTES: ETA? DON'T EVEN ASK! :laugh:

Great Work !

[BUILD0]Touchscreen, OpenGLES and CWM Test!
Hi Folks.
Feeling Adventurous? Then You Might want to have a quick go this OmapZoom AOSP 4.1.2 JZO54K That I've prepared It's in it very early stages but It would be help if some folks could give it blast and let me know if the TouchScreen functionality is working as my touchscreen hasn't worked for a long time and as such it is some I can't test. If the lastest version of Android wasn't enough of a draw, This rom also includes the work I've done with CWM Recovery.
BUILD INFORMATION AND DETAILS
What's BUILD0?
Good Question, Build0 ( Build Zero ) is pre-alpha release aimed at testing specific hardware functionality and software features.
Hardware - Working
Touchscreen (?!?) - The Drivers are installed so it "should" just work
Archos 3G / Huawei + Others 3G Dongles - The Hardware will be recognized but there is nothing implemented in Android user land as yet.
Hardware - Not Working
Everything else! - To be implemented in future builds[/QUOTE]
Software Information
The main software/driver focus of this build was getting the PowerVR Drivers to function to enable HW Acceleration. This has been achieved not only using the stock kernel modules ( as one would expect ) but also on test custom kernel builds. This is an area along with the Camera that has proved problematic when attempting previous ports and is something I wanted to solve early on.
Hacking On It!
Source Code Info : See Separate Post on building and source code info [ COMING SOON ]
Kernel Version : Archos Stock 3.0.21 - This will change in the next build to use a kernel with JellyBean Specific features plus some extra treats , For anyone interested in hacking on this current build I have included all the stock kernel modules, they can be found /system/lib/modules. Of course the kernel modules for most hardware is only half the story as many devices also require a binary firmware blob which is not included but can be grabbed from the Archos 3.0.25 Firmware.
StabilityThe build seems pretty stable overall but although the incorrect battery percentage do make a it wobble a little
Clockwork Mod Recovery - I will update the CWM thread with details regarding bugs and testing etc but just to say, It's seems fully functional with very few minor issues.
Installation - Please See The Installation Instructions For Details

Installation Guide
Installation Guide
STOP! HAVE YOU TAKEN A BACKUP OF YOUR IMPORTANT DATA
Although your existing data is not touched, It is advised you backup your data directory before proceeding.
Click to expand...
Click to collapse
ALL THE USUAL DISCLAIMERS APPLY, FILES ARE PROVIDED AS-IS AND WITHOUT WARRANTY ,
ITS YOUR DEVICE, YOUR RESPONSIBILITY, I'M NOT YOUR DAD!
Click to expand...
Click to collapse
Build0 - Requirements
Archos G9 SD Version
android sdk / android debug bridge ( adb )
SDE Enabled Firmware ( unofficial or official )
common sense.
NOTE: I've only tested this using Linux , The procedure should be the same on Windows but we don't know until we try.
Assumptions
1.You know how to flash a SDE initramfs and zImage either through the Developer Menu or using kd_flasher from the adb command line,
2.You know how to boot your device into the Special Developer Edition Firmware ( SDE )
3.You have setup adb correctly a your device is listed in the adb devices list.
Build0 - Installation Steps
1. Download and unpack the cwm boot image [ Hotfile :/archosg9-jzo54k-cwmboot.7z ]
2. Download and unpack the system image [ CURRENTLY OFFLINE - AWAITING UPDATE ]
3. Flash the unpacked zImage and initramfs.cpio.lzo using the [Recovery]/[Developer Edition Menu]/[Flash Kernel and initramfs] option in Archos recovery mode.
4. Reboot Into Developer Edition ; You should now see the Familiar CWM User Interface, You should see a couple of error messages regarding mounting /cache/recovery/command and /cache/recovery/log. This is expected.
5. use adb to push the unpacked system.img to the /._ directory on the device with the following command
Code:
[B]adb push system.img /._/system.img [/B]
NOTE: The system.img is 500MB in size and it may take some time for the transfer to be completed
6. When the file transfer is complete, reboot the device either using the CWM UI or adb reboot, The device should reboot back into CWM, The previous error messages will still present, Again this is the expected behaviour.
At this point, if everything is ok you should be able the use adb shell commands. Lets check the mount points using
Code:
[B]adb shell mount[/B]
The output should be as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
If you see the message
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
Then either you have not followed the instructions correctly or I've not typed them up correctly! Either way something's not right. See the troubleshooting section below for tips on how to check what's what.
7. Next we need to create a ext4 image for the cache and data partitions. This involves create an empty file with dd, loop mount the file as a block device using losetup then making the filesystem using mk2fs.ext2. Sounds like a lot of work. I thought so too, so all you need to do is run the following adb shell command
Code:
adb shell createfs
This will create a 500MB cache image and a 2GB data image. Again because of the file sizes involved this does take a couple of minutes to complete. Please be patient, when the command is completed the full output should look as follows
Code:
File System Image Creation Script - For Test Purpose Only
/dev/block/mmcblk0p4 /._
FileSystem Container /dev/block/mmcblk0p4 Mounted at /._.....
Checking Available Space.
Available Space : 5129
Creating cache image at /._/CAC With Block 500000
500000+0 records in
500000+0 records out
512000000 bytes (488.3MB) copied, 39.070434 seconds, 12.5MB/s
DD Returned 0 : Loop Mounting the raw image /._/CAC to /dev/block/loop1
Creating Ext FileSystem on /dev/block/loop1
warning: 287 blocks unused
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Creating data image at /._/DATA With Block 2000000
2000000+0 records in
2000000+0 records out
2048000000 bytes (1.9GB) copied, 175.243408 seconds, 11.1MB/s
DD Returned 0 : Loop Mounting the raw image /._/DATA to /dev/block/loop2
Creating Ext FileSystem on /dev/block/loop2
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
125184 inodes, 500000 blocks
25000 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304
16 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
8. Reboot the device. The device will once a gain reboot into CWM Recovery. This time there should be no error messages. check everyhting is mounted and created correctly using
Code:
adb shell mount
The output should look as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop2 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
9. Congratulations You now have Jellyean and CWM Recovery running on you device
One Last time choose "reboot system now" from the cwm menu to taste those JellyBeans!
TROUBLESHOOTING
Ok you've got problems, nothing that cannot be worked around.
Investigating
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
If you run into this error then I means that your system.img is not present on the device or has not been mounted correctly for some reason. because of the way the device recovery is setup at the minute adb still looks for it's shell binary in /system/bin this only exists if the system is mounted. Fortunately we still have a couple of adb commands at our disposal, namely pull and push, the work around this issue you do the following [ Example uses Bash Terminal on Linux ]
Code:
adb pull /sbin/busybox
chmod +x busybox # Linux Only - Make sure busybox is still executable
adb push /system/bin/sh
You should now be able to drop into an interactive shellk using
Code:
adb shell
A further trick to make sure you have access to all the commands is to symlink the contents of /sbin to /system/bin. like so
Code:
a s "ln -s /sbin/* /system/bin"
More Troubleshooting Soon! If folks get stuck.

Development Information
It turns out, perhaps unsurprisingly that the omapzoom.org aosp repo is the one for us!
I did some light changes to the blaze_tablet device tree, which mainly involved changing the word blaze to archos .
Once again I've got the powervr drivers loading successful, because archos are using the latest version we don't have to rip them off the device as the userland binaries in the device/ti/proprietary-open.git work fine.
As this is the very first build I've scaled everything back, so what you've basically got is a booting rom to hack on. Apart from the powervr drivers everything else is untested and presumed not working. Also the kernel needs rebuilding to include tracing.
If anyone fancies hacking on this, get the source from http://omapzoom.org and the archos device tree can be found on my github. place the device files in a device/ti/archos_tablet directory.
Use the jb-mr0-release branch, I had some trouble building the development branch (jb-mr0-dev), clearly someone has committed some breaking changes.....

One more for luck

Don't you just hate it when the op does this

zImage and initramfs.cpio.lzo
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp

stevemp said:
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp
Click to expand...
Click to collapse
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks

trevd said:
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks
Click to expand...
Click to collapse
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
Jelly Bean boots but touch screen not working
stevemp

stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
I think SDE is official, not sure how to find out.
Windows 7 64 bit.
SDE -> Developer Edition Menu -> Flash Kernel & Initramfs -> copied zImage and initramfs.cpio.lzo rebooted -> held power button and volume down -> went back to SDE -> Developer Edition Menu -> still looks the same.
stevemp
Click to expand...
Click to collapse
Ok Thanks Again for the Feedback.
I think the official SDE is watermarked! I also think we might have our wires crossed and you've misunderstood ( more likely I've not explained clearly ) Just what this is. This does NOT replace the existing Archos Recovery Menus. On technical level it is an SDE Rom which can be booted between android and recovery effectively adding an extra boot mode to SDE, This sits apart from the Archos BootMenu Stuff.
I suppose a good way to think about it is in the following structure.
Code:
Archos Boot Menu
Android
Recovery
Developer Edition -----> Android
Recovery
So You actually load the developer edition to use this recovery. Flashing and Booting these Files won't affect any other Rom/Data on the Tablet as the Partitions are self contained in there own image files. So you can easily return to [email protected] by flashing a "Classic" initramfs and kernel.
If You still can't boot into CWM You might want to have a go with the alternative flashing method using adb. It's a lot easier than all that Vol+Down Stuff.
When Booted in android, run the following commands
Code:
adb push zImage /data/local/zImage
adb push initramfs.cpio.lzo /data/local/initramfs.cpio.lzo
adb shell "kd_flasher -i /data/local/initramfs.cpio.lzo -k/data/local/zImage"
adb shell "reboot_into sde"
Thanks Again

stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
stevemp
Click to expand...
Click to collapse
Beat Me Too It, See my above post.... :victory:
Oh well stands as a good explanation

Jelly Bean
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp

stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
OK Thanks for the test.... To use the classic phrase, It's not you It's me , I think I'm missing some layout files, Nice to hear you got it Booted.
One piece of probably useful information I've omitted! You can boot back into CWM using adb, while booted into JellyBean use
Code:
adb reboot recovery
Recovery should be fully working, You can flash zip i.e gapps CWM-SU etc, The sdcard mount point tries to mount the external sdcard as fat32 ( for now ).
once the external sdcard is mounted you should be able to run a backup
No more instructions at the minute I'm afraid but I'll get right on it.
Once again Thanks for the Testing and Feedback, It's been very useful.

Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go

cajl said:
Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go
Click to expand...
Click to collapse
Should be good for all Gen9 SD's and in time HD versions as well, Can't test with HD Versions because I don't have one! :laugh:

If you want i will be testing this afternoon on the HD
and if the dl is ok

stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:

surdu_petru said:
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:
Click to expand...
Click to collapse
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult

trevd said:
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult
Click to expand...
Click to collapse
Hi!
Thanks TREVD!
A very very very good job!!! :good:
My device is it now on Service Centre for reparation ( touchscreen issue! ) for 3 , 4 week!
I can't wait to test all your stuff!
Thank's again and good luck! :good:

The CWM for Ouya project

Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.
The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.
I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.
Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:
./flash_image recovery recovery.img
error scanning partitions: No such file or directory
Mount reveals the following info:
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
but I can't make any sense of it. If anyone can help out i'd much appreciate it...

sonofskywalker3 said:
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Click to expand...
Click to collapse
This seems to be the magic lines in the update script:
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
Click to expand...
Click to collapse
I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.
UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts
UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).
UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).
Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line
package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");
where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).
You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.
WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.
You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
Sent from my Nexus 7 using xda premium

Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...

sonofskywalker3 said:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
Click to expand...
Click to collapse
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).

Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.

sonofskywalker3 said:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
Click to expand...
Click to collapse
It probably doesn't work because the update.zip we're using is signed.
Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.
1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"
6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)
This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.
For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.
Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.
Click to expand...
Click to collapse
There are two big unknowns here:
1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery
I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS
---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------
/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1
So far, it appears that the layout is the following:
Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3
Sent from my SCH-I535 using xda premium
---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------
I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
Sent from my SCH-I535 using xda premium

Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.

mybook4 said:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Click to expand...
Click to collapse
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.

rayman said:
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
Click to expand...
Click to collapse
I did the following with skywalker's recovery.
1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)
The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)
5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.
When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.
Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.

Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.

sonofskywalker3 said:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
Click to expand...
Click to collapse
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.
If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
Sent from my SCH-I535 using xda premium

I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?

sonofskywalker3 said:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
Click to expand...
Click to collapse
I'm still new at making a recovery.fstab, but I noticed the following:
From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"
lrwxrwxrwx root root 2013-05-25 02:23 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-05-25 02:23 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-05-25 02:23 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-05-25 02:23 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-05-25 02:23 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-05-25 02:23 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-05-25 02:23 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-05-25 02:23 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-05-25 02:23 USP -> /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?
We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.
P.S. So far, I think we are fairly certain that
APP is the system partition
CAC is the cache partition
LNX is kernel boot.img
SOS is the recovery partition
I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?

Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Update:
Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.

sonofskywalker3 said:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/systemext4/dev/block/platform/sdhci-tegra.3/by-name/APP
/cacheext4/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dataext4/dev/block/platform/sdhci-tegra.3/by-name/UDAlength=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/bootemmc/dev/block/platform/sdhci-tegra.3/by-name/LNX
/recoveryemmc/dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Click to expand...
Click to collapse
Good stuff.
Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab
length= field is probably not needed, as the stock recovery doesn't list it.
Sent from my SCH-I535 using xda premium

Here's the recovery.fstab from my Ouya's recovery partition.
# mount point fstype device
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard vfat /dev/block/platform/sdhci-tegra.0/by-num/p1
Click to expand...
Click to collapse
I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.
Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).
I tweaked the recovery.fstab to the following:
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard datamedia /dev/null
Click to expand...
Click to collapse
This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.
I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.
I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.

well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Update!
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!

sonofskywalker3 said:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Click to expand...
Click to collapse
I edited the comment right above yours.
Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.
1) adb shell
2) su
3) cd /dev/block/platform/sdhci-tegra.3/by-name
4) dd if=SOS of=/sdcard/stockRecovery.img
5) exit
6) adb pull /sdcard/stockRecovery.img .
I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:
I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.
Here's what I did step by step:
1) split_bootimg.pl stockRecovery.img
2) mkdir ramdisk
3) cd ramdisk
4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i
in the ramdisk directory is etc/recovery.fstab
I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.

sonofskywalker3 said:
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
Click to expand...
Click to collapse
Awesome! Let us know how the backup/restore and zip flashing goes.
Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):
1) adb reboot bootloader
2) wait 30 seconds (blank screen is normal)
3) fastboot flash recovery recovery.img
4) fastboot reboot recovery (need a usb keyboard to navigate CWM)
5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)
6) profit
Most of this could potentially be automated into a root/install CWM script.

Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...
Update:
The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.
It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.
Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.
Edit: removed non working zip