[SUPPORT] Update failures

Search This thread
There is a hiccup with the newest release. Unfortunately, Google Play doesn't allow the developer to roll back. Please see @Chainfire's post in the stable thread.

But It is always possible for developers to publish a new release on Google Play, no matter if it is really a new piece of code or just a copy of an old one. Don't want to put a copy? Ok, just change 1 bit.
In simple words: yes, can roll back by releasing a new "fake version" that in fact is the good old proven version.

But that was not the option taken by developer on current SU case, even as a temporary quick fix, a stop bleeding strategy. And thus the current problematic v2.81 is continuously spreading worldwide through Google Play, every minute, more and more users loosing root and even getting bootloop (sometimes without possibility to recover without losing data).
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
But It is always possible for developers to publish a new release on Google Play, no matter if it is really a new piece of code or just a copy of an old one. Don't want to put a copy? Ok, just change 1 bit.
In simple words: yes, can roll back by releasing a new "fake version" that in fact is the good old proven version.

But that was not the option taken by developer on current SU case, even as a temporary quick fix, a stop bleeding strategy. And thus the current problematic v2.81 is continuously spreading worldwide through Google Play, every minute, more and more users loosing root and even getting bootloop (sometimes without possibility to recover without losing data).
2.81 was a roll back. Still broke stuff.

IMHO, a larger part of the problem are blind updates of invasive apps like this. At a minimum, checking the stable thread would have shown that problems were developing. To blindly install or update a root app of all things is asking for trouble. It's hard to feel badly for people when the information has been out there for hours before their trouble began.

If it was simply a calendar app or a music player then I'd understand the frustration.
 
Last edited:
Please read the first thread that also refers to the second thread.

Both are from Chainfire...

https://xdaforums.com/showpost.php?p=72430541&postcount=9844

https://xdaforums.com/showpost.php?p=72429329&postcount=9810

Please note the reference to the BindFix file within the second link (above).

It's also encouraged for users to disregard/ignore the Play Store SuperSU update for v2.81 as it has issues too.

I, personally, am forced to reflash the Stable v2.79 until the issues can be resolved by Chainfire.


"Live Long and Prosper..."
~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise

"Live Long and Prosper..."
~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
 
  • Like
Reactions: ProfEngr
2.81 was a roll back.

No, it was not. As far as was written it was some kind of a mixed v2.79 and v2. 80. And people updating from v2.79 to current v2. 81 today on Google Play are having problems (see comments there), what prooves that's the case.
A good "roll back" would be a pure copy of v2.79....thus new people updating would not have any problems.

---------- Post added at 07:38 PM ---------- Previous post was at 07:33 PM ----------

Please read....

Please note the reference to the BindFix file within the second link (above).

It's also encouraged for users to disregard/ignore the Play Store SuperSU update for v2.81 as it has issues too.


Cool. Now just tell this to everyone, worldwide, all languages, that even don't know about xda. :) Got it? That's the problem.

By the way I didn't have any problem. I always set manual updates for critical apps, like su. And when taking risks I be sure to have nandroid backups.
 
Last edited:
  • Like
Reactions: Ibuprophen

xxxtncxxx

Senior Member
So I understand there are issues with 2.81 it fails for me on the SePolicy patch on recovery zip and Play Store update binary fails and root is lost after. I am not posting looking for help just thought you could use the info, if you need me to do anything else just let me know. I rolled back to 2.79 so building an su.log via adb shell as instructed is only gonna show my good SuperSU install info (I think). Here is my recovery log hope it helps.
BUY SuperSU PRO!!!
Pixel XL
Android 7.1.2 LineageOS base
Latest build 05/26/2017 of https://xdaforums.com/pixel-xl/development/rom-team-octos-oct-n-t3533511
 

Attachments

  • recovery.log.tar.gz
    8.8 KB · Views: 14

iandsteve-xda

New member
Feb 13, 2009
1
1
Possible repair method when unable to flash (e.g. locked bootloader)

