Database Develop

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

How to mount deprecated external_sd on Milaq's CM-11 KitKat rom

I'm still on 10.2 so I haven't tried this but give it a shot.
Milaq removed the mount configuration from fstab.tenderloin, init.tenderloin.rc, storagelist.xml, and recovery.fstab
if you look here on github.com/milaq/android_device_hp_tenderloin you can see the changes made if you click on "storage: prep webos-less setup"
removed from fstab.tenderloin:
-/devices/virtual/block/dm-6 auto vfats defaults voldmanaged=sdcard1:auto,nonremovable,noemulatedsd
removed from init.tenderloin.rc:
- mkdir /storage/sdcard1 0700 root root
- mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
- export SECONDARY_STORAGE /storage/sdcard1
- symlink /storage/sdcard1 /mnt/external_sd
- symlink /storage/sdcard1 /external_sd
-service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
- class late_start
- disabled
removed from storagelist.xml:
- <storage android:mountPoint="/storage/sdcard0"
- <!-- internal sdcard partition -->
- <storage android:mountPoint="/storage/sdcard1"
- android:storageDescription="@string/storage_sd_card"
- androidrimary="false"
- android:removable="false"
- android:allowMassStorage="true" />
removed from recovery.fstab:
-/devices/virtual/block/dm-6 /external_sd vfat defaults voldmanaged=sdcard:auto,nonremovable
Larry

No easy solution
The files modified are packed into the boot.img file of the ROM. Therefore there is no easy way to provide a zip to flash and overwrite/update these files after flashing a new ROM.
I had entered the following into the terminal app and was able to get read/write access to the webos media folder:
su
busybox mount /dev/mapper/store-media /data/media/legacy
You should see the .palm folder and other files in /data/media/legacy from within android.
Instead I recommend deleting all files from LOST.DIR (recycle bin) in WebOS and then using Tailor to resize the /media partition down to 400mb and add the remaining space to /data as milaq suggested. This should negate the need to access it from android.
Jim
laspero said:
I'm still on 10.2 so I haven't tried this but give it a shot.
Milaq removed the mount configuration from fstab.tenderloin, init.tenderloin.rc, storagelist.xml, and recovery.fstab
if you look here on github.com/milaq/android_device_hp_tenderloin you can see the changes made if you click on "storage: prep webos-less setup"
removed from fstab.tenderloin:
-/devices/virtual/block/dm-6 auto vfats defaults voldmanaged=sdcard1:auto,nonremovable,noemulatedsd
removed from init.tenderloin.rc:
- mkdir /storage/sdcard1 0700 root root
- mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
- export SECONDARY_STORAGE /storage/sdcard1
- symlink /storage/sdcard1 /mnt/external_sd
- symlink /storage/sdcard1 /external_sd
-service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
- class late_start
- disabled
removed from storagelist.xml:
- <storage android:mountPoint="/storage/sdcard0"
- <!-- internal sdcard partition -->
- <storage android:mountPoint="/storage/sdcard1"
- android:storageDescription="@string/storage_sd_card"
- androidrimary="false"
- android:removable="false"
- android:allowMassStorage="true" />
removed from recovery.fstab:
-/devices/virtual/block/dm-6 /external_sd vfat defaults voldmanaged=sdcard:auto,nonremovable
Larry
Click to expand...
Click to collapse

zoser42 said:
The files modified are packed into the boot.img file of the ROM. Therefore there is no easy way to provide a zip to flash and overwrite/update these files after flashing a new ROM.
I had entered the following into the terminal app and was able to get read/write access to the webos media folder:
su
busybox mount /dev/mapper/store-media /data/media/legacy
You should see the .palm folder and other files in /data/media/legacy from within android.
Instead I recommend deleting all files from LOST.DIR (recycle bin) in WebOS and then using Tailor to resize the /media partition down to 400mb and add the remaining space to /data as milaq suggested. This should negate the need to access it from android.
Jim
Click to expand...
Click to collapse
Excellent Job. You are right, I see no reason do continue using this partition. I was just wondering how it could be done.
could also use the native command
mount -t vfat /dev/mapper/store-media /data/media/legacy

