Database Develop

Recovery / Edify / Data Mount Issue

Hi,
I'm trying to mount /data with GT-5570I using recovery / updater-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?

wrong section dude
and u manually boot into recovery? i turn off my phone and i boot it myself and i cant mount/ anything.....but u must tryboot yr device to recovery at ur power menu(only some rom got this option,in my exp gb no this option)...and it will solve the cache log prob...its work for me
Sent from my GT-S5570 using XDA

Wrong section bro!! This is for dev only, post such things in general!!
Sent from my GT-S5570 using xda premium

It's nothing general, it's dev actually. I'm not talking about how to enter recovery, but about scripting and developing own recovery / custom recovery.
But thanks so far for your answers.

recovery already has mount command...try this one to mout your /data partition
Code:
mount("rfs", "EMMC", "/dev/block/stl11", "/data");
if you want to use run_program command, you can make a file contain
Code:
#!/system/bin/sh
mount -t rfs /dev/block/stl11 /data
put that file on your root folder of your zip file. to run the script you'll need to use these command on updater script
Code:
package_extract_file("<your filename>", "/tmp/<your filename>");
set_perm(0, 0, 0777, "/tmp/<your filename>");
run_program("/tmp/<your filename>");
the first method is easier...

viperbjk said:
Hi,
I'm trying to mount /data with GT-5570I using recovery / update-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?
Click to expand...
Click to collapse
Hello
you use what
update-script ?
if yesy is wrong for edify on edify is caled
updater-script and commande on it is diferant from amend script [ update-script]

viperbjk said:
Hi,
I'm trying to mount /data with GT-5570I using recovery / update-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?
Click to expand...
Click to collapse
If you are still using update-script then, I suggest you switch to updater-script and update-binary since, latest clockwork mod (v3 and above use these Edify scripting methods...).
I believe you are trying to mount data to copy files to or from /data/ partition on your device...
Here's a script to do so in recovery and I'm sure it's the exact thing you are looking for :
http://handyinformation.freevar.com/showthread.php?tid=12
Good luck!

try it
Code:
mount("rfs", "/dev/block/stl11", "/data");

