[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread
L

LastStandingDroid

Guest
Btw is supersus development going on? Or no updates anymore(last was october)..

Sent from my Nexus 5X using XDA Labs
Either it's one big updated or the Chinese team nuked it. Best way would be to ask chain fire if he heard something. Just don't spam him ;)

Sent from my DUK-L09 using Tapatalk
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,697
40,167
Halifax
GT-i9250
Google Nexus 4
Chainfire has retired and he no longer had ties to CCMT. It's really not appropriate to drag him back in at all.

But it would certainly be interesting to hear his opinion on it all if/when he is free to give it. I think he alluded to wanting to do so in one of his last posts.
 
Last edited:

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
But it would certainly be interesting to hear his opinion on it all if he is free to give it. I think he eluded to wanting to do so in one of his last posts.
I don't disagree :) I do however think it's inappropriate to post in a public manner suggesting people take action involving Chainfire. If the individual wanted to pursue that independently, then post the response, that would be different.

I think Chainfire also stated he was prohibited by contract, at least at this time, to voice opinions as it relates to SuperSu.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
 

srqrob

Senior Member
Dec 5, 2011
264
69
So many of us have respect and admiration for the skills and knowledge of Chainfire, that it's disheartening to see SuperSU languishing and becoming more and more irrelevant in moving forward. It's been so key for so long. We still owe this guy a debt of gratitude and I'd welcome him moving back into this sphere when he feels it's right.
 
  • Like
Reactions: EmiRus
For those of you who may not be aware of this (and those who don't perform a search for awareness either)...

The following thread was posted by @Chainfire just over a month ago regarding his thoughts and opinions.

https://xdaforums.com/showpost.php?p=75028239&postcount=11744

Personally, I don't feel that it's respectful/fair to pin the direction that SuperSU has been going on Chainfire and the above post reflects this as well.

I truly believe that Chainfire's heart has been dropping every time issues arise without being addressed by CCMT.

Just my, personal, thoughts and opinions regarding this and I can just recommend that we all can just "hope for the best but, prepare for the worse". :)


~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
 

Sr. Zé Alguém

Senior Member
Nov 3, 2016
789
819
Hello SuperSu experts, do someone know if it is possible to use a hashtag icon inside notification bar instead of the toast message when an app is granted root access? (similarly to Lineage OS)
 

DB126

Senior Member
Oct 15, 2013
15,356
10,163
Hello SuperSu experts, do someone know if it is possible to use a hashtag icon inside notification bar instead of the toast message when an app is granted root access? (similarly to Lineage OS)
Not that I'm aware of. However, some ROMs present the status bar hash when root is active; also check for an Xposed module. With that feature present you could then disable SuperSU's toast. Just a thought...have never tested it.
 
  • Like
Reactions: Sr. Zé Alguém

Drashnar

Senior Member
Apr 29, 2014
116
9
Cleveland
Ok, a question trying to flash this. I just flashed the newest Feb update for my Pixel XL. The OS is working fine. When I go to try to flash this SuperSU 2.82 SR5 when it gets to "-Patching sepolicy" the very next line I get "---Failure, aborting".

I assume that this means something has changed in Google's newest image that is causing some issues? This is the first image in quite awhile where the SuperSU flash won't work. Can anyone help shed some light on what's going on? Thanks.
 

piperx

Senior Member
Ok, a question trying to flash this. I just flashed the newest Feb update for my Pixel XL. The OS is working fine. When I go to try to flash this SuperSU 2.82 SR5 when it gets to "-Patching sepolicy" the very next line I get "---Failure, aborting".

I assume that this means something has changed in Google's newest image that is causing some issues? This is the first image in quite awhile where the SuperSU flash won't work. Can anyone help shed some light on what's going on? Thanks.
Really ?

Have you read any of the last few pages (or search) or did you just blindly post a question ?

Sent from my Pixel using XDA-Developers Legacy app
 

shaggyskunk

Recognized Contributor
Nov 22, 2011
19,731
16,043
IDK

pkelly517

Senior Member
Dec 28, 2011
1,672
1,681
Can see Houston from here
Google Pixel 6
I just posted a question. Didn't have time to do in depth researching, so I posted a question and left it at that. Can you point me to a specific post to go read? Thanks.

Sent from my Pixel XL using Tapatalk
Of you don't have time to read the last couple pages or do a simple search, why should anyone else bother to spoon feed you?

Sent from my Pixel C using Tapatalk
 
  • Like
Reactions: force70 and ashyx

gothicVI

Senior Member
Jun 7, 2014
1,328
627
Munich
I sense some salt ;)
Seriously though: performing own searches is a must by the XDA rules and spoonfeeding shouldn't happen. That said I'm sure hoping for someone else's device to break also can't be the solution so eventually remind people of search as it has been done and ignore them otherwise - especially when the answer has already been given -- ot violates XDA rules as well.

Gesendet von meinem Moto G 2014 LTE mit Tapatalk
 
  • Like
Reactions: IronTechmonkey

Grafiqa

Member
Jul 11, 2010
27
0
I have a Problem. After installing xposed framework v89 arm64, super su don't load the log or app list.

Gesendet von meinem SM-N950F mit Tapatalk
 
I have a Problem. After installing xposed framework v89 arm64, super su don't load the log or app list. Gesendet von meinem SM-N950F mit Tapatalk
Why are you posting in the SuperSu thread? Sounds like an xposed problem. "Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Please correct me if I'm wrong @Grafiqa...

I think that Grafiqa wasn't sure where to post since it involved both and It looks, to me, that this member was trying to state the following (in so many words):

I had flashed the XPosed Framework v89 (ARM64) and now SuperSU is no longer within the App Drawer.
@Grafiqa, what I would do is just think about the order in which this problem started.

First of all, If I had SuperSU installed and working then all should/may be well with the SuperSU.

Then I flash the XPosed Framework and SuperSU is then missing from the App Drawer. I would first ask for some member guidance within the appropriate XPosed Discussion thread before I would point to SuperSU.

A little advice first... Be sure you provide more information regarding your issue like what your device is and what the process order you took up to the point of when your issue first started as well as the specific file name(s) if you reference any.

I wish you the best of luck! :)


~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
 

Grafiqa

Member
Jul 11, 2010
27
0
I ask by the xposed board. No one answer. Srry 4 my English. After no one answer in 2 german Boards and xposed thread, i tried it here. Now i post it here and hope someone can help me.

Srry

Gesendet von meinem SM-N950F mit Tapatalk
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2533
    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://xdaforums.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.
    617
    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.