• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

swallowingled

Senior Member
Dec 23, 2013
205
94
IN
Anyone on 2.67 have issues with re-enabling after disabling root in supersu app?
It unroots fine and then says it failed rooting and try again after reboot.

This happened to me. I told it no to updating the binary and then canceled the dialog that told me it failed and then I immediately started receiving the notifications that apps were being granted root access. So for me at least it said it failed but it did not. All my root apps work as they did before, no issues and didn't need to reboot and try again.
 

Nekromantik

Senior Member
Apr 1, 2010
6,475
731
London
OnePlus 8 Pro
This happened to me. I told it no to updating the binary and then canceled the dialog that told me it failed and then I immediately started receiving the notifications that apps were being granted root access. So for me at least it said it failed but it did not. All my root apps work as they did before, no issues and didn't need to reboot and try again.

Yeah it works even though it asks for update,
However I cant stop the notifications. Annoying.
 

gorilla p

Recognized Contributor
Nov 30, 2011
3,599
2,808
Milwaukee
Xiaomi Mi Pad 4
OnePlus 8
I ran into a strange issue on my Nexus 5X. I'm running Resurrection Remix (CM13 base). I flashed SuperSU systemless 2.67.
I have looked at my screen a few tines and would randomly see it powered on, but black. I can only see the dimly lit backlight. There were no notifications and it didn't go away on its own.
I checked wakelocks and SuperSU screen wakelock was active for 3h26m in the past 20 hrs.
I'm not sure what would cause this.
Any input?
 

bobby janow

Senior Member
Jun 15, 2010
5,737
1,894
I've just not been able to reenable SuperSU from the app itself once I disable it. I'm on 2.67 an N5x, Stock image with Cataclysm overlay and Franco r-5 anykernel. Even a reboot keeps popping up the message about reinstalling binaries. Rebooted again and SuperSU app will not launch at all saying something like, SuperSU is not installed or can't be found. Recovery flash of 2.67 brings everything back to normal. Anyone else seeing this or can be more specific on the exact error message?
 

gorilla p

Recognized Contributor
Nov 30, 2011
3,599
2,808
Milwaukee
Xiaomi Mi Pad 4
OnePlus 8
I've just not been able to reenable SuperSU from the app itself once I disable it. I'm on 2.67 an N5x, Stock image with Cataclysm overlay and Franco r-5 anykernel. Even a reboot keeps popping up the message about reinstalling binaries. Rebooted again and SuperSU app will not launch at all saying something like, SuperSU is not installed or can't be found. Recovery flash of 2.67 brings everything back to normal. Anyone else seeing this or can be more specific on the exact error message?

You need to do some reading in the ROM thread.

Restore to latest factory. Easy to do it via Wugs.
Root and install custom recovery via Wugs
Boot to recovery and factory reset, format data if you want to disable encryption.
Flash ROM and GApps and boot to ROM. Ifnit gives you vendor binaries error, flash latest vendor image
Reboot to recovery, flash vendor image if needed, flash UnSu, flash superSU
 
Last edited:

bunklung

Senior Member
Mar 20, 2011
519
105
I am trying to change $PATH within a su.d script, but it's having no effect. Does this require a change to the kernel? Or is that $PATH being established AFTER su.d is executed?

I don't see where SU is modifying the PATH and when I unpack my unpatched stock kernel there is no mention of PATH in init.rc.

Certainly not the default place for a N6 PATH:
http://android.stackexchange.com/questions/3768/how-is-the-default-path-set
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
14,667
33,051
Halifax
GT-i9250
Nexus 7 (2013)
I am trying to change $PATH within a su.d script, but it's having no effect. Does this require a change to the kernel? Or is that $PATH being established AFTER su.d is executed?

I don't see where SU is modifying the PATH and when I unpack my unpatched stock kernel there is no mention of PATH in init.rc.

Certainly not the default place for a N6 PATH:
http://android.stackexchange.com/questions/3768/how-is-the-default-path-set

I don't think you can export any changes to the global path in Android unless you edit the ramdisk, which is in init.environ.rc (since KitKat, I believe). Beyond that the closest thing you can do is override it on your own specific shell instance by changing the command in your terminal emulator app, or within the script you're executing.
 
Last edited:
  • Like
Reactions: bunklung

Alxoom33

Senior Member
May 18, 2011
4,956
1,762
New York
www.sack-ip.com
the su binary needs to be updated
can someone help me?!
Re flash SU 2.67

Sent from my Nexus 6 using Tapatalk

---------- Post added at 06:06 PM ---------- Previous post was at 06:05 PM ----------

I've just not been able to reenable SuperSU from the app itself once I disable it. I'm on 2.67 an N5x, Stock image with Cataclysm overlay and Franco r-5 anykernel. Even a reboot keeps popping up the message about reinstalling binaries. Rebooted again and SuperSU app will not launch at all saying something like, SuperSU is not installed or can't be found. Recovery flash of 2.67 brings everything back to normal. Anyone else seeing this or can be more specific on the exact error message?
Re flash Su! 2.67.

