Now I know I'm rooted. I unlocked my bootloader, flashed CWM 3.0 and installed the Superuser (ef) and even installed Rom manager and gave it permission. But for some reason almost every other rooted app I download and try to use it says that my phone isn't rooted?? I'm using a Nexus S. Anybody had similiar issues and resolved it? Thanks for all responses.
Yes the answer has been posted. Go into the recovery from rom manager or by volume and power. Go to mounts and storage and mount / system. You are see it unmount now so mount the system.
You may also need to zap the system with chmod.
You do this by going into Clockwork Recovery's Mounts & Storage. Mount /system. Then in ADB from your computer type in:
1) adb shell
2) cd /system/bin
3) chmod 6775 su
exit and reboot.
I have been trying to flash this rom to my KF.. however when trying to CMD mkdir recovery i get the response mkdir failed for recovery, file exists. any solutions? im mounted and device shows on adb.
adb shell
su
cd cache
mkdir recovery
mdkir failed recovery, file exist
Any ideas?
did you look to see if the directory recovery actually exists? If so, the error makes sense.
Honestly this is my first rom flashing.. and dont understand where to find that.. i followed the instructions from here -CM7 For Kindle Fire With Audio & In-Browser Video [Download & Install]- on addictive tips
but for some reason i cannot get past that.. i didnt see any post about the same problem.. so not sure how to get around it >.< heh the only ive searched my sd card and havent found any recovery files
wtbhacks said:
Honestly this is my first rom flashing.. and dont understand where to find that..
Click to expand...
Click to collapse
Not knowing could end up bricking your device.
Using ls -l will show you what is in the cache directory... you most likely already have a recovery directory which is why mkdir doesn't work, it tells you why.
Example:
Code:
$ [B][COLOR="Red"]adb shell[/COLOR][/B]
$ [B][COLOR="Red"]su[/COLOR][/B]
su
# [B][COLOR="Red"]cd cache[/COLOR][/B]
cd cache
# [B][COLOR="Red"]ls -l[/COLOR][/B]
ls -l
drwxrwx--- root cache 1969-12-31 17:00 lost+found
drwxrwx--- system cache 2011-11-29 18:06 recovery
#
ok so i did this
ls
lost+found
recovery
thats what showed up.. so being that.. how to i rid the directory so i can flash the rom then?
ls -1 showed no such file or directory
J noticed some omissions in the instructions, like going in to root after adb shell, among some others. Make sure you are in root (# instead of $) as soon as you get into adb shell.
In all honesty, not trying to be a ****, I would suggest you wait until there is a working.custom.recovery before getting in to this. Although not difficult, you can brick your device with one bad command, ans not having a fool proof recovery is not going to make recoveery very easy.....
Sent from my Kindle Fire using Tapatalk
ughhhh amazons lay out is a jokeeeee tho haha and i was in root... su puts you in # right after adb shell.. but yeah i might have too... i cant figure this out for some reason >.< ty tho
Hello, i have a problem with my TF101 (B70 if i'm right), ADB only work when i'm in recovery mode.
I lost root i don't know how and tried to regain it, but every rooting tools failled, i then discovered that commands wasn't working (even ls), but they do work in recovery mode (from /sbin).
When i try to flash a .zip from CWM , it seems that changes suposed to be applied to /system/bin aren't applied (SuperUser/SuperSU never find /system/bin/SU) but /system/bin/app correctly get updated.
I'd prefer to not wipe the device's data and repair it from it's current state if possible.
TF101's current state : Stock .27 guevor kernel 717, CWM non touch recovery
From recovery
ls -l /sbin
http://pastebin.com/tmyZagUk
ls -l /system/bin
http://pastebin.com/6tsPaPF0
ls -l /system/xbin
http://pastebin.com/D3jW5Sy3
If you need more info please tell
Bounty : I'll send Russian chocolat and candies to the one that will find how to fix this !
Magissia said:
Hello, i have a problem with my TF101 (B70 if i'm right), ADB only work when i'm in recovery mode.
I lost root i don't know how and tried to regain it, but every rooting tools failled, i then discovered that commands wasn't working (even ls), but they do work in recovery mode (from /sbin).
When i try to flash a .zip from CWM , it seems that changes suposed to be applied to /system/bin aren't applied (SuperUser/SuperSU never find /system/bin/SU) but /system/bin/app correctly get updated.
I'd prefer to not wipe the device's data and repair it from it's current state if possible.
TF101's current state : Stock .27 guevor kernel 717, CWM non touch recovery
From recovery
ls -l /sbin
http://pastebin.com/tmyZagUk
ls -l /system/bin
http://pastebin.com/6tsPaPF0
ls -l /system/xbin
http://pastebin.com/D3jW5Sy3
If you need more info please tell
Click to expand...
Click to collapse
Go to the play store, download & install Goomanager, install TWRP. CWM seems to have a few issues with teh TF101's.
Hello, i have a CWM flashable TWRP recovery, i even tested it, but wasn't able to work with it, it was very slow and didn't found files i was looking for, i will regive it a try.
Edit : I have the exact same problem when flashing SuperSU from TeamWin recovery, everything act as i don't have SU, i can grant rights to anything i want it will still act as i don't have root, and SuperSU is unable to update it own binary at startup
Magissia said:
Hello, i have a problem with my TF101 (B70 if i'm right), ADB only work when i'm in recovery mode.
I lost root i don't know how and tried to regain it, but every rooting tools failled, i then discovered that commands wasn't working (even ls), but they do work in recovery mode (from /sbin).
When i try to flash a .zip from CWM , it seems that changes suposed to be applied to /system/bin aren't applied (SuperUser/SuperSU never find /system/bin/SU) but /system/bin/app correctly get updated.
I'd prefer to not wipe the device's data and repair it from it's current state if possible.
TF101's current state : Stock .27 guevor kernel 717, CWM non touch recovery
From recovery
ls -l /sbin
http://pastebin.com/tmyZagUk
ls -l /system/bin
http://pastebin.com/6tsPaPF0
ls -l /system/xbin
http://pastebin.com/D3jW5Sy3
If you need more info please tell
Bounty : I'll send Russian chocolat and candies to the one that will find how to fix this !
Click to expand...
Click to collapse
Hi, your busybox installation seems corrupt (ie busybox binary is missing). You can reinstall busybox to /system/bin (do make sure that /system is mounted) from inside CWM and everything shall be fine. Your root su also seems to exist and should be fine.
If you can't do it in CWM then you can try and connect to the tablet in normal use mode and then run /system/bin/su and you should be root. Then you can install busybox manually ( you'll need to upload the busybox binary to /data/local/tmp or something) and run:
/system/bin/toolbox chmod 755 /data/local/tmp/busybox ( or if you're in CWM make sure /data is also mounted and then run: /sbin/chmod 755 /data/local/tmp/busybox )
/data/local/tmp/busybox --install /system/bin ( Please verify syntax ).
Good luck!
Sent from my Transformer TF101G using xda app-developers app
idcrisis said:
Hi, your busybox installation seems corrupt (ie busybox binary is missing). You can reinstall busybox to /system/bin (do make sure that /system is mounted) from inside CWM and everything shall be fine. Your root su also seems to exist and should be fine.
If you can't do it in CWM then you can try and connect to the tablet in normal use mode and then run /system/bin/su and you should be root. Then you can install busybox manually ( you'll need to upload the busybox binary to /data/local/tmp or something) and run:
/system/bin/toolbox chmod 755 /data/local/tmp/busybox ( or if you're in CWM make sure /data is also mounted and then run: /sbin/chmod 755 /data/local/tmp/busybox )
/data/local/tmp/busybox --install /system/bin ( Please verify syntax ).
Good luck!
Sent from my Transformer TF101G using xda app-developers app
Click to expand...
Click to collapse
Hello, i cannot do anything if not under CWM (even ls gives a "not found" if not in CWM)
I tried /system/xbin/su and got a
"sh: /system/etc/mkshrc[8]: id: not found"
Rebooted in CWM and tried to install Busybox
i mounted /system /data and /sdcard
i created the folder /data/local/temp
cp /sdcard/busybox /data/local/temp
applied /sbin/chmod 755 to /data/local/temp/busybox
ran /data/local/temp/busybox --install /system/bin and got a "Invalid cross-device link" error on every commands busybox tried to install
http://pastebin.com/g3DMHbJz
Tried to install it on /system/xbin too, but same error
Note : When i use /system/xbin/su in CWM, it change name to [email protected] from ~# while it doesn't in normal mode
Edit : Titanium backup rework :
In CWM, i copied busybox to /system/bin, and i installed it to /system/bin from /system/bin
cp /data/local/temp/busybox /system/bin
/system/bin/busybox --install /system/bin
I'm now checking if only Titanium backup works or if everything else too
Thanks for your help, i don't know if it's done yet, but i made a progress using your information !
Edit 2 : Seems everything works, please send me a private message to talk about candies and chocolat
Magissia said:
Edit 2 : Seems everything works, please send me a private message to talk about candies and chocolat
Click to expand...
Click to collapse
Good to see everything works. Give the candy to some children in the neighborhood mate, I'm watching the calories
Cheers!
Sent from my Transformer TF101G using xda app-developers app
I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app
look for the error message in /cache/recovery/recovery.log
If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....
This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app
OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.
I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks
The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck
Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks
--- I posted to general by accident, meant to do Q&A, but don't have permission to delete as a new user. --
--- Please see the question in Q&A ---
Greetings,
I'm new here, and can't get over to the developers forums to ask. I have two GT-I9500s for development purposes, one if full of junk, and the other is still stock, except for recovery. They both have CWM Recovery v6.0.3.2, the latest available pre-compiled I've found. The stock phone has only been booted once. That system is not rooted (and this is my whole point, I want as close to stock as possible)
I am attempting to extract the system image from Stock I9500. I have booted into CWM Recovery mode, then "adb shell" into the device. All commands I issue to the shell return "Permission Denied"
Code:
:$ adb shell
~ $ ls
/sbin/sh: ls: Permission denied
~ $ dd of=/storage/extSdCard/SYSTEM.img if=/dev/block/mmcblk0p20 bs=4069
/sbin/sh: dd: Permission denied
~ $ su
/sbin/sh: su: Permission denied
~ $ sudo su
/sbin/sh: sudo: Permission denied
I have tried to use Advanced->Fix Permissions to no avail.
CWM is pure and latest from www dot clockworkmod dot com slash rommanager (new users apparently cannot post links). CWM is able successfully operate "Backup to External" from the stock device.
The end goal is to clone the clean, stock device onto the other one. CWM claims success on "Restore from External" to the other device, but it sits on the "Samsung" loading screen forever.
A solution to either or both of these problems would be appreciated.
-MM
same issue
I have the same issue. I first also didn't adb shell available. But I fixed it in recovery mode by doing mount /system. However, now like you I have no permissions at all. I'm considering doing a factory reset, but that's gonna be my final resort. I first go looking for other ways to come around it.
ansjovis86 said:
I have the same issue. I first also didn't adb shell available. But I fixed it in recovery mode by doing mount /system. However, now like you I have no permissions at all. I'm considering doing a factory reset, but that's gonna be my final resort. I first go looking for other ways to come around it.
Click to expand...
Click to collapse
You need to allow your pc first to use adb. Boot into android, use adb and press allow. After that you can use adb in recovery. If it still fails, then try a different recovery. Philz or TWRP.