laspero said:
Excellent Job. You are right, I see no reason do continue using this partition. I was just wondering how it could be done.
could also use the native command
mount -t vfat /dev/mapper/store-media /data/media/legacy
Click to expand...
Click to collapse
Thanks for the comments and creating the thread. I suggested creating a thread with someone else on milaq's thread since I thought it was off topic. I was using the native mount syntax early in my efforts but it was the last two parameters that were the problem.
Perhaps someone might try copying the boot.img from and earlier rom into a current rom but I have no idea if it is mostly the same or different every build. I wasn't willing to risk it but someone else may weigh in on that one. I think the changes should be in the ramcache part of boot.img.
I'm not saying it's impossible in a flashable zip but would demand a lot of time to a solution I have no intention of using.
---------- Post added at 04:50 PM ---------- Previous post was at 04:27 PM ----------
zoser42 said:
Thanks for the comments and creating the thread. I suggested creating a thread with someone else on milaq's thread since I thought it was off topic. I was using the native mount syntax early in my efforts but it was the last two parameters that were the problem.
Perhaps someone might try copying the boot.img from and earlier rom into a current rom but I have no idea if it is mostly the same or different every build. I wasn't willing to risk it but someone else may weigh in on that one. I think the changes should be in the ramcache part of boot.img.
I'm not saying it's impossible in a flashable zip but would demand a lot of time to a solution I have no intention of using.
Click to expand...
Click to collapse
It occurred to me that a "mini" build could be created that only changed the appropriate files but it would have to be kept up to date and runs counter to what milaq is trying to accomplish. I saw that some apps were even storing their data in the sdcard1(webos) folder so it was confusing android as it was. Also, I meant ramdisk and not ramcache in my previous post. My bad.
btw I branched miliq's build code and got to step 9 of 10 of cm's build instructions before running into trouble, just for the knowledge of what goes into it.

[Q] Loop in bootanimation after update to CROMi-X 7.0.2

Hi to everyone.
I was updating my tab to the latest version of the ROM of sbdags.
Everything was fine until i reboot the tab to use it for the first time: loop in the boot animation and never come out from it.
I came from the previous version of the rom, the Cromi-x 6.1 with 10.26.1.18 bootloader.
The process i use to update was this:
1) wipe of data/factory reset, wipe with format /boot, wipe with format /system
2) Install the CWM recovery 6.0.5.0 and update the bootloader to 11.4.1.17 by flashing they with the file that you can find in the rom page.
3) repeat point 1
4) install the rom by flashing it from an SD. Complete the Aroma installer and answer to every option that it ask to me.
5) reboot the system and stuck in the bootanimation
I use the WW format cause i'm italian and i check the md5
What's wrong? I can go to recovery everytime i need and i have a backup just in case i need it.
Sdbags, i really want to offer you a beer for your work. I think i will do it in every case, but yes, kitkat on my tab would be great :victory:
Sorry for bad english. For every question, i'm here. Thanks a lot.
M.

aMachi said:
Hi to everyone.
I was updating my tab to the latest version of the ROM of sbdags.
Everything was fine until i reboot the tab to use it for the first time: loop in the boot animation and never come out from it.
I came from the previous version of the rom, the Cromi-x 6.1 with 10.26.1.18 bootloader.
The process i use to update was this:
1) wipe of data/factory reset, wipe with format /boot, wipe with format /system
2) Install the CWM recovery 6.0.5.0 and update the bootloader to 11.4.1.17 by flashing they with the file that you can find in the rom page.
3) repeat point 1
4) install the rom by flashing it from an SD. Complete the Aroma installer and answer to every option that it ask to me.
5) reboot the system and stuck in the bootanimation
I use the WW format cause i'm italian and i check the md5
What's wrong? I can go to recovery everytime i need and i have a backup just in case i need it.
Sdbags, i really want to offer you a beer for your work. I think i will do it in every case, but yes, kitkat on my tab would be great :victory:
Sorry for bad english. For every question, i'm here. Thanks a lot.
M.
Click to expand...
Click to collapse
Don't do step 3. Try it again please.
Try the default options first.