Sent from my Nexus 6 using Tapatalk
 

gorilla p

Recognized Contributor
Nov 30, 2011
3,599
2,808
Milwaukee
Xiaomi Mi Pad 4
OnePlus 8
I ran into a strange issue on my Nexus 5X. I'm running Resurrection Remix (CM13 base). I flashed SuperSU systemless 2.67.
I have looked at my screen a few tines and would randomly see it powered on, but black. I can only see the dimly lit backlight. There were no notifications and it didn't go away on its own.
I checked wakelocks and SuperSU screen wakelock was active for 3h26m in the past 20 hrs.
I'm not sure what would cause this.
Any input?

I reset and checked wakelock info again and saw Greenify had been causing a long wakelock.
I was trying the aggressive doze, and I also noticed it was unchecked for some reason under "Accessibility".
I checked it again and disabled aggressive doze. I'll see if that fixes it.
 
  • Like
Reactions: frikakwa

Sachi315

Senior Member
Sep 23, 2013
122
48
OnePlus 8T
BETA 2.67 Issues

I installed beta 2.67. Wiped cache before and after. Install worked but crashed some android apps so I reinstalled stock marshmallow and installed 2.56 which had no issues its working fine.
 

bobby janow

Senior Member
Jun 15, 2010
5,737
1,894
You need to do some reading in the ROM thread.

Restore to latest factory. Easy to do it via Wugs.
Root and install custom recovery via Wugs
Boot to recovery and factory reset, format data if you want to disable encryption.
Flash ROM and GApps and boot to ROM. Ifnit gives you vendor binaries error, flash latest vendor image
Reboot to recovery, flash vendor image if needed, flash UnSu, flash superSU

I don't know what Wugs is nor do I care to know. I can restore to latest factory with my eyes closed. I don't care to disable encryption and if by now I haven't flashed the vendor.img I'd not be here. Please don't patronize. But thanks for the info.
 

discslinger

Member
Dec 3, 2011
19
3
Please clarify...