ahmadsafar said:
try it
Code:
mount("rfs", "/dev/block/stl11", "/data");
Click to expand...
Click to collapse
This one is leading into "E:Error in /tmp/sideload/package.zip (Status 0)"
last_log says that :
MountFn, 53
MountFn : type is rfs
MountFn : rfs type
MountFn result is : /data
;(

kurotsugi said:
recovery already has mount command...try this one to mout your /data partition
Code:
mount("rfs", "EMMC", "/dev/block/stl11", "/data");
if you want to use run_program command, you can make a file contain
Code:
#!/system/bin/sh
mount -t rfs /dev/block/stl11 /data
put that file on your root folder of your zip file. to run the script you'll need to use these command on updater script
Code:
package_extract_file("<your filename>", "/tmp/<your filename>");
set_perm(0, 0, 0777, "/tmp/<your filename>");
run_program("/tmp/<your filename>");
the first method is easier...
Click to expand...
Click to collapse
The first one doesn't work with my update-binary as it's the new AOSP one only taking 3 variables instead of four.
using mount("rfs", "/dev/block/stl11", "/data") or mount("emmc","/dev/block/stl11","/data") leads to "E:Error in /tmp/sideload/package.zip (Status 0)"
Using the second one, the sh method, this leads into the same error message, "No such device".
I'm guessing that the main problem might be some driver/init adbd does for mounting ....

yagya said:
If you are still using update-script then, I suggest you switch to updater-script and update-binary since, latest clockwork mod (v3 and above use these Edify scripting methods...).
I believe you are trying to mount data to copy files to or from /data/ partition on your device...
Here's a script to do so in recovery and I'm sure it's the exact thing you are looking for :
http://handyinformation.freevar.com/showthread.php?tid=12
Good luck!
Click to expand...
Click to collapse
Yeah, I basically just try to mount /data to access files. Sorry for the typo, it's updater-script of course.
When I just try to use
run_program("/system/xbin/busybox", "mount", "/data");
it isn't accepted because of
"mount: can't read '/etc/fstab': No such file or directory"

Ok, guys ... found the solution ...
mount("rfs", "EMMC", "/dev/stl11", "/data");
is working, but only using old updater-binary. Seems the AOSP
one doesn't work ... no idea why.
Many thanks for helping me out !

there's a possibility that the AOSP one doesn't compatible with the recovery.

viperbjk said:
Yeah, I basically just try to mount /data to access files. Sorry for the typo, it's updater-script of course.
When I just try to use
run_program("/system/xbin/busybox", "mount", "/data");
it isn't accepted because of
"mount: can't read '/etc/fstab': No such file or directory"
Click to expand...
Click to collapse
Well, it's probably because you don't have busybox installed. Are you sure you are rooted and have latest busybox version installed on your system?
Also, which rom do you have now?

I'm using stock rom, and yes, busybox and root is also done in recovery.
The GT-5570i hasn't got a fstab file, so that's fine.
Everything is working fine now, it was obviously that the samsung update-bin didn't work with mobiles with broadcom chipset.

try this, it's working
http://forum.xda-developers.com/showthread.php?p=27018781

meccaandroid said:
try this, it's working
http://forum.xda-developers.com/showthread.php?p=27018781
Click to expand...
Click to collapse
No. This has to do with the binary n not amend.
The issue has been resolved, so rip thread.

Dual Boot Atrix: Simplified and Standalone (30 Jan 2013)

Quickly and conveniently leverage the strengths of mainstream ROMs and kernels using my new simplified and standalone dual boot tools!
Here I assume that your rooted Atrix with unlocked boot loader already hosts a ROM on EMMC. Even if you're not dual booting, I think you will find some or all of these tools helpful!
Steps
Code:
1. Boot to Recovery
2. Flash SmartPart FZ (partition SD card right on your phone!)
3. Flash Copy-ROM (copy ROM --- all except boot image --- from EMMC to SD card)
4. Flash Atrix Boot Emporium V3.0 (boot ROM on SD card to verify success)
5. Flash another ROM of your choice to EMMC and reboot (optional)
Links
SmartPart-V1.0-signed.zip: http://www.mediafire.com/?wm96y92g3lla3ot
Copy-ROM-V1.0-signed.zip: http://www.mediafire.com/?i068xs1ktdkd183
Atrix-Boot-Emporium-V3.0-signed.zip: http://www.mediafire.com/?zsf4is8fbzs7sf9
All zips tested working on my AT&T Atrix + Samsung 32GB Class 10 SD using ClockworkMod Recovery 5.0.2.0.
If everything goes well, you will have demonstrated "standalone" dual boot capability on your Atrix beauty without a computer! In fact, "unlisted" ROMs may be supported. For example I downloaded upndwn4par's CSROM V7.0 (26 Jan 2013), ported it to SD and then successfully booted it with faux's 1.0 GHz GB boot image featured in Emporium.
Walk-Through
Step 1: I prefer ClockworkMod Recovery 5.0.2.0 as it appears to be the most compatible recovery for Atrix.
Step 2: SmartPart FZ shrinks your (external) SD card's FAT32 partition by 4GB and adds three new “ext” partitions: /system, /cache and /data of ample size to host virtually any Android ROM. SmartPart FZ takes about 30-45 seconds to partition a Class 10 card.
Important! You MUST flash SmartPart FZ from internal memory (“choose zip from internal sdcard”) because if you flash it from external memory, your SD card gets mounted and you can't partition a mounted filesystem. Also it is a good idea to flash SmartPart FZ immediately after booting to CWM; else your SD card could get mounted accidentally.
Not sure you want dual boot? Just select the “Restore” option and Smart Part FZ restores your SD to its original state by removing any existing ext partitions (up to three consecutive partitions) and growing your FAT32 partition back to its original size. This takes about 10-15 seconds on a Class 10.
Note: SmartPart FZ is fundamentally the same as its shell script predecessor ( http://forum.xda-developers.com/showthread.php?t=1651356 ) --- except that FZ runs unattended and does not backup anything.
Step 3: Copy-ROM, with the “EMMC to SD Card” option selected, copies all files on /system, /cache and /data files to the equivalent SD card ext partitions created in Step 2. Your EMMC ROM becomes a “live backup” on SD that you can boot to, thus freeing up EMMC to host another ROM of your choice.
One advantage of copying a ROM to SD is that you can first configure it the way you wish (GApps etc.), and then copy it over instead of having to flash individual customized zip files to SD. Then you're ready to flash a different ROM to EMMC, or blast off with a fully redundant system.
Copy-ROM uses the “cp -a” command, which I have found to be several times faster than cloning partitions. How much faster depends partly on disk usage since cloning copies everything, including empty space. Example: Port CM10 Liquid Smooth with ~100 total apps to a Class 10 SD. Clone ROM takes 15 minutes. Copy-ROM takes less than 2 minutes.
Another advantage of copying files over cloning partitions is that you don't have to worry about partition size mismatch. And I would not want to modify EMMC partitions --- too scary for me.
Step 4: Use Emporium V3.0 to boot a supported ROM whether it is hosted on EMMC or SD. Emporium contains boot images and corresponding /system/lib/modules for:
Code:
ICS MROM
ICSROM
CM10 epinter (Stock and OC1300)
CM10 Th3Bill (AOKP, Liquid Smooth and MIUI)
CM7 MROM (HV and SV)
CM7 Neutrino (EE, GT and GT+)
GB MROM (HV and SV)
GB NottachTrix (ATT and faux 1.00, 1.30 and 1.45)
Emporium V3.0 is less than 120 MB compressed and 10-15% more uncompressed. Each file named “boot.img” was lifted from its respective ROM zip. Each file named “boot-sd.img” exactly matches its big brother boot.img, except that ramdisk was modified to redirect ROM filesystem mounts from EMMC to SD:
Code:
/system: mmcblk0p12 to mmcblk1p2
/cache: mmcblk0p15 to mmcblk1p3
/data: mmcblk0p16 to mmcblk1p4
except for CM10 boot images. Please read CM10 Notes below.
Emporium Options
One of the dilemmas associated with dual booting is how to clear /cache and or /data. Of course CWM can do this, but only for ROMs hosted on EMMC: It does not recognize ROMs hosted on SD. And CWM is a little cumbersome to use since the clearing options are not all on one page. Emporium addresses these issues by displaying a single page with options to:
Code:
Clear /cache and /data/dalvik-cache
Clear /data (BE CAREFUL)
on EMMC or SD depending on the option selected on the first page. Now you can conveniently boot to a jet clean ROM whether it is hosted on EMMC or SD. Of course if you just copied a healthy ROM to SD, it is probably not necessary to clear.
I will explain the third option: Extract Boot Files to /sdcard/Boot later.
All three options are null by default.
Step 5: Nothing new here if you've ever flashed a ROM.
Now if for some reason you want to reverse the process and copy a ROM from SD Card to EMMC, just flash Copy-ROM and this time select the “SD to EMMC” option. Then flash Emporium or fastboot your EMMC ROM with the boot image of your choice. You may want to Nandroid-backup or Titanium Backup before doing a reverse copy.
Of course there are faster ways to switch between ROMs. But the tools presented here give your Atrix a simplified, standalone dual boot capability using all flashable zips.
Once you're comfortable using these flashable zip tools, you can then move onto “live” boot switching using all soft keys. To that end, I rolled up all of Emporium's boot images and my simplified boot switcher “boot-rom.sh” to a single directory named “Boot” which also includes the user-configurable subdirectories ROM1 and ROM2. Just select Emporium's option: Extract Boot Files. This extracts Emporium's Boot directory and its contents to the top directory of your SD card. After that you can copy your ROM boot images to Boot/ROM1 and Boot/ROM2 using Root Explorer or other suitable app. Copy boot.img to {path-to-SD}/Boot/ROM1 and boot-sd.img to {path-to-SD}/Boot/ROM2.
Now you can switch “live” between ROMs or boot to recovery using the appropriate command string:
Code:
sh boot-rom.sh (reboot to current ROM)
sh boot-rom.sh 1 (boot to ROM1)
sh boot-rom.sh 2 (boot to ROM2)
sh boot-rom.sh 3 (boot to Recovery)
Here is Emporium's boot-rom.sh:
Code:
#!/system/bin/sh
echo Motorola Atrix Dual Boot ROM1 emmc or ROM2 SD card
echo sendust7 @ xda developers
echo
echo Usage: sh boot-rom.sh N
echo where N = blank \(reboot to current ROM\)
echo 1 \(reboot to ROM1\)
echo 2 \(reboot to ROM2\)
echo 3 \(reboot to recovery\)
echo
echo "Home directory: $HOME"
echo
if [ $# -eq 0 ]; then
echo Rebooting to current ROM. Please wait...
sleep 3
reboot
elif [ $1 -eq 1 ]; then
if [ -f $HOME/ROM1/boot.img ]; then
cat $HOME/ROM1/boot.img > /dev/block/mmcblk0p11
echo Rebooting to ROM1. Please wait...
sleep 3
reboot
else
echo "boot.img not found. Check home directory."
exit 1
fi
elif [ $1 -eq 2 ]; then
if [ -f $HOME/ROM2/boot-sd.img ]; then
cat $HOME/ROM2/boot-sd.img > /dev/block/mmcblk0p11
echo Rebooting to ROM2. Please wait...
sleep 3
reboot
else
echo "boot-sd.img not found. Check home directory."
exit 1
fi
elif [ $1 -eq 3 ]; then
echo Rebooting to recovery. Please wait...
sleep 3
reboot recovery
else
echo "Invalid option. See Usage."
exit 1
fi
return 0
Note that boot-rom.sh is more robust than previous versions. The improved logic displays the $HOME directory and also displays an error message if it can't find ROM1/boot.img or ROM2/boot-sd.img under $HOME. If you are using Script Manager to launch boot-rom.sh, go to Settings>More>Advanced>Configuration, set Home directory to {path-to-Boot} (for example, “/storage/sdcard1/Boot” for CM10), press field at bottom to select Home directory, then select “Export $HOME” and “Browse as root”. So when you launch boot-rom.sh from Script Manager, the $HOME directory should be: {path-to-SD-card}/Boot. If not, you get an error message if you enter an argument of 1 or 2 in the command string.
Be sure to launch boot-rom.sh as root.
CM10 Notes
If you unpack any of Emporium's CM10 files named “boot-sd.img”, note that I made two small changes in ramdisk in addition to rerouting filesystem mounts:
The “init” executable was replaced with the MROM ICS init
init.olympus.rc was modified to grant elevated privileges in mkdir /storage/sdcard{0,1} per the MROM ICS init.olympus.rc
I found these two additional steps necessary to successfully boot CM10 from SD and to make apps run properly. That said, these “boot-sd.img” files should be viewed as experimental, as your mileage may differ. But no kernels were modified.
I think that porting CM10 to SD has some merit as the /system partition is easily up-sized to hold apps moved from the /data partition. Why would I make this obscure statement? Well it turns out that CM10 apps running under /system appear to have more privileges than those running under /data. I demonstrated this behavior on at least two different CM10 builds hosted on both EMMC and SD using “aLogcat” a GUI-based system logcat generator. When I launched aLogcat under /data/app, it would not display logcat to screen nor save results to a file. Then I moved it to /system/app and the problems disappeared.
Enjoy.
Troubleshooting
No wifi? Try re-flashing with Emporium since it refreshes /system/lib/modules.
Soft-brick? You may have attempted to boot a non-existent, corrupt or incompatible ROM.
Unusually fast completion of zip flash? An error has probably occurred, and you may need adb and recovery log to debug.
Disclaimer: Standard disclaimers apply.
Credits: Embedded in the zip files.
Photos and Screenshots
SmartPart FZ Before and After (in adb shell):
{
"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"
}
Emporium V3.0 Directory Structure
More on the way!

beautiful
B-e-a-u-t-i-f-u-l

Great work......I will try it. Thanks
from the (M)ATRIX...

Awesome stuff, as usual.

can you explain what exactly is this? what we will be able to do with it?

antmiu2 said:
can you explain what exactly is this? what we will be able to do with it?
Click to expand...
Click to collapse
It automates dual ROM setup and usage.

antmiu2 said:
can you explain what exactly is this? what we will be able to do with it?
Click to expand...
Click to collapse
It generates a "live" backup of your existing ROM on your SD card --- a ROM you can boot to. Then you can flash another ROM to internal memory just as you normally would.
If all goes well, you will have successfully dual booted your Atrix.
Here's the original xda article on dual booting Atrix: http://www.xda-developers.com/android/atrix-4g-dual-booting-method-for-linux-and-windows/

sendust7 said:
If you are using Script Manager to launch boot-rom.sh, go to Settings>More>Advanced>Configuration, set Home directory to {path-to-Boot} (for example, “/storage/sdcard1/Boot” for CM10), press field at bottom to select Home directory, then select “Export $HOME” and “Browse as root”. So when you launch boot-rom.sh from Script Manager, the $HOME directory should be: {path-to-SD-card}/Boot. If not, you get an error message if you enter an argument of 1 or 2 in the command string.
Click to expand...
Click to collapse
Hi sendust. Thank you very much! :good:
Managed to succesfully run TheBill's PA 299 from my sdcard (using AOKP boot.img) and restore and run a backup of a GB rom (nottachtrix based) to/from emmc.
I also managed to reboot from GB to PA299 using Script Manager by following the above quoted steps.
I can't seem to get Script Manager to run the same script from PA299 using 1 as argument to reboot into my GB rom. I did set Home directory as instructed to /storage/sdcard1/Boot but the log still says Home = / and it returns boot.img not found.
Any help would be appreciated
cheers
n1c00_

n1c00_ said:
Hi sendust. Thank you very much! :good:
Managed to succesfully run TheBill's PA 299 from my sdcard (using AOKP boot.img) and restore and run a backup of a GB rom (nottachtrix based) to/from emmc.
I also managed to reboot from GB to PA299 using Script Manager by following the above quoted steps.
I can't seem to get Script Manager to run the same script from PA299 using 1 as argument to reboot into my GB rom. I did set Home directory as instructed to /storage/sdcard1/Boot but the log still says Home = / and it returns boot.img not found.
Any help would be appreciated
cheers
n1c00_
Click to expand...
Click to collapse
Great to hear of your success!
I experienced similar behaviour with Script Manager (SM) running under /system/app. Then I moved it to /data/app and the problem went away.
If SM resides in /data/app and still doesn't work, uninstall it and download the latest version from Play Store.
Here is SM (under /data/app) in action, booting from Neutrino 2.91 (ROM1) to Liquid Smooth (ROM2) ...

sendust7 said:
Great to hear of your success!
I experienced similar behaviour with Script Manager (SM) running under /system/app. Then I moved it to /data/app and the problem went away.
If SM resides in /data/app and still doesn't work, uninstall it and download the latest version from Play Store.
Click to expand...
Click to collapse
Thanks. SM already resides in data/app and reinstalation from Store didn't help.
I realise the problem is with SM and not with the script cause it runs fine in GB
Are there any other options?
Here's what I get
Thanks a million!
n1c00_

[Deleted --- Redundant.]

n1c00_ said:
Thanks. SM already resides in data/app and reinstalation from Store didn't help.
I realise the problem is with SM and not with the script cause it runs fine in GB
Are there any other options?
Here's what I get
Thanks a million!
n1c00_
Click to expand...
Click to collapse
I would check permissions for SM. Below is what I have for CM10 Liquid Smooth (scroll down to "os.tools.scriptmanager-1.apk"). Note that the permissions match those of the other apps.
Another option would be to configure a different app like Terminal Emulator to execute boot-rom.sh as root from the Boot directory.
[email protected]:~# adb kill-server
[email protected]:~# adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
[email protected]:/ # cd /data/app
[email protected]:/data/app # ls -ld *.apk
-rw-r--r-- root root 5433305 2013-02-02 16:35 Magazines.apk
-rw-r--r-- root root 6160306 2013-02-02 16:35 com.android.vending-1.apk
-rw-r--r-- root root 1345436 2013-02-02 16:35 com.devuni.flashlight-2.apk
-rw-r--r-- root root 5615781 2013-02-02 16:35 com.ebay.mobile-1.apk
-rw-r--r-- root root 6284122 2013-02-01 13:50 com.google.android.apps.currents-1.apk
-rw-r--r-- root root 7232165 2013-02-01 13:50 com.google.android.apps.maps-2.apk
-rw-r--r-- root root 3591566 2013-02-01 13:50 com.google.android.gm-2.apk
-rw-r--r-- root root 4075228 2013-02-01 13:50 com.google.android.gms-1.apk
-rw-r--r-- root root 6149925 2013-02-01 13:50 com.google.android.youtube-2.apk
-rw-r--r-- root root 16600426 2013-02-02 16:35 com.instagram.android-1.apk
-rw-r--r-- root root 5787419 2013-02-02 16:35 com.keramidas.TitaniumBackup-1.apk
-rw-r--r-- root root 316047 2013-02-02 16:35 com.liveov.shotuxtrial-1.apk
-rw-r--r-- root root 7116916 2013-02-02 16:35 com.mediafire.android-1.apk
-rw-r--r-- root root 6869418 2013-02-02 16:35 com.sirma.mobile.bible.android-1.apk
-rw-r--r-- root root 853905 2013-02-02 16:35 com.socialnmobile.dictapps.notepad.color.note-1.apk
-rw-r--r-- root root 417303 2013-02-02 16:35 com.speedsoftware.rootexplorer-1.apk
-rw-r--r-- root root 1004380 2013-02-02 16:35 com.sportstracklive.stopwatch-1.apk
-rw-r--r-- root root 98247 2013-02-02 16:35 eu.chainfire.cfbench-1.apk
-rw-r--r-- root root 1020803 2013-02-02 16:35 eu.chainfire.supersu-1.apk
-rw-r--r-- root root 84111 2013-02-02 16:35 eu.kowalczuk.rsync4android-1.apk
-rw-r--r-- root root 73631 2013-02-02 16:35 fr.depoortere.android.CircleBatteryWidget-1.apk
-rw-r--r-- root root 343102 2013-02-02 16:35 jackpal.androidterm-1.apk
-rw-r--r-- root root 781592 2013-02-02 16:35 jp.sblo.pandora.jota-1.apk
-rw-r--r-- root root 492578 2013-02-02 16:35 org.cohortor.gstrings-1.apk
-rw-r--r-- root root 1193795 2013-02-02 16:35 os.tools.scriptmanager-1.apk
-rw-r--r-- root root 141061 2013-02-02 16:35 se.qzx.isoextractor-1.apk
-rw-r--r-- root root 671989 2013-02-02 16:35 spinninghead.talkingstopwatchlite-1.apk
-rw-r--r-- root root 303317 2013-02-02 16:35 uk.co.nickfines.RealCalc-1.apk
[email protected]:/data/app #

sendust7 said:
I would check permissions for SM. Below is what I have for CM10 Liquid Smooth (scroll down to "os.tools.scriptmanager-1.apk"). Note that the permissions match those of the other apps. Another option would be to configure a different app like Terminal Emulator to execute boot-rom.sh as root from the Boot directory.
Click to expand...
Click to collapse
After few hours of trial and error finally managed to get it working!
Sendust you're a star!
SM just didn't want to configure (probably) because it was installed while running rom from sd. Once I got it installed running the rom on emmc and copied emmc to sd it kept the configuration. I just had to change the argument.
Thanks and keep up the good work :good:

I dont knlw if i am the only one but its seems I cant use dualboot with ICSROM on SD and CM10 on EMMC, everything show to have been done properly but when i try to boot into ICSROM i have a black screen (no bootlogo ), and when i flashed mrom kernel on ICSROM i get the bootlogo for ever ... :crying:
Any ideas ?
PS i use bootemporium

DBSS Troubleshooting
johnannis said:
I dont knlw if i am the only one but its seems I cant use dualboot with ICSROM on SD and CM10 on EMMC, everything show to have been done properly but when i try to boot into ICSROM i have a black screen (no bootlogo ), and when i flashed mrom kernel on ICSROM i get the bootlogo for ever ... :crying:
Any ideas ?
PS i use bootemporium
Click to expand...
Click to collapse
Troubleshooting manual in work.. I will try to have something in a few hours.
[UPDATE, 05 Feb 2012 1315 PST]
I duplicated the problem on my Atrix. In fact I couldn't even get ICSROM 1.4.6 to boot from EMMC. I tried reformatting /system, /cache and /data and re-flashing. Got a fixed Big-M with fadeout, followed by a single-blink and then blank for many minutes.
Then I CWM flashed MROM boot.img using Emporium 3.0 but it hung up at the pulsating Big-M. In retrospect, I may not have waited long enough.
Then I flashed MROM ICS right over ICSROM and it booted.
Then I reflashed ICSROM 1.4.6 and rebooted. Same behavior as at the start.
Then I CWM factory reset and flashed ICSROM 1.4.3 (previous version). This time, I got pulsating Big-M for several minutes (expected due to factory reset) followed by Location Consent screen, indicating a successful boot. So ICSROM 1.4.3 appears to work.
Then I flashed Emporium's ICSROM 1.4.6 boot.img (EMMC) and rebooted. Big-M came up and then... blank --- as before.
So I reinstalled 1.4.6 ROM, factory reset, fastbooted the 1.4.3 boot image (pulled from ICSROM 1.4.3 zip file) and voila... 1.4.6 came up.
These results intimate an issue with the ICSROM 1.4.6 kernel.
Unfortunately there is not a straightforward means of obtaining kernel debug messages (dmesg >> dmesg.txt) on a failed boot: http://bootloader.wikidot.com/linux:android:kmsg
Now if you Copy-ROM ICSROM 1.4.6 to SD, you need a modified boot image. Try this one:
Link (boot-icsrom-1.4.3-sd.img): http://www.mediafire.com/?57b25z5hkid2bc2
Modified init.olympus.rc code (ramdisk):
Code:
mount ext3 /dev/block/mmcblk1p2 /system noatime nodiratime wait ro barrier=1
mount ext3 /dev/block/mmcblk1p4 /data nosuid nodev noatime nodiratime wait barrier=1
mount ext3 /dev/block/mmcblk1p3 /cache nosuid nodev noatime nodiratime wait barrier=1
[UPDATE, 05 Feb 2012 1630 PST]
OK. I may have found a problem with the stock ICSROM 1.4.6 boot.img. If you unpack it and navigate to /ramdisk/default.prop, you will notice several "read-only" settings --- ones that can only be modified in ramdisk. I made one small change: Set ro.debuggable=1 (instead of 0). Here is the modified default.prop:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.sys.usb.config=mtp
After making this one simple change, I repacked the 1.4.6 boot.img (boot-repack.img) then did the following:
Code:
Reboot to CWM
Perform factory-reset
Flash ICSROM 1.4.6
Reboot to fastboot
fastboot flash boot boot-repack.img
fastboot reboot
This time, I still got the familiar Big-M fadeout followed by the single-blink Big-M. But then 30 seconds later, the pulsating Big-M appeared, and several minutes after that, ICSROM 1.4.6 finally came up.
Link (boot-icsrom-146-emmc.img): http://www.mediafire.com/?5da1ngcny8px14w
Note: In the ICS MROM boot.img, "ro.debuggable" is already set to 1.
The short answer is that the ICS kernels are presently not stable, which is why I hesitated to include them in Atrix Boot Emporium.
Hope this helps.

what happens if i use the smart formater to my ext.sdcard and on the card are swap partitions and webtop partition? do i lose them??

Hai_Duong said:
what happens if i use the smart formater to my ext.sdcard and on the card are swap partitions and webtop partition? do i lose them??
Click to expand...
Click to collapse
I deliberated much about this and decided that for V1.0 I would stick with three (primary) ext partitions.
So yes, if you flash SmartPart FZ V1.0 and select the "Create" option, it will first do this:
Code:
echo "We first remove any existing partitions beyond the FAT32 partition..."
#echo "ENTER to continue; CNTL-Z to exit." ; read
parted /dev/block/mmcblk1 rm 4 > /dev/null 2>&1
parted /dev/block/mmcblk1 rm 3 > /dev/null 2>&1
parted /dev/block/mmcblk1 rm 2 > /dev/null 2>&1
parted /dev/block/mmcblk1 print
and then it wll create three new partitions, one each for /system, /cache and /data:
Code:
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val3" "$val4"
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val5" "$val6"
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val7" "$val8"
where the $val parameter values are partition boundaries based on the FAT32 right-hand boundary and fixed partition sizes defined in the shell script.

sendust7 said:
I deliberated much about this and decided that for V1.0 I would stick with three (primary) ext partitions.
So yes, if you flash SmartPart FZ V1.0 and select the "Create" option, it will first do this:
Code:
echo "We first remove any existing partitions beyond the FAT32 partition..."
#echo "ENTER to continue; CNTL-Z to exit." ; read
parted /dev/block/mmcblk1 rm 4 > /dev/null 2>&1
parted /dev/block/mmcblk1 rm 3 > /dev/null 2>&1
parted /dev/block/mmcblk1 rm 2 > /dev/null 2>&1
parted /dev/block/mmcblk1 print
and then it wll create three new partitions, one each for /system, /cache and /data:
Code:
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val3" "$val4"
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val5" "$val6"
parted /dev/block/mmcblk1 mkpartfs primary ext2" $val7" "$val8"
where the $val parameter values are partition boundaries based on the FAT32 right-hand boundary and fixed partition sizes defined in the shell script.
Click to expand...
Click to collapse
oh thats sad. i wanted to try this because i love to test roms but i dont want to give up on my webtop partition.

Using your 1.4.3 boot.img and it still doesnt want to boot in the rom Dont know why, but after i flash the emmc with another rom it doesnt boot, before that it booted from sd
Sent from my Nexus 4 using xda app-developers app

johnannis said:
Using your 1.4.3 boot.img and it still doesnt want to boot in the rom Dont know why, but after i flash the emmc with another rom it doesnt boot, before that it booted from sd
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
OK that's good info. The file: boot-icsrom-1.4.3-sd.img was intended to boot 1.4.6 on SD. But of course it does not have the "ro.debuggable=1" fix. So when I got 1.4.6 to boot on EMMC using the fix:
Link (boot-icsrom-146-emmc.img): http://www.mediafire.com/?5da1ngcny8px14w
I realized that boot-icsrom-1.4.3-sd.img probably would not boot 1.4.6 on SD. And such was the case for me.
Did you try this:
Code:
Reboot to CWM
Perform factory-reset
Flash ICSROM 1.4.6
Reboot to fastboot
fastboot flash boot boot-icsrom-146-emmc.img
fastboot reboot
I would not be surprised if you got different results based on what the ICSROM author says...
http://forum.xda-developers.com/showthread.php?p=37561654&highlight=work#post37561654 ,
]If someone can post a link I will definitely take a look at it.
But please don't your hopes too high guys. Remember this ROM runs different on every device.
Click to expand...
Click to collapse
[UPDATE 07 Feb 2013, 0745 PST]
So I unpacked the ICSROM 1.4.6 and MROM boot images and found that the ICSROM init.olympus.rc (the device-specific script launched at boot time by the init process) is three times the size of MROM's init.olympus.rc.]. More to follow...

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

[WIP/DEV Only] Ubuntu Touch on Nexus S

This topic is for developers and future testers, we are at least 3-4 people that try to boot Ubuntu Touch on Nexus S. Joint work would be better, don't you think?
IRC Channel: irc.androidirc.com #ubuntu-touch-crespo
Mibbit: http://client00.chat.mibbit.com/?server=irc.androidirc.org&channel=#ubuntu-touch-crespo

So now I am here: http://pastebin.com/RnvjqMBx
Blobs list: https://github.com/CyanogenMod/android_device_samsung_crespo/blob/cm-10.2/proprietary-blobs.txt

nyl said:
So now I am here: http://pastebin.com/RnvjqMBx
Blobs list: https://github.com/CyanogenMod/android_device_samsung_crespo/blob/cm-10.2/proprietary-blobs.txt
Click to expand...
Click to collapse
You can have tricks on the REAME-20130807 https://drive.google.com/#folders/0B_fPIBhY3pcRSVVBSDY1TjJKQXc
---------- Post added at 07:59 PM ---------- Previous post was at 07:54 PM ----------
Tygerlord said:
You can have tricks on the REAME-20130807 https://drive.google.com/#folders/0B_fPIBhY3pcRSVVBSDY1TjJKQXc
Click to expand...
Click to collapse
First step I think is trouble of data space (up to 1Go) seems too small
My goals is to modify script of saucy-preinstalled-touch-armhf.zip to
1 ) create /sdcard/tubuntu.img, ext4 image disk of up to 4 Go
2 ) mount loop /sdcard/tubuntu.img to /data/tubuntu
3 ) create symlink betwen /data/tubuntu/ubuntu /data/ubuntu
Q: Why I don't mount directly tubuntu.img to /data/ubuntu
A: deploy script use temp directories that need to be moved.
Currently process fail on creating file system tubuntu.img with code:
busybox mkfs.ext2 -F /sdcard/tubuntu.img
mkfs.ext2: lseek: Value too large for defined data type :crying::crying:
My saucy-preinstalled-touch-armhf+crespo.zip can be found here:
https://drive.google.com/#folders/0B_fPIBhY3pcRSVVBSDY1TjJKQXc
This can be installed with recovery (and should break anything). It take up to 10 minutes to install.