I lost root when the binary update failed with v2.80. I spent almost a whole day attempting to get back to working SuperSU using a number of different versions. I was able to re-root the device via various non-SuperSU methods including both apk and adb based solutions BUT on attempting to switch back to SuperSU and update the su binary (e.g. using Super-sume etc.), I was always met with either a binary occupied or an installation failed error message. I finally found a method that worked for me (Huawei Y360, Android 4.4.2, locked bootloader.) (I'm not sure whether all these steps were completely necessary or not but better safe than sorry):

Installed the LATEST version of the KingRoot apk.
Rooted the device with KingRoot.
Used SuperRoot to check that the binary is showing as KingRoot (3.48 or 3.78 I think, I can't quite remember, but that's not important.)
Rebooted.
Fully unrooted with KingRoot.
(Some earlier versions of KingRoot did NOT unroot correctly so be sure to have downloaded the latest version. I think this may have been the vital step that cleaned up whatever the issue was with updating the su binary.)
Rebooted.
Used SuperRoot to check that there was now NO su binary present at all.
Re-installed KingRoot.
Rooted the device AGAIN with KingRoot.
Installed SuperSU 2.79 SR3 alongside KingRoot (so that SuperSU could use KingRoot to get root authorisation.)
Updated the su binary in SuperSU. (This MIGHT still have given me an error message but be sure to check with SuperRoot afterwards anyway because it seemed to have worked despite the error message.) (SuperSU also failed to uninstall KingRoot afterwards when it offered to uninstall conflicting apps.)
Used SuperRoot to check that the su binary is now showing as SuperSU 2.79.
Manually uninstalled KingRoot (and any other apps it has installed, such as Purify) (WITHOUT unrooting in KingRoot!)
Re-opened SuperSU after uninstalling KingRoot and was prompted to update the su binary AGAIN. This time it said that it WAS successful.
Rebooted and tested: I could now get root authorisation via SuperSU again!

No promises, obviously! But it worked for me so I hope it helps someone else too!
 
  • Like
Reactions: budies3

truelies1

Senior Member
Aug 14, 2011
559
31
I am using HTC M7, the twrp is 3.0.0. I tried 2.79 sr3, but it can't boot, just stay at animation when updating binary. Only install 2.46 can boot my phone. Certainly 2.80 and 2.81 not work. What's the reason for this? Does new edition of SuperSU can only work on newest twrp?
 

Lone Stranger

Member
Oct 12, 2012
6
0
Install Causes Unrecoverable Bootloop on Moto X (xt1058)

Phone: Moto X 2013, xt1058, US- ATT, unlocked
Version: 5.1, rooted via SuperSU, TWRP installed and functioning.
No other Superusery apps, Xposed or BusyBox installed, ever.

There's a few threads about SuperSU update failures, so if there's a better one to post in please let me know.

A few days ago I took an update to SuperSU (I can't find out which version) and mistakenly selected to install via TWRP instead of "normal." As I recall it rebooted to TWRP and I don't remember doing anything except rebooting normally. Everything seemed to be working as usual.

Sunday night it asked to be updated again, and again without looking at which version, I selected to install via the "normal" method, it rebooted to the Android splash screen and stays there. It will reboot using the power button, but again it stays on the splash screen. I left it all night like this. In this state it discharges the full battery in a few hours. In normal use the battery lasts 2 days.

It won't boot into recovery, and with the splash screen displaying, the usb connection won't work for adb. RSD Lite doesn't see it either. I've checked the drivers and there doesn't seem to be any problems. It appears the phone is stuck at a point where the usb isn't active except for battery charging.

Any help is greatly appreciated.
 
Last edited:

shadow2797

Member
Aug 9, 2010
21
0
I have an HTC One m7, originally T-Mobile, but rooted S-Off and changed to International. I have a stock 5.0.2 (or whatever the latest possible version for my phone is) ROM.

SuperSU prompted me to update the binaries about a week ago, which I've done before and it went smoothly then. I got tired of the notification, so I decided to do it this morning. I selected the CWM/TWRP method. It booted into recovery flashed update.zip and rebooted. It appeared to hang at the HTC One boot screen. I left it like that for about 15 minutes and then tried rebooting. It appears I'm in a boot loop and I'm not sure how to proceed. I tried installing update.zip again from /cache/recovery but no dice, same thing.

How do I get back to a previous version? I have 2.65 on my phone still from originally rooting it, but I don't know how to uninstall the current version, nor do I know which version it is. I'm also not sure if 2.65 is compatible with Android 5.0.2. So if I need 2.79, how do I get that on my phone without boot? ADB?

Info Dump:
M7_UL PVT SHIP S-OFF RH
CID-BS_US001
HBOOT - 1.61.0000
OS 7.17.1540.51
TWRP 3.0.M0-0
 

Lone Stranger

Member
Oct 12, 2012
6
0
Fixed It

On my Moto X, I was eventually able to boot into fastboot by repeatedly pressing the volume down button at a rate of about twice per second. (Holding it down or any other method would not lead to fastboot.)

Once in fastboot I booted into TWRP and restored a full backup from a few months ago and it worked.

I updated everything except SuperSU, used it for a few days to make sure it was the way I wanted it, then backed up through TWRP.
 

shadow2797

Member
Aug 9, 2010
21
0
I was able to fix my problem by using unSU. I haven't rerooted yet, but that part is pretty straightforward. Hopefully, this helps someone else.
 

rizla2

Senior Member
Jul 2, 2013
218
27
Please help me.... I assume I have installed updated to that infamous 2.80 few days ago...installed a binary and all that. Today, I rebooted my phone and got stuck in bootloop....only advice I found on thread was to flash 2.79 zip...so I went into recovery, cleared cache and dalvik and flashed it, but the phone is still bootlooping. I disabled xposed, assuming it might help(used a zip for disabling it which apparently makes a disabled file in xposed's folder...) but that didn't help either. I really need to fix this... Anyways, I am using Sony Xperia Z1 Compact with dual recovery(PhilZ Touch 6.59.0, ClockworkMod v6.0.5.1 an TWRP v.2.8.7.0), locked bootloader cause I can't unlock it on this one... I hope somebody can guide me through this and help soon....
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
Please help me.... I assume I have installed updated to that infamous 2.80 few days ago...installed a binary and all that. Today, I rebooted my phone and got stuck in bootloop....only advice I found on thread was to flash 2.79 zip...so I went into recovery, cleared cache and dalvik and flashed it, but the phone is still bootlooping. I disabled xposed, assuming it might help(used a zip for disabling it which apparently makes a disabled file in xposed's folder...) but that didn't help either. I really need to fix this... Anyways, I am using Sony Xperia Z1 Compact with dual recovery(PhilZ Touch 6.59.0, ClockworkMod v6.0.5.1 an TWRP v.2.8.7.0), locked bootloader cause I can't unlock it on this one... I hope somebody can guide me through this and help soon....
Try osm0sis' unsu script. If that fixes your bootloop, you'll be unrooted. Then go back to what had worked. I'd suggest you turn off auto update in the play store for SuperSu.

Edit: You need to flash that file I linked to in recovery. I usually link to the thread [emoji4]

I would also suggest you search the stable and beta threads for your device.
 
Last edited:

rizla2

Senior Member
Jul 2, 2013
218
27
Try osm0sis' unsu script. If that fixes your bootloop, you'll be unrooted. Then go back to what had worked. I'd suggest you turn off auto update in the play store for SuperSu.

Edit: You need to flash that file I linked to in recovery. I usually link to the thread [emoji4]

I would also suggest you search the stable and beta threads for your device.

Actually, I have managed to fix it and the solution was a lot simpler than expected, I simply flashed THIS version of 2.79. @Chainfire linked this version in official post: https://download.chainfire.eu/1021/SuperSU/SR3-SuperSU-v2.79-SR3-20170114223742.zip and it seems to be different, I've seen other people reporting that this one does not fix the issue while the one on the official supersu site does...Might help some other people too...
 

spencermathews

New member
Dec 23, 2014
2
0
Moto X
Google Pixel 4a
Moto X 2013 Optimizing

I'm currently running SuperSU 2.79 since all of my attempts to upgrade binary and APK to 2.82 resulted in all apps optimizing at every boot.

I'm curious what the status is on this bug, which has already been reported by others.

Until this is fixed I intend to stay with 2.79, but on I every boot I get "The SU binary needs to be updated!" message. Is there a way to suppress this message?

Thanks!
Spencer

Moto X 2013 / XT1060 32GB / 5.1 LPAS23.12-39.7.1
 
Last edited:

ianfebay

New member
Jun 28, 2017
1
0
Sony Z5 E5823 Android 7.0 was rooted fine. Playstore updated SuperSu to 2.82 and now I keep getting message 'The SU Binary needs to be updated'. The binary update fails. Is this possibly going to be fixed?
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
Sony Z5 E5823 Android 7.0 was rooted fine. Playstore updated SuperSu to 2.82 and now I keep getting message 'The SU Binary needs to be updated'. The binary update fails. Is this possibly going to be fixed?
The 2.82 SR1 in the beta thread will probably fix it. You'll have to flash in recovery. Search that thread for your Z5 device, and you'll see there were problems. There was a "test" release that would be incorporated into the SR 1 release.
 
gpd xd (gaming tablet)
4.4.4 custom rom legacy 1.8
http://boards.dingoonity.org/gpd-android-devices/(rom)-legacyrom-kitkat-for-gpd-xd/
2.82 free

after updating su binary from notification, my home and recent button doesnt work. recent works if i long press it but shows the option menu as expected.
i tested twice becayse first time i didnt know what caused it but today i reflashed the rom and install my apps one at a time.
im convinced that su caused this error.
is there a way to go to previous version or some kind of fix?
thank you
 

Dave_247

Senior Member
I'm not sure in which topic to post this, but I guess this would be the best place.

My Xperia X gets stuck in an endless bootloop if I try flashing 2.8.2 SR3 with systemless SBIN mode using the aroma configurator, and changing nothing but the install method. I'm running the stock Sony firmware 34.3.A.0.194 with the Vodaphone AU carrier, which is Android 7.1.1. I have also used ta_poc to patch my bootloader and disable Sony RIC before installing SuperSU as otherwise it would fail to install.

I am able to root and boot successfully in regular systemless mode however with no issues however.

Attached my kernel crash log after over 5 consecutive reboots.
 

Attachments

  • console-ramoops-0.txt
    94.1 KB · Views: 16

Top Liked Posts

  • There are no posts matching your filters.
  • 102
    With all major changes to SuperSU, there are updates to both the GUI and binary. The GUI is the part you see on screen, the binary is what allows other apps to actually acquire root access. The first time you open SuperSU after such an update, it will attempt to update the binary to the latest version.

    There are a lot of components to the binary and it needs to be set up just right for everything to work. This is a complex operation, and sometimes it fails. SuperSU is used by dozens of millions of users across hundreds of different devices, running even more different firmware revisions - any change always has the potential to break something somewhere.

    SuperSU offers multiple ways of installation: in-app 'normal', in-app TWRP/CWM, and ZIP via TWRP/CWM. These all have their own strengths and weaknesses, so if one doesn't work, try the others if available.

    If you are reporting an update failure, you should include at least the following information. Some information requires some skill with adb to retrieve.

    - Exact device model
    This includes the brand, the model, and the carrier variant (if applicable: mostly USA, Korea, China)

    - Exact firmware version
    Which exact firmware are you using? If you are using a custom firmware, please include a link to the download for this firmware. If on top of that, you are also using a custom kernel, please include a link to the download for that as well.

    - Exact Android version
    Android x.y

    - Exact SuperSU version
    Which version were you running, and to which version are you updating? If using Pro, do you have OTA survival mode enabled?

    - Interfering apps
    There are some apps that can interfere with SuperSU installation, primarily:
    - other Superusery apps
    - Xposed
    - BusyBox (symlinked or non-symlinked)
    Include in your report if you have one or more of these installed.

    - Update methods tried
    In-app 'normal', in-app via recovery, and ZIP via recovery. If you used one of the recovery options, please include exactly which version of which recovery you are using, and if it's not an official build (so a TWRP not from the TeamWin website, a CWM not from CWM's site, etc) a link to where you got it from.

    Note that if you let TWRP or CWM "fix" root for you, or let them disable the firmware from flashing a new recovery (sometimes you are asked this), you have broken root, and the only way to recover it is flashing the full ZIP through recovery.

    - What kind of root are you left with?
    After a failed binary update, multiple outcomes are possible:
    - Root is lost. Apps cannot get root anymore, you cannot get root using "su" from an adb shell, etc
    - Root seems to mostly still work. Most apps still work, and/or "su" still works from an adb shell
    - Nothing seems to have changed at all, even the GUI still shows the old version number
    Report what state your device is in now. Note that you can get the version of the main "su" binary by running "su -v" from a terminal emulator or adb shell.

    - Logs from TWRP, when updating the binary using the TWRP/CWM button inside the SuperSU app
    After pressing the TWRP/CWM button, the device should reboot into TWRP, do it's thing for a few seconds, then reboot into Android. If SuperSU still complains about the binary, please retrieve the TWRP log file. You can retrieve it via adb pull /cache/recovery/last_log, which should produce the last_log file in your current directory. You still need at least partial root from booted Android to retrieve this log. Sadly it is wiped and replaced with a new file when you boot into recovery a second time, so you cannot retrieve it that way. Note that this log will always contain a number of errors, as the installer tries several things in several ways, that work differently on different firmwares. Attach this log file.

    - Logs from TWRP, when updating SuperSU completely via ZIP
    If after you boot back into Android, SuperSU is not working right or still asks for updated binaries, reboot back into TWRP, install the ZIP again. After the ZIP is installed, you can retrieve the log file via adb pull /tmp/recovery.log, which should produce the recovery.log file in your current directory. Attach this log file.

    - Logs from SuperSU (very important)
    If SuperSU keeps asking you to update the binaries after trying any which way and failing, please post the detection log. After updating has failed, don't reboot, but produce detection information via adb logcat -d | find /i "installer" > logcat.txt (Windows, use 'grep -i' instead of 'find /i' on Linux or OSX), which should produce a logcat.txt file in your current directory with several lines mentioning SuperSU. Attach this log file.

    - Various logs (very important)
    Some additional handy information can be gotten by via some adb shell calls. If you that working, copy/pasting the following commands should produce a nice sulog.txt file in your current directory, which you should attach to your post:
    (as always with copy/pasting, make sure you press enter a few times afterwards to make sure the last line was flushed)

    Code:
    adb shell getprop > sulog.txt
    adb shell set >> sulog.txt
    adb shell toolbox id >> sulog.txt
    adb shell busybox >> sulog.txt
    adb shell su -v >> sulog.txt
    adb shell su -V >> sulog.txt
    adb shell su -h >> sulog.txt
    adb shell su --self-test >> sulog.txt
    adb shell ls -l /system/xbin/*su* >> sulog.txt
    adb shell ls -lZ /system/xbin/*su* >> sulog.txt
    adb shell ls -lZ /system/bin/toolbox >> sulog.txt
    adb shell ls -l /system/bin >> sulog.txt
    adb shell ls -l /system/xbin >> sulog.txt
    adb shell ls -laR /su >> sulog.txt
    adb shell ps >> sulog.txt

    In closing
    All this information will help diagnose the problem, and potentially help fix the issue if there is something wrong with SuperSU itself (which is not unheard of). The more information you provide, the better you can be helped. Still, be aware that often it takes a while to get a problem sorted. Even when a lot of people are having the same problem (and many problems may look the same but deep down are separate issues), it is rare to find a user who actively wants to help fix the issue. Most users will only complain but then don't really assist in solving the issue. If you can be someone who can actively help, and by that I mean being responsive to questions, being available for a live debugging session, etc, you are a rare gem indeed, and your assistance will be greatly appreciated.

    If you are writing multiple posts, it is always helpful if you keep linking back to your original post with the report. Saves me time.

    Sorry for the inconvenience!
    11
    Note5 SM-N920C 6.0.1

    Hi @Chainfire

    The Note5 users would greatly appreciate your assistance.

    • Device: Samsung Galaxy Note5 SM-N920C (international model)
    • Firmware: N920CXXU2BPB6
    • Android version: 6.0.1
    • Recovery: twrp-3.0.0-0-nobleltezt-nobleltezt.img.tar (others won't boot into recovery or fail flash)
    • Knox warranty void: 1
    • SuperSU v2.67

    Device state:

    1. Install TWRP
    2. Wipe: system, data, cache, dalvik-cache
    3. Flash N920CXXU2BPB6 with Odin3 v3.10.6
    4. Boot and initial setup for start-up (skip where possible).
    5. No apps installed or any other changes made except enable developer options and check:
      a) OEM unlock is enabled
      b) enable USB debugging​
    6. Reboot into DL mode & Install TWRP again
    7. Boot into TWRP
    8. Flash SuperSU v2.67
    9. recovery.log (attached)
    10. Reboot into system
    11. No root access from SuperSU app (no SU binary installed)
    12. Other logs not obtainable due to "Read-only file system"

    I have also attempted to force inject su into system (2.52 & 2.67) via ramdisk modifications that had worked on my 5.1.1 kernels. No luck. I patched sepolicy and tried a few other things = no luck, but I believe we stll need a “permissive” kernel for that to work. Kernel source hasn't yet been released for me to compile. . . Is it SELinux preventing root and system mount and write ? Thing is, I can create a service from init.rc for deep sleep fix (only briefly checked though), so can write to scsi sysfs. I don't think having the N9208 recovery matters here, it appears to work OK.

    For further info, you can please check my post HERE, where @dr.ketan has opened a thread and trying to help users out.

    Cheer,

    UITA
    8
    SGH-T999
    4.3
    2.06 can update to 2.14 but binary update never takes
    BusyBox but dont know what kind
    In-app 'normal', in-app via recovery, and ZIP via recovery after that binary update still fails normal and via TWRP v2.8.0.1
    Still have root

    As stated on IRC, I'm going to need the logs described above.
    6
    I've done a factory reset & stoll have the same problem. How would I restore data?

    You would restore the data from a backup you've made before resetting ?

    In SuperSU you can try 'full unroot' from Settings (twice if necessary) and unroot, see if that resolves the slowness/crashing.
    5
    Hi Folks,

    First posting here but just in case I've stumbled upon something that's been missed..

    supersu (free) 2.45
    Kango (latest but doubt it matters)

    For reasons unimportant here, I accidently rooted my cheapo tablet.

    It appears kango wrote to /system/sbin/su whereas supersu wrote /system/xbin/su and subsequently supersu would keep wanting to update 'su' then fail.

    The long and the short of it is once I manually removed /system/sbin/su supersu stopped telling me 'su' was outdated. I don't know android but I do know linux.

    $PATH on my tablet has /system/sbin/ prior to /system/xbin/ so it would appear supersu is issuing 'su -V' as opposed to '/system/xbin/su -V' when it checks the version. The kingo 'su' was older than the supersu 'su'.

    Dunno what the solution is 'cos the older 'su' is going to get called first & I figure there's nothing but trouble to be gained from changing $PATH globally. Nevertheless it might be enough to check $PATH for unwanted 'su' and flag them, possibly offer to remove them? In my case I renamed it "/system/sbin/su.ORIGINAL" so that it's still runnable in an emergency.

    Cheers!