You go into TWRP > Advanced > Terminal Command, then select the current folder (it could be the root folder, it doesn't matter). Then type the command(s) in the text box one by one. You don't need to worry about it since you are already on systemless root.

Are you saying there is no need to type these commands if already "systemlessly rooted" so to speak? I am rooted on systemless root btw.

Also, when you say, "Select current folder" - what folder are you talking about? And in the case of the issuing a terminal command in TWRP menu - are you saying a text box open up when the 'current folder' is selected. This sounds weird the way this is worded, please clarify this - I appreciate it!

One thing Solved:
I see hitting the check mark in the corner brings up a terminal command box- or whatever that is called. Still... fuzzy on the "don't need to worry about it". What is 'it' ? Tx!
 
Last edited:

nathanchance

Senior Recognized Developer / Contributor
Jul 22, 2015
13,751
49,974
26
Mesa, AZ
nathanchance.dev
Are you saying there is no need to type these commands if already "systemlessly rooted" so to speak? I am rooted on systemless root btw.

Also, when you say, "Select current folder" - what folder are you talking about. And in the case of the issuing a terminal command in TWRP menu - are you saying a text box open up when the 'current folder' is selected. This sounds weird the way this is worded, please clarify this - I appreciate it!

Yeah if you are on 2.60+ and flash 2.64+, the installer will keep your systemless root. You only need to worry about those commands on a clean install (when you wipe the /data partition). The current folder should usually be root ( / ). Yes, a text box will pop up that you type those commands in.
 

discslinger

Member
Dec 3, 2011
19
3
Yeah if you are on 2.60+ and flash 2.64+, the installer will keep your systemless root. You only need to worry about those commands on a clean install (when you wipe the /data partition). The current folder should usually be root ( / ). Yes, a text box will pop up that you type those commands in.
Thank you! Now on Pure Nexus! Starting up now. Booted. Got 'vendor image out of date' message.

Is that a correct message... considering that I did flash the ' latest vendor.img' ?
I was on mmb29K and just double checked I did indeed download the correct zip.
Do I need to flash a stock vendor image?

Tx. in advance!

Going ahead to setup phone now.
 
Last edited:

wvcadle

Senior Member
Dec 31, 2011
1,520
480
Yeah if you are on 2.60+ and flash 2.64+, the installer will keep your systemless root. You only need to worry about those commands on a clean install (when you wipe the /data partition). The current folder should usually be root ( / ). Yes, a text box will pop up that you type those commands in.

Now that Google has patched AP, is there still a benefit of systemless root compared to traditional? For now, if one is rooted traditionally, could one still use AP by disabling SU beforehand, then re-enabling it?
 

j1gga84

Senior Member
Jun 21, 2012
4,614
2,730
Bremen
www.android-hilfe.de
I have a problem to install 2.67, I got following error message in recovery when I am trying to flash:

Boot image patcher:
-Finding boot image
-Boot image: /dev/block/mmcblk0p5
-Extracting ramdisk
-Failure, aborting

Using stock kernel.
The strange thing is that it worked in older builds of the CM12.1 based ROM I have currently installed.
It works without problems when I flash 2.46 in recovery :confused:

regards
 
  • Like
Reactions: blacklight1025

Top Liked Posts

  • There are no posts matching your filters.
  • 2527
    This thread is for SuperSU releases that are still in testing, and are not yet available through the Play store. The main thread for stable SuperSU releases is located here: https://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703. The changelogs are in the old release thread.

    Please keep track of the version numbers in the thread titles, as the latest test release may not always be newer than the latest stable release.

    The latest test release is:
    SR5-SuperSU-v2.82-SR5-20171001224502.zip
    RELEASE NOTES
    That is a recovery flashable ZIP (I recommend FlashFire or TWRP). If you want to install via APK, it is also present inside the ZIP, in the common folder.
    614
    unSU Script zip -- Unroot with ease!

    Originally this was a little zip to help with uninstalling the old system-modifying version of SuperSU. It properly restores all the original files the SuperSU installer backed up (so, file-based OTA friendly!) and removes any files added by the installer/app. I figured other people might find it handy as well so it's attached below. Be aware, if you flashed SuperSU twice mistakenly, the SuperSU installer wasn't written to recognize that and so you've lost your originals; a system.img flash WILL be necessary in your case.

    Due to popular demand by the custom ROM community using this to unroot and pass SafetyNet checks/use Android Pay, etc., the script has been expanded to unroot Koush's SuperUser, ROM su binaries, as well as SuperSU Systemless (su.img and BINDSBIN), phh's Superuser (which is also systemless), and now Magisk and LineageOS addonsu.

    Note: To completely remove all traces of the systemless roots, you still need to flash a different, unrooted boot.img, likely the default one that came with the ROM. You can extract it from the ROM zip (or a /data/stock*.gz backup from your root solution before flashing unSU) and flash it using TWRP's awesome "Flash Image" functionality, or, "dirty flashing" the ROM zip should also work.

    My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

    P.S. If you found this handy then please check out my Odds and Ends thread for more flashable goodness. :D

    Previous download counts: 58944; 158506; 59850; 226692
    578
    f2fs with Android story is always complicated.

    So why is SuperSU broken with many custom ROMs:
    systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
    The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
    This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

    This “fix” is rather dumb :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

    The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
    (The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
    So you have 2 choices :
    A. Cherry-pick that fix separately
    B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


    But there are more stories to be told, unfortunately.
    Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
    There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

    You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    Without this fix, the kernel will panic upon reading any data.


    So we took care of the method A.
    However, there is still an issue with method B : deadlock.

    As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
    It took about a month to bisect it, and I got the culprit commit :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

    I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
    Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


    TL;DR
    It’s not @Chainfire 's fault.
    You have to ask the kernel developer to fix the issue.
    2 methods for the kernel developers

    A. Incorporate only the necessary 2 fixes to fix loopback images :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
    (A little credit would be appreciated, as it took me a frustrating month to bisect this)

    Thanks.
    348
    --- reserved ---
    189
    @ everyone

    This post is likely an important one going forward, it could be the answer to various issues people have on 6.0 related to /system.

    The conversation below pertains specifically to Nexus 6 @ 6.0.1, which has an almost full /system, but I'll bet the issue exists on all Nexus devices.

    Do you mean that there's even less space than on 6.0?
    Titanium Backup reports that there 15.6 MB free. Shouldn't this be enough for a very small mod such as an edit to build. prop?

    So after some further investigation, something pretty odd is going on.

    ext4 (the filesystem) has various types of reserved blocks.

    I suspect the tools on booted Android do not count one type of reserved block. Indeed, when you use "df" utility (both toolbox and toybox), it shows 15mb or so free. Using the same "df" utility in recovery (busybox) shows 0b free. It does show that not all blocks are in use, but the remainder is likely reserved.

    If you use a root shell on either booted Android or in recovery, trying to write contents to a new file in /system will fail. To make matters worse, file creation succeeds, but writing content does not, so you end up with a 0 byte file. You need to delete a few extra megabytes of files, before you are able to write even 1 byte to a new file!

    Many editing tools remove the old file and write a new file at the same spot rather than truly editing a file. I'm not sure if the latter has any chance of succeeding, but the former would definitely fail in this scenario.

    While the issue is understandable technically, it is likely to trip up a lot of tools, as the error is generated at the least expected moment.

    This issue is a magnet for file corruption and bootloops. Beware this issue when modifying anything on /system!

    DEVS Immediate hunch is that the difference is explained by usage of struct statfs's bfree vs bavail member.

    TL;DR Yes, even though TiBu and whatever other tool are showing you megabytes free, adding/modifying files is likely to give unexpected results on a (near-)full /system partition, and an unlucky edit can definitely prevent the device from booting! Can't give you exact numbers right now, but before modifying files or adding files to /system, I would recommend deleting files until you have at least 30-ish mb free.