sbdags said:
Don't do step 3. Try it again please.
Try the default options first.
Click to expand...
Click to collapse
If default option are those who are pre-selected on the aroma installer i've already try it.
Also i try to do it without point 3. Nothing
Here a log of the installation of the rom
AROMA INSTALLER version 2.56
(c) 2012 by amarullz xda-developers
ROM Name : CROMi-Xenogenesis KitKat
ROM Version : 7.0.2 DEODEX
ROM Author : sbdags
Device : Asus Transformer TF701T
Start at : Mon Aug 25 20:30:02 2014
Thank you for installing CROMi-Xenogenesis KitKat 4.4.2!
Sit back and relax...
-----------------------------------------------------
This will take a few minutes!
Preparing File System...
about to run program [/sbin/umount] with 3 args
umount: can't umount /system: Invalid argument
run_program: child exited with status 1
about to run program [/sbin/umount] with 3 args
Formatting System....
Creating filesystem with parameters:
Size: 2147483648
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 8192
Label:
Blocks: 524288
Block groups: 16
Reserved block group size: 127
Created filesystem with 11/131072 inodes and 17193/524288 blocks
Tuning System....
about to run program [/tmp/tune2fs.ext4] with 6 args
tune2fs 1.41.12 (17-May-2010)
Tuning Data - Journaling Enabled.....
about to run program [/tmp/tune2fs.ext4] with 6 args
tune2fs 1.41.12 (17-May-2010)
Wiping Cache.....
Installing Core System.....
Installing Options...
Region Specific Files
- TF701 WW Build
Kernel Preparation
- sbdag's 11.4.1.17 Stock Modded Kernel
package_extract_file: no extras/kernel/sbmodded/701sb3.img in package
DPI Preparation
- 320 DPI
Resolution Preparation
- 2560x1600 res
Boot Animation
- Google Android-L
Launcher
- Asus Stock Launcher
Asus Apps 1
- Asus Email
- Asus Desk Clock & Widget
- Asus Weather & Time Widget
- Asus Splendid
- Asus Calculator
- Asus MyDictionary
- Asus Studio
Asus Apps 2
Google Apps 1
- Google Calendar
- Google Now and Voice Search
- Google Music
- News and Weather Genie
- YouTube
- Maps
- Hangouts
Google Apps 2
- Google Chrome
- Google Drive Docs
Misc Apps
- ES File Explorer
- AdAway installed
- Keyboard Manager
- Terminal Emulator
- Polaris Office
Installing CROMi-X System Tweaks.....
about to run program [/tmp/cromix-build-prop.sh] with 1 args
Tweaks and Scripts
- Browser2RAM enabled
- Ad Blocker enabled
- Zip Align Script installed
- Keyboard Dock Remapping installed
Building symlinks.....
Setting permissions.....
Installing BusyBox.....
about to run program [/system/xbin/busybox] with 4 args
Setting ROOT.....
DRM Options
- Google Video & Hulu+ DRM
Installing build.prop
about to run program [/sbin/sh] with 2 args
about to run program [/sbin/sh] with 2 args
Finalising ROM
about to run program [/sbin/umount] with 3 args
---------------------------------------
All Done!
Don't forget to follow @sbdags on Twitter
If you like it please donate to [email protected] on paypal
Enjoy CROMi-X!
script succeeded: result was [Enjoy CROMi-X!]
Installer Sucessfull (Status 0)
I don't know if this can be helpful, but if i restore the backup of the previous version of the rom everything work fine. I'm reading the discussion of the guy with the partition problem and i was wondering if maybe the problem was the same, but i don't think it.
Another time, sorry for bad english and thanks for all your work sdbags.
M.