try making it vfat (not sure if ubuntu reads vfat), anyway something like this should be for a 4gb vfat i think.
Code:
mkdir /data/tubuntu
su
dd if=/dev/zero of=/sdcard/tubuntu.img bs=1024 count=4194340
busybox mkfs.vfat /sdcard/tubuntu.img
mount -o loop -t vfat /sdcard/tubuntu.img /data/tubuntu
Edit: http://e2fsprogs.sourceforge.net/ would be better for creating ext4 image

nyl said:
try making it vfat (not sure if ubuntu reads vfat), anyway something like this should be for a 4gb vfat i think.
Code:
mkdir /data/tubuntu
su
dd if=/dev/zero of=/sdcard/tubuntu.img bs=1024 count=4194340
busybox mkfs.vfat /sdcard/tubuntu.img
mount -o loop -t vfat /sdcard/tubuntu.img /data/tubuntu
Edit: http://e2fsprogs.sourceforge.net/ would be better for creating ext4 image
Click to expand...
Click to collapse
vfat can't support linux os...
Never mind, I've solved my problem.
Now I've a disk image tubuntu.img with saucy-preinstalled-touch-armhf expended on it.
I've /data/tubuntu to mount this image and symbolic link /data/ubuntu -> /data/tubuntu/ubuntu :good:
Next step, build kernel for crespo with mounting /sdcard/tubuntu.img and use root dir /data/ubuntu...

