Related
I have a bit of a problem.
I have dangerspl, latest radio & cyanogen recovery 1.4 +jf.
I've tried to install numerous roms on my G1:
Both modaco v2 hero roms from http://android.modaco.com/content/h...m-is-here-2-versions-based-on-the-new-update/
also, cyanogen's 4.0.4 from http://forum.xda-developers.com/showthread.php?t=537204
and JAC;s xrom v1.4r3 from http://forum.xda-developers.com/showthread.php?t=543621
The process I'm following is
Code:
alt+w wipe in recovery then,
adb shell mount /sdcard
push the zip over with adp push whatever.zip /sdcard/whatever.zip
and finally apply any zip from sd.
Installation gets to 'copying files' then I get some errors:
Code:
E: Can't chown/mod /system/xbin/busybox (No such file or directory)
E: Failure at line 41:: set_perm 0 0 04755 SYSTEM:xbin/busybox.
Installation aborted.
I've sniffed around and found /system is full via df -h.
Code:
Filesystem Size Used Available Use% Mounted on
tmpfs 47.8M 0 47.8M 0% /dev
/dev/block/mmcblk0p1 1.3G 105.3M 1.2G 8% /sdcard
/dev/block/mtdblock3 90.0M 90.0M 4.0K 100% /system
/dev/block/mtdblock4 30.0M 1.1M 28.9M 4% /cache
Is it safe to rm -rf /system or will it turn my g1 into a shiny black paperweight?
Thanks,
Ruint.
edit: seems /system/app is full of apk/odex files, is it safe to remove them?
edi2: looks like after wiping, /data is never remounted, even if I mount it, it looks like it's unused in the install procsess. :/
repartition ur card to give urself more space. u can pull ur apps off of the partition. or write down what u have and reinstall all of them. also make sure u have the right spl, radio image, and if u haven't grab cyanogen's 1.4 recovery to help with the partitioning. of u can partition with ubuntu or paragon. if u need help check my sig and get back to me on gmail, or gtalk
EDIT: i see that u already have the radio, spl and recovery lol
same problem as yours.......
I can install some roms (CM 3.x, CM 4.x, zeroXd and even some hero ones), but while flashing others (JAC, MoDaCo, ecc.) I receive errors like the one you said and sometime line 88 copy_dir error.
Tried repairing the sdcard filesystem but it didn't help.....maybe it's a space related problem, as you suggested?
ps latest radio, recovery, and spl for me, too.......
I've had these errors and usually what it means is the rom.zip file is corrupt. Are you guys downloading the zip files from your phone? If so try downloading from a computer and then putting it on your phone. Don't use ADB just use windows. This solved my problem.
I'm downloading from the pc. Tried re-downloading and a different microsd card but the situation hasn't improved much....... sigh
any one found a fix for this issue...i cant seem to load newer ROMS..i keep gettin this error...pls help
I'm fairly certain it has nothing to do with the SD. The /system folder is stored on the phone's memory, not on the SD card. I'm looking into modifying the install script to use the busybox that is in /system/bin
EDIT: oh and "rm -r"ing anything is scary. I'm pretty sure that the whole system folder gets overwritten by most ROM install scripts, but why delete it?
EDIT: So I tried removing the copy commands from the install script and then copying the stuff manually and this happened: I first "rm -r"ing the system folder which removes all but the lost+found, then I tried copying the system folder from the ROM manually using "cp -r * /system". Then I got a very tell-tale error: not enough room on device. doing a quick "df -h" shows that my system folder is only allowed 67.5M of space, which is less than what ruin posted as his. anyone know of a way to resize?
i can install any rom on my x1..i try to but the screen just hang... pLLLLLSSSSS help
ruin said:
I have a bit of a problem.
I have dangerspl, latest radio & cyanogen recovery 1.4 +jf.
I've tried to install numerous roms on my G1:
Both modaco v2 hero roms from http://android.modaco.com/content/h...m-is-here-2-versions-based-on-the-new-update/
also, cyanogen's 4.0.4 from http://forum.xda-developers.com/showthread.php?t=537204
and JAC;s xrom v1.4r3 from http://forum.xda-developers.com/showthread.php?t=543621
The process I'm following is
Code:
alt+w wipe in recovery then,
adb shell mount /sdcard
push the zip over with adp push whatever.zip /sdcard/whatever.zip
and finally apply any zip from sd.
Installation gets to 'copying files' then I get some errors:
Code:
E: Can't chown/mod /system/xbin/busybox (No such file or directory)
E: Failure at line 41:: set_perm 0 0 04755 SYSTEM:xbin/busybox.
Installation aborted.
I've sniffed around and found /system is full via df -h.
Code:
Filesystem Size Used Available Use% Mounted on
tmpfs 47.8M 0 47.8M 0% /dev
/dev/block/mmcblk0p1 1.3G 105.3M 1.2G 8% /sdcard
/dev/block/mtdblock3 90.0M 90.0M 4.0K 100% /system
/dev/block/mtdblock4 30.0M 1.1M 28.9M 4% /cache
Is it safe to rm -rf /system or will it turn my g1 into a shiny black paperweight?
Thanks,
Ruint.
edit: seems /system/app is full of apk/odex files, is it safe to remove them?
edi2: looks like after wiping, /data is never remounted, even if I mount it, it looks like it's unused in the install procsess. :/
Click to expand...
Click to collapse
Where the hell is your /system/sd partition?
If your trying to install a Hero rom it needs an ext partition.
According to this:
Code:
Filesystem Size Used Available Use% Mounted on
tmpfs 47.8M 0 47.8M 0% /dev
/dev/block/mmcblk0p1 1.3G 105.3M 1.2G 8% /sdcard
/dev/block/mtdblock3 90.0M 90.0M 4.0K 100% /system
/dev/block/mtdblock4 30.0M 1.1M 28.9M 4% /cache
Where is mmcblk0p2 (system/sd) at?
Is there a way to make all applications store their data in a folder other than /sdcard (root folder on the sd card) ?
I'm planning on rooting and thought that this time round I can keep my sdcard nice and organized by creating an "ApplicationData" folder in the root of the sdcard and somehow configuring android to use that.
On a similar note, can I move the DCIM (camera photos) to a different location too?
Will the below change-mount-point idea work?
Maybe as root we can
1) un-define /sdcard (in /etc/fstab) //or wherever its defined
2) define /sdcard as /dev/<hdb0>/ApplicationData //change hdb0 to the appropriate device/partition
thanks.
Yeah, I see your point... but quite frankly, I believe it's upto the app developers [my knowledge of the Android world is still from the stone-age!!]... if the app specifies that it's data will be stored in /sdcard/AppName, there's not much you can do, unless you can modify the app...
I was thinking that maybe as root we can
1) un-define /sdcard (in /etc/fstab) //or wherever its defined
2) define /sdcard as /dev/<hdb0>/ApplicationData
edit: added to post#1
britoso said:
I was thinking that maybe as root we can
1) un-define /sdcard (in /etc/fstab) //or wherever its defined
2) define /sdcard as /dev/<hdb0>/ApplicationData
edit: added to post#1
Click to expand...
Click to collapse
I did think of this too...
/sdcard --> /sd/AppData
rest of sd card --> /sd
but I think it would mean some other changes as well... for example... the mount usb functionality would have to be modified to mount/unmount a different volume...
So heres the contents of my fstab file:
Code:
C:\>adb shell cat /system/etc/fstab
/dev/block/mtdblock3 /system yaffs2 rw
/dev/block/mtdblock4 /cache yaffs2 rw
/dev/block/mtdblock5 /data yaffs2 rw
/dev/block/mmcblk0p1 /sdcard vfat rw
/dev/block/mmcblk0p2 /system/sd auto rw
/system/modules/modules.sqf /system/modules squashfs ro,loop
/system/xbin/xbin.sqf /system/xbin squashfs ro,loop
I'll try changing line 4 (/sdcard), I'm guessing /system/sd is for when I apps2sd is enabled.
Question: How do I escape from INSERT/EDIT mode in VI? Tried pressing trackball+1, trackball+1+2...didnt work
Hey britoso!
Keep us updated with your accomplishments. I, personally, am very interested in being able to achieve this.
Good luck!
update: that didnt work.
Note: the way to get the ESCAPE character is CONTROL + [ (hold the trackball then press [ ). The control key is configurable and defaults to the Jogball/TrackBall
here are the contents of my fstab file, the camera app is still writing to the root of the sdcard (/sdcard/DCIM)
Code:
C:\>adb shell cat /system/etc/fstab
/dev/block/mtdblock3 /system yaffs2 rw
/dev/block/mtdblock4 /cache yaffs2 rw
/dev/block/mtdblock5 /data yaffs2 rw
/dev/block/mmcblk0p1 /sdcard/AppData vfat rw
/dev/block/mmcblk0p2 /system/sd auto rw
/system/modules/modules.sqf /system/modules squashfs ro,loop
/system/xbin/xbin.sqf /system/xbin squashfs ro,loop
Heres the output of "df"
Code:
C:\>adb shell df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 197600 0 197600 0% /dev
tmpfs 4096 0 4096 0% /sqlite_stmt_journals
/dev/block/mtdblock3 148480 100088 48392 67% /system
/dev/block/mtdblock5 200960 63752 137208 32% /data
/dev/block/mtdblock4 97280 39628 57652 41% /cache
/dev/block//vold/179:1
15643712 6843256 8800456 44% /sdcard
@britoso
This is what I found out about mounts in Android...
The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a /etc/fstab file in Android).
And from what I see in your df output, it didn't mount /sdcard/AppData...
Have a few ideas in mind... gonna try 'em out now...
craigacgomez said:
gonna try 'em out now...
Click to expand...
Click to collapse
thanks for the info. Let us know how it works out.
Here's what I reached finally...
To achieve this, I have 2 ideas...
1. We gotta modify the init and change the SD mount point to AppData and add another for the rest of the SD... this however would require a rebuilt ROM (I can't edit init on the phone, need to edit init.c from the source)
2. We push some startup scripts to achieve this, but so far, I haven't been able to mount anything else on /sdcard (operation failed), but I think I'm doing something wrong...
Didn't get much time to experiment... and it mite be a busy end of week for me... but I'll try to squeeze in so time to get this...
Why not ask Cyanogen to do this for us in his next ROM?
Or your next favorite modder?
I'm sure they'll like this idea!?
theres a setting in /init.rc that may help
Code:
export EXTERNAL_STORAGE /sdcard
However / is mounted read-only
mount
rootfs on / type rootfs (ro,relatime)
Click to expand...
Click to collapse
Dual-booting has always intrigued me. I dual-boot between Windows and Linux on one of my computers, dual-boot between stock firmware and RockBox on my Sansa Fuze v2, and I decided to find out how to dual-boot my Galaxy Tab 2 7.0". It took a couple days of work, but I have found one way to do so using the external SD card.
In the future, if I can work it out, I will provide a method for dual-booting using only internal storage. Update: I have successfully tested an internal dualboot setup. I will post details later.
Warning: While I am not aware of any specific way this could brick your device, stuff happens, so don't blame me. I've tested this and found no problems, but you may not be the same.
To use this method, you need a microSD card at least 8GB in size. If you use 8GB, though, you will have pretty limited space for storage, so a card 16GB or greater is advised.
Preparing SD Card
Repartition your microSD card using whatever program suits you. You need to shrink the first storage partition to make room for the new system partitions. The new partitions should take at least 5GB, so be sure to leave at least 5.25GB. You can always resize later if you need to.
After shrinking your storage partition, create four ext4 partitions in this order: system (min 800MB, recommended 1.25GB), cache (min 500MB, recommended 700MB), data (min 3GB, recommended 5GB), and EFS (min 21MB, recommended 32MB).
Verify your partitions on your tablet by inserting the SD card, booting into CWM, and running "parted /dev/mmcblk1" (no quotes) over ADB shell.
Flashing External ROM
Now you just need a ROM to flash. Most ROMs are not packaged to run from external SD card. You MUST either use a provided ROM or edit one yourself. I provide here a repackaged version of the 8/28 CM10 nightly which can flash to and run from your SD card. If you want to edit a ROM yourself, see the bottom of this post.
Boot into CWM and backup. You will need your backed up boot image if anything goes wrong.
Now flash your ROM. It will install to the external SD card on the appropriate partitions if you did everything right. Reboot: you should be in your new ROM.
You'll probably want a Google Apps package. See below for packages for external dualboot.
Using Your Dual-Boot Setup
Your internal and external ROMs do not share internal storage, due to the odd nature of the SD card fuse tool.Your external ROM has an "internal SD card" of its own. You may find a way to mount the internal /data/media to the external ROM's /sdcard. My new ROM conversion script will add attempt to mount the internal ROM's storage to /storage/intSdCard
The ROMs I provide here include a script in /system/bin called "bootinternal." Run this from a terminal emulator or adb to switch from the external ROM back to the internal one. I have attached a script called "bootexternal" to this post. Use it on your internal ROM to switch to the external one (remember to set the executable permission).
In order for the boot switching scripts to work, you must do some preparation. On your external ROM, place the internal ROM's boot.img in /sdcard/Boot/internal.img. For your internal ROM, place your external ROM's boot.img in /sdcard/Boot/external.img.
If you ever need/watch to switch ROMs manually, run the following commands in a terminal emulator or over ADB, replacing "boot.img" with the boot image of the ROM you are switching to:
Code:
cat boot.img > /dev/block/mmcblk0p5
reboot
Alternatively, you could switch boot images using Mobile Odin.
Update: I would skip using my prepackaged ROMs now, because I have uploaded a converter script that will actually do a better job. These will configure the "bootinternal" and "bootexternal" scripts automatically.
If you ever need to wipe your data, cache, or dalvik cache, see the next post for CWM zips.
Downloads
Roms for External SD Card:
CyanogenMod 10 Nightly (8/28/2012)
AOKP P3113 Stable
Note that these are probably unnecessary now, because I provide a script to convert ROMs automatically on Linux.
Google Apps Packages for External SD Card:
Gapps for Jelly Bean - Use for CM10, AOKP, etc
Gapps for Ice Cream Sandwich - Use for stock, RomsWell, etc
If I ever have time, I plan to upload SD card images which you can use to partition your external SD card automatically.
---
Repacking a ROM for Dual-boot from SD Card
Note: You no longer need to do this manually. I have uploaded a script which automates the conversion process. See the next post for download.
First, you need to extract and unpack the boot image. There are tools and scripts available for this, so find one.
Once the boot image is unpacked, you need to edit init.espresso.rc on the ramdisk. Find where the partitions are mounted and change the code to look like this (yours may look slightly different depending on the ROM, but just be sure to replace the default partition mounts with those of your SD card partitions):
Code:
#mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS /system wait rw
mount ext4 /dev/block/mmcblk1p2 /system wait rw
#mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS /system ro remount
mount ext4 /dev/block/mmcblk1p2 /system ro remount
#mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data wait noatime nosuid nodev crypt discard,noauto_da_alloc
mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data2 wait noatime nosuid nodev crypt discard,noauto_da_alloc
mount ext4 /dev/block/mmcblk1p4 /data wait noatime nosuid nodev crypt discard,noauto_da_alloc
#mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/CACHE /cache wait noatime nosuid nodev nomblk_io_submit,errors=panic
mount ext4 /dev/block/mmcblk1p3 /cache wait noatime nosuid nodev nomblk_io_submit,errors=panic
#mount ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/EFS /efs wait rw
mount ext4 /dev/block/mmcblk1p5 /efs wait rw
Repack the boot image and stick it back into the ROM. Then edit the updater-script, and change all references to the internal system partition (/dev/block/mmcblk0p9) to the external system partition (e.g. /dev/block/mmcblk1p2). If any other partitions are referenced, change them as well.
Optional: insert the "bootinternal" script in /system/bin and the a script to mount the internal storage in /system/etc/init.d.
Your ROM is ready to go. Flash and be happy!
Thanks to Johnsel for helping me edit the boot image and pointing me to sendust7's work on the Atrix, who I also thank for his precedent.
CWM Zips for Wiping External Partitions
If you ever need to wipe /data, /cache, or dalvik on your external dual-boot partitions, you can use these CWM zips to do so.
Update: Here is a script to automate the conversion of a ROM from standard to external dualboot.
interesting... gonna try this later...
Nice guide! Dual boot with stock and cm9/10/AOKP would be ideal.
Confirmed?
Sent from my GT-P3113 using Tapatalk 2
scottx . said:
Nice guide! Dual boot with stock and cm9/10/AOKP would be ideal.
Click to expand...
Click to collapse
Agreed! Is it possible to dual boot stock and AOKP?
IFLATLINEI said:
Agreed! Is it possible to dual boot stock and AOKP?
Click to expand...
Click to collapse
Absolutely. If you're running stock, just follow the instructions to partition your SD card, then flash the provided AOKP package and (I assume you would) the gapps package. You should boot right into to your external AOKP installation. Then just copy your stock boot image to /sdcard/Boot/internal.img and run "bootinternal" from a Terminal Emulator or adb shell to return to stock.
BRILLIANT !!!
A few suggestions:
Possible to have a GUI to switch ROM or even better to have it at boot (through kernel).
Script to Automate the process of converting any(P31xx) ROM to dual-boot. It will take away pressure off you.
Thanks !
thanks for the tutorial.
silentvisitor said:
BRILLIANT !!!
A few suggestions:
Possible to have a GUI to switch ROM or even better to have it at boot (through kernel).
Script to Automate the process of converting any(P31xx) ROM to dual-boot. It will take away pressure off you.
Thanks !
Click to expand...
Click to collapse
The GUI may or may not happen, since I, while familiar with partitions and scripting, don't know much about Java or Android development. I'll look into it, though. Having it run at boot through the kernel is beyond my skills. The closest I could do would be an init.d script.
As for a script to automate the conversion process, that seems doable. It only involves two files (init.espresso.rc in the boot image and the updater-script), so I could see that happening. I'll try to do something with that.
This is very interesting!
But I think it is better if we can install dual-boot like CM10 and some porting of Linux desktop version, chrome OS (love it) and other
I follow this thread!
Update: I've added a script that automatically converts ROMs to external dualboot format. I advise using this script instead of my provided ROMs. Just open a terminal in the script's directory and run:
Code:
./convert.sh rom-to-convert.zip
It will automatically edit the boot image and updater script, as well as configure the dualboot scripts. Go back to the second post to download.
Dual-boot question
Sorry for offtop, but your work is very interesting for me. I have GT-P6800 (Tab 7.7) and will try your method on my device. What can i do for it? May be change numeration of partitions inside a script? And firmware counter will be ticked or not? And my current firmware in internal memory will be untoched? Thanks for your work again!
partola1 said:
Sorry for offtop, but your work is very interesting for me. I have GT-P6800 (Tab 7.7) and will try your method on my device. What can i do for it? May be change numeration of partitions inside a script? And firmware counter will be ticked or not? And my current firmware in internal memory will be untoched? Thanks for your work again!
Click to expand...
Click to collapse
I would assume our tablets are very similar, so my method probably would work as is. To be sure, extract the updater-script from your rom and send it to me, along with the boot image, and I'll check it out. Your firmware counter will not be increased, and your current firmware should not be affected.
marry me. I just asked the dual boot question like a week ago lol
Macadamia Daze said:
I would assume our tablets are very similar, so my method probably would work as is. To be sure, extract the updater-script from your rom and send it to me, along with the boot image, and I'll check it out. Your firmware counter will not be increased, and your current firmware should not be affected.
Click to expand...
Click to collapse
Hi, this is my p680 kernel & updater-script:
http://hotfile.com/dl/170647189/80fec16/P6800.ZIP.html
Please, check it!
Also, i have some questions:
as you know, only 4 primary partition allowing on sdcard. I create 1 partition primary fat32 and 4 partitions logical ext4. Is this ok?
And how can i check partitions directly on tab? Terminal emulator not understand parted command, and from recovery TWRP 2.2.0.0 terminal asking me about from which directory execute commands. I try few directories, but parted/dev/mmcblk1 command show nothing to me.
Thank you for your adwise.
partola1 said:
Hi, this is my p680 kernel & updater-script:
http://hotfile.com/dl/170647189/80fec16/P6800.ZIP.html
Please, check it!
Click to expand...
Click to collapse
I'm having problems unpacking your boot image. Run the command "mount" on your tab and give me the output. I looked in your updater-script, though, and that seems compatible.
as you know, only 4 primary partition allowing on sdcard. I create 1 partition primary fat32 and 4 partitions logical ext4. Is this ok?
Click to expand...
Click to collapse
I was able to put 5 primary partitions on my SD card. Are you using an MBR partition table or GUID partition table? You need to use GUID to have 5 primary partitions. Anyway, I don't know if it will make a difference for logical partitions. Once you can check the partitions from your tab, I'll be able to tell you if it will work.
And how can i check partitions directly on tab? Terminal emulator not understand parted command, and from recovery TWRP 2.2.0.0 terminal asking me about from which directory execute commands. I try few directories, but parted/dev/mmcblk1 command show nothing to me.
Click to expand...
Click to collapse
Use CWM instead of TWRP.
Macadamia Daze said:
I'm having problems unpacking your boot image. Run the command "mount" on your tab and give me the output. I looked in your updater-script, though, and that seems compatible.
Click to expand...
Click to collapse
Hi, this is result of mount command:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
[email protected]:/ $ 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
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/mmcblk0p9 /system ext4 ro,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p7 /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p1 /efs ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p10 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/mmcblk0p4 /mnt/.lfs j4fs rw,relatime 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
tmpfs /mnt/sdcard/extStorages tmpfs rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,size=0k,mode=755,gid=1000 0 0
/dev/block/vold/179:9 /mnt/sdcard/extStorages/SdCard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
[email protected]:/ $
Also, i get CWM instead TWRP. But CWM have not possibility entering commands at all.
If you had troubles with unpacking CM10 kernel, any way for update it to booting from sd?
Thank you.
Why duplicate the efs partition?
And what makes it need such a big cache partition?
Sent from my GT-P1000
partola1 said:
Hi, this is result of mount command:
Code:
[email protected]:/ $ export PATH=/data/local/bin:$PATH
[email protected]:/ $ 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
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/mmcblk0p9 /system ext4 ro,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p7 /cache ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p1 /efs ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p10 /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/mmcblk0p4 /mnt/.lfs j4fs rw,relatime 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
tmpfs /mnt/sdcard/extStorages tmpfs rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,size=0k,mode=755,gid=1000 0 0
/dev/block/vold/179:9 /mnt/sdcard/extStorages/SdCard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
[email protected]:/ $
Click to expand...
Click to collapse
Your essential partitions are the same, but are referenced differently. I will need to make a slight alteration to the conversion script.
Also, i get CWM instead TWRP. But CWM have not possibility entering commands at all.
Click to expand...
Click to collapse
You do it through ADB.
If you had troubles with unpacking CM10 kernel, any way for update it to booting from sd?
Click to expand...
Click to collapse
I'm looking into the boot image, but let's try something out. In the terminal emulator, run "cat /dev/block/mmcblk0p5 > /sdcard/full-boot.img" (without quotes). Then upload that file.
cdesai said:
Why duplicate the efs partition?
Click to expand...
Click to collapse
When I first ran across it, I wasn't sure what it was, so I added it for safety.
And what makes it need such a big cache partition?
Click to expand...
Click to collapse
I'm not sure. I decided to keep it close to the original cache partition size, which was 700+ MB. However, I've found in another setup that I can get by with half that. In my internal dual-boot setup, I have a 384MB cache partition.
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
I have a problem ... i'm trying to install Android MM using TWRP 3.0.2 but i can't because i can't format.
When i'm trying to format it shows this error: E:Unable to wipe '/data' -- unknown file system 'auto'
Unable to format to remove encrytion
Do i need to use another recovery?
Can someone tell me how to solve this?
I had the same problem, for some reason TWRP is unable to format encrypted partitions.
It can be solved using adb shell or using the terminal in TWRP (it's under the advanced tab).
To format the partition you have to know which device it is, to find out type this inside the terminal:
Code:
cat /etc/fstab
In my case the output is:
~ # cat /etc/fstab
/dev/block/mmcblk0p13 /system ext4 rw 0 0
/dev/block/mmcblk0p14 /cache f2fs rw 0 0
/dev/block/mmcblk0p15 /data f2fs rw 0 0
Which means that my /data is on device /dev/block/mmcblk0p15 and uses the f2fs filesystem. If you're on f2fs then you can format the partition using
Code:
mkfs.f2fs /dev/block/mmcblkXXXX
if you're on ext4 then use
Code:
make_ext4fs /dev/block/mmcblkXXXX
Where XXXX is whatever is in your fstab. After this TWRP should be able to mount /data.
It worked,thank you!
Ok, now i have another problem ... every time i'm trying to install(flash) a zip with TWRP it's rebooting again in TWRP and can't install anything ... I had this problem in the past and i solved it but i forgot how i did that .. anyone knows?
Solved: i had to format my sd card.
penn.gwyn said:
I had the same problem, for some reason TWRP is unable to format encrypted partitions.
It can be solved using adb shell or using the terminal in TWRP (it's under the advanced tab).
To format the partition you have to know which device it is, to find out type this inside the terminal:
Code:
cat /etc/fstab
In my case the output is:
~ # cat /etc/fstab
/dev/block/mmcblk0p13 /system ext4 rw 0 0
/dev/block/mmcblk0p14 /cache f2fs rw 0 0
/dev/block/mmcblk0p15 /data f2fs rw 0 0
Which means that my /data is on device /dev/block/mmcblk0p15 and uses the f2fs filesystem. If you're on f2fs then you can format the partition using
Code:
mkfs.f2fs /dev/block/mmcblkXXXX
if you're on ext4 then use
Code:
make_ext4fs /dev/block/mmcblkXXXX
Where XXXX is whatever is in your fstab. After this TWRP should be able to mount /data.
Click to expand...
Click to collapse
I did that but I am getting only this
/3rdmodem ext4 rw 0 0
/cache ext4 rw 0 0
/data f2fs rw 0 0
and so on
/dev/block/mmcblkXXXX is missing My TWRP version is 3.1.1-1-frd any help would be greatly appreciated.
penn.gwyn said:
I had the same problem, for some reason TWRP is unable to format encrypted partitions.
It can be solved using adb shell or using the terminal in TWRP (it's under the advanced tab).
To format the partition you have to know which device it is, to find out type this inside the terminal:
Code:
cat /etc/fstab
In my case the output is:
~ # cat /etc/fstab
/dev/block/mmcblk0p13 /system ext4 rw 0 0
/dev/block/mmcblk0p14 /cache f2fs rw 0 0
/dev/block/mmcblk0p15 /data f2fs rw 0 0
Which means that my /data is on device /dev/block/mmcblk0p15 and uses the f2fs filesystem. If you're on f2fs then you can format the partition using
Code:
mkfs.f2fs /dev/block/mmcblkXXXX
if you're on ext4 then use
Code:
make_ext4fs /dev/block/mmcblkXXXX
Where XXXX is whatever is in your fstab. After this TWRP should be able to mount /data.
Click to expand...
Click to collapse
I tried this but now i cant fully install roms correctly. However i did this to more than just data
Hi, I tried this, but it's telling me : "need size of filesystem"
Do you have an idea of what's going wrong ? thanks
BTW : i have : /dev/block/dm-0 /data ext rw 0 0
hi I need help. Tell me "need size of filesystem"
Please help me.
help me /sbin/e2fsck -fp /dev/block/sda18 process ended with ERROR: 8
Cannot format /data using TWRP
and
make_ext4fs /dev/block/mmcblkXXXX
tell me "need size of filesystem"
help me please
dont know how i got into this. perhaps its the twrp 3.5.2_9 issue.
my parition names are long. ../soc.0/f9824900.sdhci/by-name/userdata
there is no data partition.
any way to get out of this? i dont have anything on the phone so i just want to get back to clean start.