That log is fine - everything is installed.
Read out the bootloader version from the bootloader screen to double check please.
Also you are rebooting after installing the bootloader and cwm package aren't you?
aMachi said:
If default option are those who are pre-selected on the aroma installer i've already try it.
Also i try to do it without point 3. Nothing
Here a log of the installation of the rom
AROMA INSTALLER version 2.56
(c) 2012 by amarullz xda-developers
ROM Name : CROMi-Xenogenesis KitKat
ROM Version : 7.0.2 DEODEX
ROM Author : sbdags
Device : Asus Transformer TF701T
Start at : Mon Aug 25 20:30:02 2014
Thank you for installing CROMi-Xenogenesis KitKat 4.4.2!
Sit back and relax...
-----------------------------------------------------
This will take a few minutes!
Preparing File System...
about to run program [/sbin/umount] with 3 args
umount: can't umount /system: Invalid argument
run_program: child exited with status 1
about to run program [/sbin/umount] with 3 args
Formatting System....
Creating filesystem with parameters:
Size: 2147483648
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 8192
Label:
Blocks: 524288
Block groups: 16
Reserved block group size: 127
Created filesystem with 11/131072 inodes and 17193/524288 blocks
Tuning System....
about to run program [/tmp/tune2fs.ext4] with 6 args
tune2fs 1.41.12 (17-May-2010)
Tuning Data - Journaling Enabled.....
about to run program [/tmp/tune2fs.ext4] with 6 args
tune2fs 1.41.12 (17-May-2010)
Wiping Cache.....
Installing Core System.....
Installing Options...
Region Specific Files
- TF701 WW Build
Kernel Preparation
- sbdag's 11.4.1.17 Stock Modded Kernel
package_extract_file: no extras/kernel/sbmodded/701sb3.img in package
DPI Preparation
- 320 DPI
Resolution Preparation
- 2560x1600 res
Boot Animation
- Google Android-L
Launcher
- Asus Stock Launcher
Asus Apps 1
- Asus Email
- Asus Desk Clock & Widget
- Asus Weather & Time Widget
- Asus Splendid
- Asus Calculator
- Asus MyDictionary
- Asus Studio
Asus Apps 2
Google Apps 1
- Google Calendar
- Google Now and Voice Search
- Google Music
- News and Weather Genie
- YouTube
- Maps
- Hangouts
Google Apps 2
- Google Chrome
- Google Drive Docs
Misc Apps
- ES File Explorer
- AdAway installed
- Keyboard Manager
- Terminal Emulator
- Polaris Office
Installing CROMi-X System Tweaks.....
about to run program [/tmp/cromix-build-prop.sh] with 1 args
Tweaks and Scripts
- Browser2RAM enabled
- Ad Blocker enabled
- Zip Align Script installed
- Keyboard Dock Remapping installed
Building symlinks.....
Setting permissions.....
Installing BusyBox.....
about to run program [/system/xbin/busybox] with 4 args
Setting ROOT.....
DRM Options
- Google Video & Hulu+ DRM
Installing build.prop
about to run program [/sbin/sh] with 2 args
about to run program [/sbin/sh] with 2 args
Finalising ROM
about to run program [/sbin/umount] with 3 args
---------------------------------------
All Done!
Don't forget to follow @sbdags on Twitter
If you like it please donate to [email protected] on paypal
Enjoy CROMi-X!
script succeeded: result was [Enjoy CROMi-X!]
Installer Sucessfull (Status 0)
I don't know if this can be helpful, but if i restore the backup of the previous version of the rom everything work fine. I'm reading the discussion of the guy with the partition problem and i was wondering if maybe the problem was the same, but i don't think it.
Another time, sorry for bad english and thanks for all your work sdbags.
M.
Click to expand...
Click to collapse

sbdags said:
That log is fine - everything is installed.
Read out the bootloader version from the bootloader screen to double check please.
Also you are rebooting after installing the bootloader and cwm package aren't you?
Click to expand...
Click to collapse
When i install cwm and bootloader package i reboot from cwm but i stuck in boot animation. The same that happen when i try to reboot after install the rom.
In bootloader screen i read
Android macallan-user BL released by WW_epad-11.4.1.17-20140711

aMachi said:
When i install cwm and bootloader package i reboot from cwm but i stuck in boot animation. The same that happen when i try to reboot after install the rom.
In bootloader screen i read
Android macallan-user BL released by WW_epad-11.4.1.17-20140711
Click to expand...
Click to collapse
Right and then you boot back to CWM, do a full wipe (you may need to wipe your internal sdcard so back it up first) and then flash the rom. After that it should boot fine.
If not please search xda for how to get a logcat and post one of it bootlooping please.

sbdags said:
Right and then you boot back to CWM, do a full wipe (you may need to wipe your internal sdcard so back it up first) and then flash the rom. After that it should boot fine.
If not please search xda for how to get a logcat and post one of it bootlooping please.
Click to expand...
Click to collapse
I try the first thing that you say but nothing, still loop in bootanimation.
I'll do a logcat through adb in the afternoon. Now i had some problem cause i can't mount usb storage through cwm for some reason. Late i'll find drivers or what's missing.
Maybe can help: when i reboot frequently cwm ask me if i want to fix root. It's normal?
Thanks you for your help.

aMachi said:
I try the first thing that you say but nothing, still loop in bootanimation.
I'll do a logcat through adb in the afternoon. Now i had some problem cause i can't mount usb storage through cwm for some reason. Late i'll find drivers or what's missing.
Maybe can help: when i reboot frequently cwm ask me if i want to fix root. It's normal?
Thanks you for your help.
Click to expand...
Click to collapse
That message is normal. Just a bug in CWM.
We need to find why you are bootlooping.

sbdags said:
That message is normal. Just a bug in CWM.
We need to find why you are bootlooping.
Click to expand...
Click to collapse
Ok, logcat is here.
Hope it can help.

aMachi said:
Ok, logcat is here.
Hope it can help.
Click to expand...
Click to collapse
OK You got some serious problems there. It would appear that your internal sdcard doesn't mount:
Code:
D/Vold ( 359): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 359): *********** Success!! "ro.epad.mount_point.sdcard=/mnt/media_rw/sdcard"
D/Vold ( 359): Volume usbdrive state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 359): *********** Success!! "ro.epad.mount_point.usbdrive=/mnt/media_rw/usbdrive"
I/Vold ( 359): opening the sysfs of TF701
E/Vold ( 359): lookupVolume usbdisk1 failed!
E/Vold ( 359): lookupVolume usbdisk2 failed!
E/Vold ( 359): lookupVolume sdreader failed!
D/Vold ( 359): checkUsbdisk sucess.
D/DirectVolume( 359): i:0 minor:48
D/Vold ( 359): Volume sdcard state changing 0 (No-Media) -> 2 (Pending)
D/DirectVolume( 359): i:1 minor:49
D/Vold ( 359): Volume sdcard state changing 2 (Pending) -> 1 (Idle-Unmounted)
@lj50036, @_that any suggestions for this one?
@aMachi - what is the SKU of your device? And you can restore a nandroid back to 4.3 and it works fine?

sbdags said:
OK You got some serious problems there. It would appear that your internal sdcard doesn't mount:
Code:
D/Vold ( 359): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 359): *********** Success!! "ro.epad.mount_point.sdcard=/mnt/media_rw/sdcard"
D/Vold ( 359): Volume usbdrive state changing -1 (Initializing) -> 0 (No-Media)
D/Vold ( 359): *********** Success!! "ro.epad.mount_point.usbdrive=/mnt/media_rw/usbdrive"
I/Vold ( 359): opening the sysfs of TF701
E/Vold ( 359): lookupVolume usbdisk1 failed!
E/Vold ( 359): lookupVolume usbdisk2 failed!
E/Vold ( 359): lookupVolume sdreader failed!
D/Vold ( 359): checkUsbdisk sucess.
D/DirectVolume( 359): i:0 minor:48
D/Vold ( 359): Volume sdcard state changing 0 (No-Media) -> 2 (Pending)
D/DirectVolume( 359): i:1 minor:49
D/Vold ( 359): Volume sdcard state changing 2 (Pending) -> 1 (Idle-Unmounted)
@lj50036, @_that any suggestions for this one?
@aMachi - what is the SKU of your device? And you can restore a nandroid back to 4.3 and it works fine?
Click to expand...
Click to collapse
i've some problem to find the SKU code. I search on the box of the tablet but there are too many codes and i don't know what's the right. Can you give me an exemple of it?
Yes, i can restore to 4.3. In this right moment i'm writing with the tab with cromix 6. Everything seems to work fine.
In case like this you really know how much important is to do a backup..