Tygerlord said:
vfat can't support linux os...
Never mind, I've solved my problem.
Now I've a disk image tubuntu.img with saucy-preinstalled-touch-armhf expended on it.
I've /data/tubuntu to mount this image and symbolic link /data/ubuntu -> /data/tubuntu/ubuntu :good:
Next step, build kernel for crespo with mounting /sdcard/tubuntu.img and use root dir /data/ubuntu...
Click to expand...
Click to collapse
almost done with the kernel hope it will work )
edit, find kernel here: https://drive.google.com/?tab=wo&authuser=0#folders/0B34Kseus4HL2ZEM5Mjd4YzNyREE

nyl said:
almost done with the kernel hope it will work )
Click to expand...
Click to collapse
Previous link for shared documents seems not working, this one should work better... I hope

okay i got into adb shell tried to manually mount /data/ubuntu, didn't work

Current test
nyl said:
okay i got into adb shell tried to manually mount /data/ubuntu, didn't work
Click to expand...
Click to collapse
mount -t ext4 /sdcard/tubuntu.img /data/tubuntu
This work for me, but my kernel build don't. Seem having trouble mounting system partition see attached file for dmesg.

Ok after lot of efforts I've install script creating ubuntu.img (based on saucy-preinstalled-touch-armhf.zip) on sdcard and kernel,
kernel mount correctly ubuntu.img but stay locked on google logo...
Adb is working and I retreive dmesg (see debug.txt file)
There are plenty of error and I can't understand what happen , missing knowledge on ubuntu touch process to debug that...
Since first release start on october 17 I think that developpers will be too busy for help now...
I can't progress anymore, current developments are available here
So I wait for help or more documentations on ubuntu touch process to continue...

