Related
Here is a nood friendly tutorial for fastboot flashing the new CWM Touch Recovery .
Download the zip file attached and extract it anywhere .
LE:\\ You need ENG S-OFF and a rooted phone , too.
Your phone needs to be in debugging mode and you need the lastest usb drivers instaled . ( HTC Sync )
FLASHING VIA FAST BOOT :
Step 1 : Run Start Here.bat , a comand promt window will open.
Step 2 : Type in "adb reboot bootloader" . <This works on every rom , it will reboot in fastboot mod.>
Step 3 : After the phone rebooted in fastboot , type in "fastboot flash recovery recovery-clockwork-touch-5.8.0.0-ace.img" .
Step 4 : You have your Touch Recovery flashed .
UPDATE TO LASTEST VERSION :
Step 5 : Download and install "ROM Manager" from Android Market.
Step 6 : Open ROM Manager , and select "Flash ClockworkMod Touch".
Step 7 : Confirm your phone model and in about 20 seconds a message should appear "Successfully flashed ClockworkMod Recovery!" press ok and you are done.
FLASH VIA BOOTLOADER (Without enghboot) : //Thx. nteeb
nteeb said:
For those who don't have enghboot.
The recovery is flashable from bootloader if you pack it in a PD98IMG.zip.
I tried it,this is the zip,use if you want:
PD98IMG.zip
md5: E19E4461F73AB6449760D70AE906341D
Click to expand...
Click to collapse
If you are unable to flash recovery do this and try again : //THX. CostaTX
CostaTX said:
Connect phone via usb and turn on debugging/just charging
Open up cmd (eventually as administrator) and type in "adb shell"
Find out how your system partition is named: "cat /proc/mounts | grep /system"
Mount system partition write/read. replace the X's "mount -o remount,rw -t yaffs2 /dev/block/XXXXX /system"
Use the terminal emulator to install the recovery:
su
flash_image recovery /sdcard/touch.img (or whatever the recovery image is named)
remount the system partition again as read only "mount -o remount,ro -t yaffs2 /dev/block/XXXXX /system
and you're done
Click to expand...
Click to collapse
Donate to ClockworkMod for awesome job .
A new version of recovery (5.8.1.5) is available here: http://www.clockworkmod.com/rommanager
You can also use Terminal Emulator: (I prefer to place the .img file in the root of the SD card and rename the image to something simple like touch.img so I don't have to type the long name from my phone)
su
flash_image recovery /sdcard/touch.img (or whatever the recovery image is named)
reboot recovery
Enjoy!
hello, this method does n't work for me, tried in fastboot with adb, same.... it's showing "remoot error" or something lik that
Do you have S-off? That error usually indicates you do not, and it is required for this method... Any luck using Terminal Emulator, as described two posts above?
Sent from my BNTV250 using Tapatalk
winsettr said:
You can also use Terminal Emulator: (I prefer to place the .img file in the root of the SD card and rename the image to something simple like touch.img so I don't have to type the long name from my phone)
su
flash_image recovery /sdcard/touch.img (or whatever the recovery image is named)
reboot recovery
Enjoy!
Click to expand...
Click to collapse
Hey dude. This method doesn't work for me.
I keep getting a message saying 'flash_image: not found'.
I have placed the image on the root of the sd card as well as in the original download folder. Neither location works.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Any ideas?
Greg.
Sent from my Desire HD using Tapatalk
Two thoughts: when you download the recovery image its actually named something like touch-recovery-ace-5.8.0.2.img; if you want to just type in touch.img in Terminal Emulator you need to rename the file that you downloaded. If you have already done this then you may not have busybox installed (CM and MIUI do, I don't know for sure about other ROMs). To test, from Terminal Emulator type "busybox"; if it's installed, you will get a list of available commands.
Sent from my BNTV250 using Tapatalk
works perfect, thx for the new recovery
winsettr said:
Two thoughts: when you download the recovery image its actually named something like touch-recovery-ace-5.8.0.2.img; if you want to just type in touch.img in Terminal Emulator you need to rename the file that you downloaded. If you have already done this then you may not have busybox installed (CM and MIUI do, I don't know for sure about other ROMs). To test, from Terminal Emulator type "busybox"; if it's installed, you will get a list of available commands.
Sent from my BNTV250 using Tapatalk
Click to expand...
Click to collapse
Hey dude.
I had indeed already renamed the file to touch.img.
I checked TE and I do seem to have busybox installed, I'm rocking RCMIX3D V4.
Curious.
Greg.
Sent from my Desire HD using Tapatalk
Also, I took the ***** way out and I bought the touch recovery, it's only £2.
Cheers,
Greg.
Sent from my Desire HD using Tapatalk
Supporting developers is never looked down upon, glad you are up and running!
Sent from my BNTV250 using Tapatalk
It did not work for me. i get these errors:
Code:
C:\Users\Jan>cd c:\touchrecovery
c:\TOUCHRECOVERY>fastboot flash recovery touch.img
sending 'recovery' (3554 KB)... OKAY [ 0.597s]
writing 'recovery'... FAILED (remote: not allowed)
finished. total time: 0.598s
c:\TOUCHRECOVERY>notepad
i ran cmd as admin but i still get the same error. when i try installing it via terminal emulator it also says "file not found". idea?
Do you have ENG S-off (different from just rooting)? That error usually indicates you do not, and it is required for the OP method... You might try updating Busybox (search Market for Busybox Installer) if you are sure when using Terminal Emulator that the path and filename are correct.
Sent from my BNTV250 using Tapatalk
I do have eng s-off . i was able to update the the recovery in the first place. i updated busybox and su-binaries as well but still got the same error. rebooted the phone just in case but still got the errors.
i can't say if it would have worked flashing via fastboot, now with the updated busybox. I'll give it a try when i'm back home. I believe it won't work neither. Maybe you got another idea?
edit: nothing changed using fastboot
So just to confirm, you only have this problem flashing the touch recovery, and can flash other versions of CWM just fine (using fastboot or terminal)?
Sent from my Desire HD using Tapatalk
Thanks for the guide, but I have a problem. When flashing the .img file, I get the following error:
sending 'recovery' (3554 KB)... OKAY [ 0.633s]
writing 'recovery'... FAILED (remote: not allowed)
finished. total time: 0.634s
I have S-OFF, but not ENG S-OFF. Is it possible to flash this without ENG S-OFF?
ROM Manager Premium says: "Error while downloading from server. Please make sure that you have a stable internet connection, and that your SD card is inserted and has free space!"
The internet connection and the SD card are of course all right...
Edit: I read that "Engineering HBOOT is required to flash the recovery area remotely." How can I flash the recovery on the phone (not remotely)?
winsettr said:
So just to confirm, you only have this problem flashing the touch recovery, and can flash other versions of CWM just fine (using fastboot or terminal)?
Sent from my Desire HD using Tapatalk
Click to expand...
Click to collapse
i've tested flashing a non-touch recovery right now but nothing changed. i noticed that flashing a recovery via rom manager works without any problem.
I read a while back that some users (from a G1 forum, so may not be as helpful, but it's an idea) had to mount the recovery partition r/w manually from fastboot. I'll see if I can find the link... http://www.droidforums.net/forum/dr...e-busybox-flash_image-more-app.html#post87383
That might fix your error while flashing from fastboot, but it seems the issue with terminal emulator is that it's not recognizing the flash_image command. The above link also has instructions for installing flash_image which may be the key!
I downloaded this file: recovery-clockwork-touch-5.8.1.5-ace.zip
Is it safe to install this zip (which is a recovery) in recovery?
winsettr said:
I read a while back that some users (from a G1 forum, so may not be as helpful, but it's an idea) had to mount the recovery partition r/w manually from fastboot. I'll see if I can find the link... http://www.droidforums.net/forum/dr...e-busybox-flash_image-more-app.html#post87383
That might fix your error while flashing from fastboot, but it seems the issue with terminal emulator is that it's not recognizing the flash_image command. The above link also has instructions for installing flash_image which may be the key!
Click to expand...
Click to collapse
here ist what i did with that link
Code:
C:\TOUCHRECOVERY>adb shell
# cat /proc/mounts |grep /system
cat /proc/mounts |grep /system
/dev/block/mmcblk0p25 /system ext4 rw,relatime,barrier=1,data=ordered 0 0
# mount -o remount,rw -t yaffs2 /dev/block/mmcblk0p25 /system
mount -o remount,rw -t yaffs2 /dev/block/mmcblk0p25 /system
# cat /sdcard/touch.img > /system/bin/touch.img
cat /sdcard/touch.img > /system/bin/touch.img
# chmod 755 /system/bin/touch.img
chmod 755 /system/bin/touch.img
# sync
sync
# mount -o remount,r -t yaffs2 /dev/block/mmcblk0p25
mount -o remount,r -t yaffs2 /dev/block/mmcblk0p25
mount: mounting /dev/block/mmcblk0p25 on /system failed: Invalid argument
# mount -o remount,r -t yaffs2 /dev/block/mmcblk0p25 /system
mount -o remount,r -t yaffs2 /dev/block/mmcblk0p25 /system
mount: mounting /dev/block/mmcblk0p25 on /system failed: Invalid argument
busybox was already installed so i skipped this part and started with installing the recovery right away. I don't know why i'm not able to remount the system partition as read only at the end. It looks like as if everything seems to have worked properly but the touch recovery is not showing up.
Hi,
I'm trying to mount /data with GT-5570I using recovery / updater-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?
wrong section dude
and u manually boot into recovery? i turn off my phone and i boot it myself and i cant mount/ anything.....but u must tryboot yr device to recovery at ur power menu(only some rom got this option,in my exp gb no this option)...and it will solve the cache log prob...its work for me
Sent from my GT-S5570 using XDA
Wrong section bro!! This is for dev only, post such things in general!!
Sent from my GT-S5570 using xda premium
It's nothing general, it's dev actually. I'm not talking about how to enter recovery, but about scripting and developing own recovery / custom recovery.
But thanks so far for your answers.
recovery already has mount command...try this one to mout your /data partition
Code:
mount("rfs", "EMMC", "/dev/block/stl11", "/data");
if you want to use run_program command, you can make a file contain
Code:
#!/system/bin/sh
mount -t rfs /dev/block/stl11 /data
put that file on your root folder of your zip file. to run the script you'll need to use these command on updater script
Code:
package_extract_file("<your filename>", "/tmp/<your filename>");
set_perm(0, 0, 0777, "/tmp/<your filename>");
run_program("/tmp/<your filename>");
the first method is easier...
viperbjk said:
Hi,
I'm trying to mount /data with GT-5570I using recovery / update-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?
Click to expand...
Click to collapse
Hello
you use what
update-script ?
if yesy is wrong for edify on edify is caled
updater-script and commande on it is diferant from amend script [ update-script]
viperbjk said:
Hi,
I'm trying to mount /data with GT-5570I using recovery / update-script.
However, I'm stuck with an issue, I just don't know what's happening :
running the script :
Code:
run_program("/system/xbin/busybox","mount","-t rfs","/dev/stl11","/data");
the log in /cache/recovery/last_log says :
Code:
Mount : cannot mount /dev/stl11 on /data : no such device
however, if I start adbd using
Code:
run_program("/sbin/adbd")
right in recovery, and sending
Code:
# /system/xbin/busybox mount -t rfs /dev/stl11 /data
/data mounts fine.
Now the big question :
Why isn't it possible to mount /data using recovery script, but running adbd in recovery, I am able to mount /data in recovery ?
Any ideas ?
Click to expand...
Click to collapse
If you are still using update-script then, I suggest you switch to updater-script and update-binary since, latest clockwork mod (v3 and above use these Edify scripting methods...).
I believe you are trying to mount data to copy files to or from /data/ partition on your device...
Here's a script to do so in recovery and I'm sure it's the exact thing you are looking for :
http://handyinformation.freevar.com/showthread.php?tid=12
Good luck!
try it
Code:
mount("rfs", "/dev/block/stl11", "/data");
ahmadsafar said:
try it
Code:
mount("rfs", "/dev/block/stl11", "/data");
Click to expand...
Click to collapse
This one is leading into "E:Error in /tmp/sideload/package.zip (Status 0)"
last_log says that :
MountFn, 53
MountFn : type is rfs
MountFn : rfs type
MountFn result is : /data
;(
kurotsugi said:
recovery already has mount command...try this one to mout your /data partition
Code:
mount("rfs", "EMMC", "/dev/block/stl11", "/data");
if you want to use run_program command, you can make a file contain
Code:
#!/system/bin/sh
mount -t rfs /dev/block/stl11 /data
put that file on your root folder of your zip file. to run the script you'll need to use these command on updater script
Code:
package_extract_file("<your filename>", "/tmp/<your filename>");
set_perm(0, 0, 0777, "/tmp/<your filename>");
run_program("/tmp/<your filename>");
the first method is easier...
Click to expand...
Click to collapse
The first one doesn't work with my update-binary as it's the new AOSP one only taking 3 variables instead of four.
using mount("rfs", "/dev/block/stl11", "/data") or mount("emmc","/dev/block/stl11","/data") leads to "E:Error in /tmp/sideload/package.zip (Status 0)"
Using the second one, the sh method, this leads into the same error message, "No such device".
I'm guessing that the main problem might be some driver/init adbd does for mounting ....
yagya said:
If you are still using update-script then, I suggest you switch to updater-script and update-binary since, latest clockwork mod (v3 and above use these Edify scripting methods...).
I believe you are trying to mount data to copy files to or from /data/ partition on your device...
Here's a script to do so in recovery and I'm sure it's the exact thing you are looking for :
http://handyinformation.freevar.com/showthread.php?tid=12
Good luck!
Click to expand...
Click to collapse
Yeah, I basically just try to mount /data to access files. Sorry for the typo, it's updater-script of course.
When I just try to use
run_program("/system/xbin/busybox", "mount", "/data");
it isn't accepted because of
"mount: can't read '/etc/fstab': No such file or directory"
Ok, guys ... found the solution ...
mount("rfs", "EMMC", "/dev/stl11", "/data");
is working, but only using old updater-binary. Seems the AOSP
one doesn't work ... no idea why.
Many thanks for helping me out !
there's a possibility that the AOSP one doesn't compatible with the recovery.
viperbjk said:
Yeah, I basically just try to mount /data to access files. Sorry for the typo, it's updater-script of course.
When I just try to use
run_program("/system/xbin/busybox", "mount", "/data");
it isn't accepted because of
"mount: can't read '/etc/fstab': No such file or directory"
Click to expand...
Click to collapse
Well, it's probably because you don't have busybox installed. Are you sure you are rooted and have latest busybox version installed on your system?
Also, which rom do you have now?
I'm using stock rom, and yes, busybox and root is also done in recovery.
The GT-5570i hasn't got a fstab file, so that's fine.
Everything is working fine now, it was obviously that the samsung update-bin didn't work with mobiles with broadcom chipset.
try this, it's working
http://forum.xda-developers.com/showthread.php?p=27018781
meccaandroid said:
try this, it's working
http://forum.xda-developers.com/showthread.php?p=27018781
Click to expand...
Click to collapse
No. This has to do with the binary n not amend.
The issue has been resolved, so rip thread.
Hi guys, İ just flashed the cm10 mod on stock kernel everything seems to work properly but can't install apks from sdcard. Is this a bug? Or did I do something wrong?
AlexZooL said:
Code:
mount -o remount,rw /
chmod 755 /mnt/shell
chmod 555 /storage
Decision "problem parsing package"
Drew script to automatically run, throw in the system / etc / init.d (unpacked from the archive)
set permissions to 755-rwxr-xr-x (the letter П)
If all of a sudden does not start at boot - install Script Manager, open the script in it and put SU and BOOT
Click to expand...
Click to collapse
Download this file
forum.xda-developers.com/attachment.php?attachmentid=1897898&d=1366473855
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
This recovery has been superseded by Eliminater74's TWRP.
This post and its files remain for archival purposes.
-- Old OP --
Note: I no longer own this device. To help test, join my Testing Discord (Please read the rules presented when you join.)
Note: There is a known bug with restoring backups. If you need to use the backup/restore features, please do not use Melina TWRP until rel_o3 is released, which has no eta.
The following releases are unofficial and will always be due to dirty edits.
However, it offers the following features over the official release:
Oreo Only Features:
Integrated Melina Kernel (rel_o2) into TWRP build system (rel_o2 or newer)
Oreo kernel (nougat kernel cannot mount unencrypted /data for some reason) (rel_o1 or newer)
Disabled encryption (rel_o1 or newer) (Note: LGE uses forceencryption now, and also has a script to replace your custom recovery with their own. Please flash my anti-root removal tool, which will remove rctd, forceencrypt, and the anti-custom-recovery script)
Nougat/Oreo Features:
Integrated Melina Kernel (rel_nr2) into TWRP build system (rel_t2 or newer)
Integrated uber-toolchain 6.x for kernel compilation into TWRP build system (rel_t2 or newer)
Stability and performance increases over rel3 (rel_t1 or newer)
/vendor partition support (if you have not repartitioned, which at the time of this release, 99% of you haven't, then you may get an error in TWRP regarding mounting storage. This is safe to ignore) (rel_t1 or newer)
/misc bootloop fix (rel_t1 or newer)
Date and time fix (msm8996 workaround) (mixed reports, but works for me on US997 with Stock and Fulmics ROMs, see this post for more information)
Option to wipe LG lockscreen security settings when restoring data partition (workaround for known issue where sometimes you get locked out of restored stock ROMs)
NTFS support (untested, should allow NTFS USB-OTG for restoring backups and flashing zips, read-only)
SD-Ext support (including backing up and restoring, both ext4 and F2FS supported thanks to Melina)
Purple theme, because purple is cool
Based on J0SH1X's work.
Downloads (bold is current):
Oreo
rel_o2
US997
H870
rel_o1
US997
H870
Nougat
rel_t2
US997
H870
rel_t1
US997 (old)
H870 (old)
rel3
US997 (old)
H870 (old)
rel2
US997 (old)
H870 (old)
Usage:
Unzip file and flash recovery.img
Please keep in mind I only have the US997 so help test this for H870!
Current Known issues:
Restoring backups does not work, due to tar process terminating with error 255.
You must format data when coming from a stock ROM due to LG using forceencrypt.
Fixed issues:
Disabled encryption (fixed in rel_o1)
E:Unhandled flag: 'removeable' (fixed in rel_t2)
Slow SDCard Performance (fixed in rel_t1)
MTP reliability (fixed in rel_t1)
GPL (dev info):
Read the readme on the github.
If my releases help you, please leave a thanks. If you are able, please consider a tip (check the small link in my sig).
Prompt for password to decrypt data
I installed the 3.2.1 version by flashing the img from the older 3.1.1 version.
When I rebooted to recovery, it prompted me for a password to decrypt the data. I don't remember encrypting the data and I do not know the password. I was able to tap cancel and get to the main TWRP screen.
Should I be worried about this?
DonS said:
I installed the 3.2.1 version by flashing the img from the older 3.1.1 version.
When I rebooted to recovery, it prompted me for a password to decrypt the data. I don't remember encrypting the data and I do not know the password. I was able to tap cancel and get to the main TWRP screen.
Should I be worried about this?
Click to expand...
Click to collapse
That is strange, I don't use encryption and never had that. I guess if the data was accessible after hitting cancel, I wouldn't worry about it. Which device?
I have the US997 version.
I didn't try flashing anything from TWRP, I just booted to make sure it showed the new version number. I rebooted to the system and everything is working fine.
DonS said:
I have the US997 version.
I didn't try flashing anything from TWRP, I just booted to make sure it showed the new version number. I rebooted to the system and everything is working fine.
Click to expand...
Click to collapse
Try flashing the img through fastboot as per normal rather than through TWRP, then when you reboot into recovery, regardless if you get the message or not, go to the backup menu and be sure Data has more than (0 MB) next to it on the list.
Oh, also, the old 3.1.1 (the one I didn't make) had an issue where if you used "Format Data" (with yes option) it actually created a corrupt file system, so that could be it as well. To fix that, execute the following under adb shell:
umount /dev/block/sda19
e2fsck -f /dev/block/sda19
(Select y for yes to repair if prompted)
Then reboot recovery and try again. You shouldn't lose data using these commands. However, if it does find and repair errors, it is not out of the question, but is something you'll want to address.
@zefie flashed the H870 build (flashed the img trough official TWRP), no password, data in backup is 8893MB, time is working fine, if you have other things to check just tell me.
BTW no purple theme, don't know why
Killua96 said:
@zefie flashed the H870 build (flashed the img trough official TWRP), no password, data in backup is 8893MB, time is working fine, if you have other things to check just tell me.
BTW no purple theme, don't know why
Click to expand...
Click to collapse
Probably just the header, is the slider purple?
Edit: nevermind, I know why, didn't define my theme in the h870 config. Rebuilding.
Edit 2: Fix should be up. Also updated US997 since this is Melina rel6 now (previous release used a pre-release version of rel6)
hello and thank you for this
anyway, I wanted to flash it under twrp as an image
it asks me :
"select partition to flash image"
-boot
-recovery
-system image
-modem
-persist
also is it ok to flash this with Fulmics ROM?
dave_id said:
hello and thank you for this
anyway, I wanted to flash it under twrp as an image
it asks me :
"select partition to flash image"
-boot
-recovery
-system image
-modem
-persist
also is it ok to flash this with Fulmics ROM?
Click to expand...
Click to collapse
It's a recovery, so you need to choose "recovery".
Also is fine with Fulmics, i've tested it on H870
just wanted to be sure, so THANKS!
zefie said:
Try flashing the img through fastboot as per normal rather than through TWRP, then when you reboot into recovery, regardless if you get the message or not, go to the backup menu and be sure Data has more than (0 MB) next to it on the list.
Oh, also, the old 3.1.1 (the one I didn't make) had an issue where if you used "Format Data" (with yes option) it actually created a corrupt file system, so that could be it as well. To fix that, execute the following under adb shell:
umount /dev/block/sda19
e2fsck -f /dev/block/sda19
(Select y for yes to repair if prompted)
Then reboot recovery and try again. You shouldn't lose data using these commands. However, if it does find and repair errors, it is not out of the question, but is something you'll want to address.
Click to expand...
Click to collapse
I flashed from fastboot instead of TWRP and I get the same thing. I get prompted for a password to decrypt data. I flashed the old 3.1.1 TWRP and I don't get that error. If I go into backup with TWRP 3.2.1 data shows 0 MB. With 3.1.1 it shows the actual size.
I rebooted to the system and connected a USB cable and went into a ADB shell. the first command returns an error. I thought your first command had a typo and you mean unmount instead of umount. I'll paste the error below.
C:\ADB>adb shell
lucye:/ $ umount /dev/block/sda19
umount /dev/block/sda19
umount: bad /etc/fstab: No such file or directory
1|lucye:/ $ unmount /dev/block/sda19
unmount /dev/block/sda19
/system/bin/sh: unmount: not found
127|lucye:/ $
DonS said:
I flashed from fastboot instead of TWRP and I get the same thing. I get prompted for a password to decrypt data. I flashed the old 3.1.1 TWRP and I don't get that error. If I go into backup with TWRP 3.2.1 data shows 0 MB. With 3.1.1 it shows the actual size.
I rebooted to the system and connected a USB cable and went into a ADB shell. the first command returns an error. I thought your first command had a typo and you mean unmount instead of umount. I'll paste the error below.
C:\ADB>adb shell
lucye:/ $ umount /dev/block/sda19
umount /dev/block/sda19
umount: bad /etc/fstab: No such file or directory
1|lucye:/ $ unmount /dev/block/sda19
unmount /dev/block/sda19
/system/bin/sh: unmount: not found
127|lucye:/ $
Click to expand...
Click to collapse
The error is because it's not mounted at all (since it sees 0 MB), so just skip to the second command.
zefie said:
The error is because it's not mounted at all (since it sees 0 MB), so just skip to the second command.
Click to expand...
Click to collapse
Here is what I get when running the second command:
C:\ADB>adb shell
lucye:/ $ e2fsck -f /dev/block/sda19
e2fsck -f /dev/block/sda19
/system/bin/sh: e2fsck: can't execute: Permission denied
126|lucye:/ $
I have gone back to TWRP 3.1.1 and in the backup screen it does show the proper size for the data volume.
DonS said:
Here is what I get when running the second command:
C:\ADB>adb shell
lucye:/ $ e2fsck -f /dev/block/sda19
e2fsck -f /dev/block/sda19
/system/bin/sh: e2fsck: can't execute: Permission denied
126|lucye:/ $
I have gone back to TWRP 3.1.1 and in the backup screen it does show the proper size for the data volume.
Click to expand...
Click to collapse
Run it in either TWRP, not under Android.
zefie said:
Run it in either TWRP, not under Android.
Click to expand...
Click to collapse
OK, here are the results from TWRP 3.1.1 terminal
umount /dev/block/sda19 returns an error
umount: can't umount /dev/block/sda19: invalid argument
e2fsck -f /dev/block/sda19 returns an error:
/dev/block/sda19 is in use.
e2fsck: cannot continue, aborting.
DonS said:
OK, here are the results from TWRP 3.1.1 terminal
umount /dev/block/sda19 returns an error
umount: can't umount /dev/block/sda19: invalid argument
e2fsck -f /dev/block/sda19 returns an error:
/dev/block/sda19 is in use.
e2fsck: cannot continue, aborting.
Click to expand...
Click to collapse
Invalid argument should not happen. Personally I'd make a back and reformat data. You say everything works but it's only a matter of time before the corruption catches you off guard. You could try the two commands on my TWRP, but if it's still saying invalid argument, back up and reformat. (With yes screen format option not just wipe data)
Thank you so much for your work. It is the only version which is working on mine.
@zefie is it somehow possible to convert ext4 to f2fs without loosing data?
Thanks for your strike work! [emoji4]
Gesendet von meinem LG-H870 mit Tapatalk
saenta said:
@zefie is it somehow possible to convert ext4 to f2fs without loosing data?
Thanks for your strike work! [emoji4]
Gesendet von meinem LG-H870 mit Tapatalk
Click to expand...
Click to collapse
Not conventionally. You could let TWRP back up sd-ext while ext4, and reformat it f2fs, but if you try to restore it in the TWRP GUI I think it'll format it back to the original format. That said, you could then manually extract the twrp backup files (they are just tar files, so something like tar -C /sd-ext -xf /path/to/sd-ext.ext4.win000 or whatever.) Extract them in numerical order.
If you are talking about built-in partitions like /data or /cache, don't do it, as ROMs have to be configured specifically to support f2fs, so it wouldn't work anyway.
bump for rel3
New Features:
Updated and Integrated Melina Kernel (rel7) into TWRP build system
Option to wipe LG lockscreen security settings when restoring data partition (workaround for known issue where sometimes you get locked out)