aMachi said:
i've some problem to find the SKU code. I search on the box of the tablet but there are too many codes and i don't know what's the right. Can you give me an exemple of it?
Yes, i can restore to 4.3. In this right moment i'm writing with the tab with cromix 6. Everything seems to work fine.
In case like this you really know how much important is to do a backup..
Click to expand...
Click to collapse
SKU is just your country code - so if you have changed it it could be causing issues with the clean install.
US, WW, TW, CN, JP are the only 5 I know of.
So if you changed the bootloader from US to WW I heard another user reporting some issues.
But in your case I am at a loss as to how you can boot 4.3 but not 4.4.2 as you are apparently on a 4.4.2 compatible bootloader and recovery .......

sbdags said:
SKU is just your country code - so if you have changed it it could be causing issues with the clean install.
US, WW, TW, CN, JP are the only 5 I know of.
So if you changed the bootloader from US to WW I heard another user reporting some issues.
But in your case I am at a loss as to how you can boot 4.3 but not 4.4.2 as you are apparently on a 4.4.2 compatible bootloader and recovery .......
Click to expand...
Click to collapse
Ah, right, i understand. I am WW, and i use it in every installation that i've done on my eee pad, from the rooting process and the unlocking of bootloader to the change of the rom.
Now that i am on the previous version of your rom those are infos of kernel, firmware, ecc.
Android Version 4.3
Kernel Version 3.4.57-g47dbe4d [email protected]#1
Tue Dec 17 23.26.15 CST 2013
Build Number TF701T_CROMi-Xenogenesis-6.1-WW_DEODEX-ORIGINAL-10.26.1.18 020115_201310210002
In ROM Manager i can see that my Recovery still is the 6.0.5.0 version.
In bootloader i can see that it is "WW_epad-11.4.1.17-20140711"
Hope that this might be helpful and hope that i don't write anything of unsafe.
M.

aMachi said:
Ah, right, i understand. I am WW, and i use it in every installation that i've done on my eee pad, from the rooting process and the unlocking of bootloader to the change of the rom.
Now that i am on the previous version of your rom those are infos of kernel, firmware, ecc.
Android Version 4.3
Kernel Version 3.4.57-g47dbe4d [email protected]#1
Tue Dec 17 23.26.15 CST 2013
Build Number TF701T_CROMi-Xenogenesis-6.1-WW_DEODEX-ORIGINAL-10.26.1.18 020115_201310210002
In ROM Manager i can see that my Recovery still is the 6.0.5.0 version.
In bootloader i can see that it is "WW_epad-11.4.1.17-20140711"
Hope that this might be helpful and hope that i don't write anything of unsafe.
M.
Click to expand...
Click to collapse
NO that is expected but hat is not expected is why you can't boot 4.4.2. Let's wait for _that and lj50036 to cast their expert eyes over your issues.

sbdags said:
@lj50036, @_that any suggestions for this one?
Click to expand...
Click to collapse
This seems to be the core of the problem:
Code:
E/dalvikvm(13002): JNI posting fatal error: Native registration unable to find class 'com/android/internal/os/RuntimeInit'; aborting...
Check that the framework is correctly installed and the BOOTCLASSPATH is set correctly:
Code:
adb shell echo $BOOTCLASSPATH > bootclasspath.txt
adb shell ls -l /system/framework > framework.txt

_that said:
This seems to be the core of the problem:
Code:
E/dalvikvm(13002): JNI posting fatal error: Native registration unable to find class 'com/android/internal/os/RuntimeInit'; aborting...
Check that the framework is correctly installed and the BOOTCLASSPATH is set correctly:
Code:
adb shell echo $BOOTCLASSPATH > bootclasspath.txt
adb shell ls -l /system/framework > framework.txt
Click to expand...
Click to collapse
Ok, so maybe now i need some help.
I run adb in my pc then i type adb shell to run the remote shell interactively.
Then what i need to type?
Anyway if i type "ls -l /system/framework > framework.txt" the response is "No such file or directory"
Sorry for my n00b questions. Really hope to learn something here, and give a chance to reward everyone for the help.

aMachi said:
Ok, so maybe now i need some help.
I run adb in my pc then i type adb shell to run the remote shell interactively.
Then what i need to type?
Anyway if i type "ls -l /system/framework > framework.txt" the response is "No such file or directory"
Sorry for my n00b questions. Really hope to learn something here, and give a chance to reward everyone for the help.
Click to expand...
Click to collapse
The commands were supposed to be typed as is on your computer. However I think I missed to quote the "echo $BOOTCLASSPATH" - I want the bootclasspath of your device, not of your PC.
Anyway, if you type "adb shell" first and then "ls -l /system/framework" and you get back "No such file or directory" that's strange...

_that said:
The commands were supposed to be typed as is on your computer. However I think I missed to quote the "echo $BOOTCLASSPATH" - I want the bootclasspath of your device, not of your PC.
Anyway, if you type "adb shell" first and then "ls -l /system/framework" and you get back "No such file or directory" that's strange...
Click to expand...
Click to collapse
Ok so tomorrow i'll give you the result of this test. I hope that i learn how to right use this command.
Any other thing that i can do?

aMachi said:
Ok so tomorrow i'll give you the result of this test. I hope that i learn how to right use this command.
Any other thing that i can do?
Click to expand...
Click to collapse
Post screenshots of your cmd window so that they can see the actual input/output

berndblb said:
Post screenshots of your cmd window so that they can see the actual input/output
Click to expand...
Click to collapse
No need for a graphical screenshot - you can copy the text from the console window.

[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:

[SOLVED] *******PLEASE HELP ME!!!!!!!!!! - seems like i've got a permanent soft brick

Hello everybody im wondering if someone can help me
im trying to reinstall a rom to my HTC One m7
But everytime i try to use fastboot or RUU exe to unbrick it i get stuck at the signature verification part.
my phone info is as follows (bootloader):
*** TAMPERED ***
*** RELOCKED ***
*** Security Warning ***
M7_UL PVT SHIP S-ON RH
HBOOT-1.44.0000
RADIO-4A.13.3231.27
OpenDSP-v26.120.274.0202
eMMC-boot
Mar 7 2013,23:09:00-1
IF I TYPE IN FASTBOOT: fastboot getver version-main I receive: 1.28.61.7
My CID: ORANG001
TWRP recovery version: 2.8.7.0
I am able to unlock and relock at my own will using fastboot to relock and using HTC-Dev toekn .bin file to unlock via fastboot.
I am able install both TWRP and CWM recoveries... but when I enter recovery with (unlocked device) neither can mount the sdcard so i can copy a rom to the phone to install.
I am abdle to use adb to copy files to my internal storage but am not able to use the abd sideload as the TWRP recovery cannot seem to mount the sdcar or system or data
The phone is completely wiped and I dont know what else to do. I understand that if i was able to gain S-OFF then the signature verification would pass but is there a way to do this when I cant do anything but get into my bootloader and recovery?
Maybe its down to the RUU exe and zip files im using i dont know??? but it seems very hard to find a link to one that is for my phone.
any help would be very appreciated and links also please
HELP ME
SOLUTION
Quote:
Originally Posted by nkk71
Hey @basv81, I'm leaving this for you cause I'm probably not going to be online tonight:
I don't think you will be able to do this. TWRP and CWM, although they say "format", what it actually does is only wipe the contents of the partition. Since TWRP is unable to mount it, means it's really corrupt. not only /data/media (internal storage), but the whole /data partition.
If you read through this post: http://android-revolution-hd.blogspo...a-htc-one.html
You can clearly see it pretty much applies to your case: "E:Unable to mount '/data'" and e2fsck reporting error.
I would follow the repair instructions from that article, basically (while in recovery):
download this: http://goo.gl/pmZ9Mt, then
adb push mkfs.ext4 /tmp
adb shell
chmod 777 /tmp/mkfs.ext4
/tmp/mkfs.ext4 -b 4096 -O ^huge_file,^dir_nlink,^ext_attr,^resize_inode,^ext ra_isize -m 0 /dev/block/mmcblk0p37
that last command is quite long and not the easiest , so I recommend you type is in very slowly, and be particularly careful with extra or missing spaces, check the link above to make sure it's correct. (it didn't work for the other guy I mentioned cause I told him to copy/paste it, but that introduced an extra space which we both overlooked; so we had to solve it using e2fsck, which in your case is not able to fix the filesystem ).
Once formatting is complete, you need to recreate the /data/media folder, so while still in the adb shell:
mount /data
mkdir -p /data/media/0
then you can use adb push or sideload to get your phone working.
Good luck, and post back with hopefully positive results
Checked if my device was connected properly:
Code:
C:\Repair_HTC_One_m7ul>adb devices
adb server is out of date. killing...
* daemon started successfully *
List of devices attached
H*********** recovery
As that was the case I continued. First I read the topic nkk71 suggested: http://android-revolution-hd.blogspo...a-htc-one.html
First of all I pushed the downloaded mkfs.ext4 file to my device:
Code:
C:\Repair_HTC_One_m7ul>adb push mkfs.ext4 /tmp
3255 KB/s (3537143 bytes in 1.061s)
After that, I changed the file's permissions and executed it with the long command:
Code:
C:\Repair_HTC_One_m7ul>adb shell
~ # ←[6nchmod 777 /tmp/mkfs.ext4
chmod 777 /tmp/mkfs.ext4
~ # ←[6n/tmp/mkfs.ext4 -b 4096 -O ^huge_file,^dir_nlink,^ext_attr,^resize_inode,^extra_isize -m 0 /dev/block/mmcblk0p37
/tmp/mkfs.ext4 -b 4096 -O ^huge_file,^dir_nlink,^ext_attr,^resize_inode,^extra_isize -m 0 /dev/block/mmcblk0p37
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1703936 inodes, 6815744 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
208 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
I mounted the /data folder and made directory /data/media/0. After that I quitted the shell.
Code:
~ # ←[6nmount /data
mount /data
~ # ←[6nmkdir -p /data/media/0
mkdir -p /data/media/0
~ # ←[6nexit
exit
I pushed the latest stable Cyanogenmod ROM to my device, including the corresponding Google Apps (so my android keyboard keeps working when I install it):
Code:
C:\Repair_HTC_One_m7ul>adb push cm-10.1.3-m7ul.zip /data/media/0
3284 KB/s (187979506 bytes in 55.886s)
C:\Repair_HTC_One_m7ul>adb push gapps-jb-20130812-signed.zip /data/media/0
3516 KB/s (100751136 bytes in 27.981s)
In twrp:
install
navigated to CM10.1.3 zip-file
installed CM10.1.3 zip-file
Rebooted to bootloader, so I can flash the boot.img again (AFTER installing CM)
Code:
C:\Repair_HTC_One_m7ul>fastboot flash boot boot.img
sending 'boot' (5558 KB)...
OKAY [ 0.993s]
writing 'boot'...
OKAY [ 0.514s]
finished. total time: 1.510s
Rebooted system to see if CM10.1.3 would start for first run. It did, YAY, so I rebooted to recovery again to install Google apps.
Entered recovery (twrp):
install
navigated to gapps zip-file
installed gapps zip-file
wiped cache/dalvik
Many, many thanks to @nkk71 for all support you've given. Without you I'd still be hopelessy stuck!

i rule123 said:
Many, many thanks to @nkk71 for all support you've given. Without you I'd still be hopelessy stuck!
Click to expand...
Click to collapse
glad you got it sorted, for future reference or anybody else that happens to check here, the "manual" formatting method is not really necessary, you can do it in TWRP
TWRP -> Wipe -> Format data -> type 'yes' (this will do a real format of your entire data partition)
I've mentioned it in the FAQ Sticky in particular on page 3
But happy everything worked out for you :good::good:

The links are dead. Could someone please update? I'm having the same issue and would like to use this solution.