Tygerlord said:
Ok after lot of efforts I've install script creating ubuntu.img (based on saucy-preinstalled-touch-armhf.zip) on sdcard and kernel,
kernel mount correctly ubuntu.img but stay locked on google logo...
Adb is working and I retreive dmesg (see debug.txt file)
There are plenty of error and I can't understand what happen , missing knowledge on ubuntu touch process to debug that...
Since first release start on october 17 I think that developpers will be too busy for help now...
I can't progress anymore, current developments are available here
So I wait for help or more documentations on ubuntu touch process to continue...
Click to expand...
Click to collapse
Last kernel seem produce less errors.. (but display still not working). I've message on log lxc-android-boot.log,
cp: cannot stat '/usr/lib/lxc-android-config/70-crespo.rules': No such file or directory
but I've created file (make a copy of other) and error still present, very strange!!!
Matsca09 Any news??

[RECOVERY] Unofficial TWRP 2.8.5.2 by Syhost (for 4G)

As we all know our device does not get official TWRP builds yet. Hopefully now that the sources have been released, it's just a matter of time before this happens, but meanwhile an unofficial TWRP 2.8.5.2 build has just been released by Syhost. More information is available on his blog (in Chinese). To install:
Download the file from Baidu
The password (posted publicly on Syhost's blog) is sa89.
The download is an .exe file. It appears to be just an installation script but I did not run it. Instead, I just unpacked it with WinRAR (right-click on the file).
Inside there is the file recovery.img, which can be flashed with standard methods. The way I do it:
Code:
adb reboot bootloader
fastboot erase recovery
fastboot flash recovery recovery.img
Alternatively, if you just want to test it without replacing your current recovery:
Code:
adb reboot bootloader
fastboot boot recovery.img
The interface is all in Chinese. If you're comfortable with that language, you can stop here. However, what I did was:
Keep the kernel from Syhost's version.
Replace the RAM Disk image with files from the stock TWRP for another device: I used openrecovery-twrp-2.8.5.2-mako.img, as I already had the file.
Integrate the TWRP Materialised Play theme in the appropriate resolution (720x1280). The file is 2850_v1_720_play.zip and you'll also want to replace the curtain.jpg file with one of the splash screens from here: splashes_720.zip.
Delete the following files:
Code:
/fstab.mako
/ueventd.mako.rc
Copy over the following files from Syhost's RAM Disk image:
Code:
/default.prop
/file_contexts
/init.rc
/init.recovery.qcom.rc
/property_contexts
/seapp_contexts
/selinux_version
/sepolicy
/service_contexts
/ueventd.rc
Replace /etc/recovery.fstab with the following contents:
Code:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered wait,check
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc wait,check
/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 nosuid,nodev,barrier=1,data=ordered,nodelalloc wait
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:radio_efs_file:s0 wait
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/recovery /recovery emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/misc /misc emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/modem /radio emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/sbl1 /sbl1 emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/tz /tz emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/rpm /rpm emmc defaults defaults
/dev/block/platform/msm_sdcc.1/by-name/aboot /aboot emmc defaults defaults
/dev/block/mmcblk1p1 /external_sd vfat rw,noatime,nodev,noexec,nosuid,uid=1000,gid=1015,fmask=0002,dmask=0002,utf8 defaults
/dev/block/sda1 /usbdisk vfat rw,noatime,nodev,noexec,nosuid,uid=1000,gid=1015,fmask=0002,dmask=0002,utf8 defaults
Replace /etc/twrp.fstab with the following contents:
Code:
/boot emmc /dev/block/platform/msm_sdcc.1/by-name/boot
/recovery emmc /dev/block/platform/msm_sdcc.1/by-name/recovery
/system ext4 /dev/block/platform/msm_sdcc.1/by-name/system
/data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
/cache ext4 /dev/block/platform/msm_sdcc.1/by-name/cache
/external_sd vfat /dev/block/mmcblk1p1 flags=display="SD Card";storage;wipeingui;removable
/usbdisk vfat /dev/block/sda1 flags=display="USB Disk";storage;removable
.
I don't think I can post the resulting image file, as none of this is my work and I don't have the original authors' permission but if you follow the above instructions, you'll end up with a working TWRP 2.8.5.2 recovery image with the English interface that also looks great thanks to the excellent TWRP Materialised theme. Haven't had the chance to test it extensively yet but everything appears to work just great at this point. Screenshots - before and after:

That's really great find. And helpful tip. Cool.
Btw, I do think you can share the resulting TWRP, in English and themed, by simply crediting the original dev/page for the find. Without credit, it won't be cool for sure, but with credit, it's good.

MTP Status
MTP does not appear to work in the modified version but neither does it work for me in the original, unmodified one, even if the description on Syhost's blog seems to suggest it should. I don't really use this function so I'll leave it like that at the moment, as it's not immediately obvious what's going on. If someone wants to take over from here, the following might be useful:
Logcat:
Code:
MtpServer::run fd: 16
E:request read returned -1, errno: 22, exiting MtpServer::run loop
TWRP Source, mtp/mtp_MtpServer.cpp:55
Code:
int fd = open(mtp_device, O_RDWR);
TWRP Source, mtp/mtp_MtpServer.cpp:47
Code:
#ifdef USB_MTP_DEVICE
#define STRINGIFY(x) #x
#define EXPAND(x) STRINGIFY(x)
const char* mtp_device = EXPAND(USB_MTP_DEVICE);
MTPI("Using '%s' for MTP device.\n", EXPAND(USB_MTP_DEVICE));
#else
const char* mtp_device = "/dev/mtp_usb";
#endif
Android Source, include/errno.h:55
Code:
#define EINVAL 22 /* Invalid argument */

itskapil said:
That's really great find. And helpful tip. Cool.
Btw, I do think you can share the resulting TWRP, in English and themed, by simply crediting the original dev/page for the find. Without credit, it won't be cool for sure, but with credit, it's good.
Click to expand...
Click to collapse
Thanks! I've PMed Syhost and will upload the image if he's OK with it.

Aqq123 said:
Thanks! I've PMed Syhost and will upload the image if he's OK with it.
Click to expand...
Click to collapse
:good: