• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

KaMyKaSii

Senior Member
Feb 25, 2015
1,386
671
v2.78 SR1 (aka beta) has been released.

Release notes are here: https://plus.google.com/+Chainfire/posts/8mPirmjhgqT


I was happy to hear about the possible compatibility fix with Magisk, then decided to test. I was in TWRP, mounted /data/magisk.img, deleted the related folder to another super user manager, and I install SuperSU. Already I got a little confused when it was installed in system mode, which before always installed in systemless even without the /data/.supersu terminal command. I thought I'd give bootloop because before when i tried to force the system mode (i was without PC was and could not run the risk of running out of root/TWRP) always entered bootloop, but this time I believe that the changes in the boot.img made by Magisk cause Android boot. I opened the SuperSU app and said no binary was found, but when I opened the FX File Explorer and navigated to /system/xbin/ the binary "su" was there. I thought it was a bug first boot then restarted, but again the same thing. I went back the TWRP, installed the stock boot.img (removing Magisk) and reinstalled SuperSU now installed in systemless and it worked perfectly. So I do not know how it is in other devices, but at least in my seems that compatibility does not work yet

My device:
Quantum GO 4G, Android 6.0
http://www.meuquantum.com.br/smartphone-quantum-go-4g-32gb/t/20
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,713
www.chainfire.eu
Does this not have an interface, can't find supersu app for settings once flashed, for sr1

On some custom ROMs it is under "Settings". Otherwise, it may be that the system has not picked up the change.

You can take the APK from the ZIP and do "adb install -r /path/to/apk" from your computer to fix it, probably.

Was the intent of that last item to increase the boot time by a minute? That seems to be the case on my N5 running stock ROM.. just hangs at the Google logo for a long time before continuing.. :confused:

I've definitely never had any issues with su.d scripts running out of execution time.. my gappsintegrator script always continues to run for up to several minutes after boot completes no problem.

To reproduce the issue I'm assuming you just need a su.d script that sleeps until sys.boot_completed like mine currently does (to set a sysfs value overriding the ramdisk). Hopefully things can go back to executing in the background and not holding up the boot.

@Chainfire​ i wonder why increasing the su.d script launch time to 60 from 4 seconds?
I haven't tested it but doesn't it cause problem for LiveBoot? And also i have my script to setup lots of things and i want it to be run when bootanim is launched.

But maybe i haven't understand it correctly and it make su.d script 60 secs to excute and passing this delay scripts won't be launched. Which is this case avoid some problem i guess and i have nothing to complain.

Anyway your work is awesome. Thanks for your work! 

I think you both misunderstand how su.d is supposed to work. These are the guarantees:

- All SELinux patching is complete before su.d scripts are executed
- All scripts inside su.d are executed in alphabetical order (0-9a-z)
- Scripts are run serially. The next one in order is not started until the previous one has finished.
- Boot does not proceed until all scripts have been executed
--- unless your boot image does not support exec (very rare)
--- unless scripts run longer than the timeout (now 60 seconds, previously 4 seconds)

If your script does not need to delay the boot process, the script itself should make sure its actions are run asynchronously.

These scripts must delay the boot process, otherwise mods like (the first versions of) systemless xposed just aren't possible. And those sorts of mods are exactly what su.d was made to enable.

Example case: LiveBoot

/su/su.d/0000liveboot: (due to 0000, almost guaranteed to be the first thing run)
Code:
/su/bin/sush /data/user/0/eu.chainfire.liveboot/files/liveboot &

It calls SuperSU's copy of the shell, and has it execute /data/user/0/eu.chainfire.liveboot/files/liveboot. But due to the & sign at the end, this happens asynchronously in a background shell (standard scripting stuff).

In other words, LiveBoot delays the boot only for the few milliseconds it takes to spawn the background shell. It has no need to delay the boot process, and thus it doesn't.

Conclusion
If this delays your boot by one minute, one of your scripts needs adjustments. It was always delaying the boot process, now it just delays it a lot more and makes the problem apparent.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,713
www.chainfire.eu
I was happy to hear about the possible compatibility fix with Magisk, then decided to test. I was in TWRP, mounted /data/magisk.img, deleted the related folder to another super user manager, and I install SuperSU. Already I got a little confused when it was installed in system mode, which before always installed in systemless even without the /data/.supersu terminal command. I thought I'd give bootloop because before when i tried to force the system mode (i was without PC was and could not run the risk of running out of root/TWRP) always entered bootloop, but this time I believe that the changes in the boot.img made by Magisk cause Android boot. I opened the SuperSU app and said no binary was found, but when I opened the FX File Explorer and navigated to /system/xbin/ the binary "su" was there. I thought it was a bug first boot then restarted, but again the same thing. I went back the TWRP, installed the stock boot.img (removing Magisk) and reinstalled SuperSU now installed in systemless and it worked perfectly. So I do not know how it is in other devices, but at least in my seems that compatibility does not work yet

Some compatibility issues with Magisk were indeed fixed, but compatibility is not complete. There are still changes and fixes that need to be made inside Magisk; hopefully the next Magisk version will see full support, @topjohnwu is aware of the issues.

One of the things that Magisk breaks is the PATH, systemless su is removed from it. So you must enable BINDSYSTEMXBIN in SuperSU, and then still some commands will not work. Of course, Magisk's root toggle will not work with SuperSU either currently.

But that is why I am building suhide :)
 
Last edited:

KBanause

Senior Member
Jul 27, 2010
1,991
349
Munich
I just updated to 2.78 SR1 and some apps are having problems detecting that the device is rooted (Nexus 7 (2013) stock, build MOB30X and Nexus 6P, stock, build NRD90U). For example Helium or Secure Settings. Titanium Backup or Recently for example don't have any problems.
I can't tell which version was the last one working. I just noticed it after I have reinstalled Secure Settings on my Nexus 7 with SuperSU 2.77 BETA installed and it's telling me now that it's not rooted.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,713
www.chainfire.eu
I just updated to 2.78 SR1 and some apps are having problems detecting that the device is rooted (Nexus 7 (2013) stock, build MOB30X and Nexus 6P, stock, build NRD90U). For example Helium or Secure Settings. Titanium Backup or Recently for example don't have any problems.
I can't tell which version was the last one working. I just noticed it after I have reinstalled Secure Settings on my Nexus 7 with SuperSU 2.77 BETA installed and it's telling me now that it's not rooted.

Sounds to me like you had the old app compatibility mode enabled (BINDSYSTEMXBIN) previously, and you have it disabled now.

From adb shell (or Terminal Emulator), run 'su', then:
Code:
echo "BINDSYSTEMXBIN=true">>/data/.supersu

Then, reflash SuperSU.

Note that if your TWRP cannot decrypt your /data partition, this solution will not work.
 

KBanause

Senior Member
Jul 27, 2010
1,991
349
Munich
Sounds to me like you had the old app compatibility mode enabled (BINDSYSTEMXBIN) previously, and you have it disabled now.

From adb shell (or Terminal Emulator), run 'su', then:
Code:
echo "BINDSYSTEMXBIN=true">>/data/.supersu

Then, reflash SuperSU.

Note that if your TWRP cannot decrypt your /data partition, this solution will not work.

Thanks. Even though I didn't find /data/.supersu (on both devices) it has worked after I created the file and added the line you mentioned.
 

danmaman

Senior Member
Jan 15, 2012
1,376
891
hi
I'm on stable playstore version 2.78
can i flash this SR1 with flashfire over this?
or comes in near future an playstore update?

thanks in advance
 
Last edited:

smitharro

Senior Member
Jan 2, 2012
2,629
1,711
Blokker
hi
I'm on stable playstore version 2.78
can i flash this SR1 with flashfire over this?

thanks in advance
Just did that! Works like charm! (CM13, Lenovo Moto G4 Plus).
469eae360d47a30797968e9d9abfbe4a.jpg


Send with my Moto G4 Plus (XT1642) with CM13 using Tapatalk!
 
  • Like
Reactions: danmaman

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,442
87,713
www.chainfire.eu
Im curious as to why cache isn't used instead of data to circumvent that issue if the command only has to be set once?

You can use /cache/.supersu if you want. It also works :)

I am hesitant to rely on /cache though. Many people wipe it out of habit. And some tools do automatically.
 

dreamland2000

Senior Member
Jun 5, 2011
808
155
Just reading the release notes and not sure if it's me being paranoid but it says this latest release fixes a vulnerability to the kernel etc, this seems to have happened with the release that ccmt released with notifying @Chainfire and this new release has fixed the security risk.

Normally I wouldn't question this as I've used SuperSU for as long as I've had android but with the knowledge that an unknown Chinese company is in control and suddenly there is a security vulnerability in an app that can pretty much have few reign of your system begs the question as to the actual security behind this app anymore. We all know these Chinese dev companies are renowned for spamming apps or provide back door security issues in apps.

Like I said I may just be being paranoid and reading to much into this but it just raised the question as to how secure is this app becoming now it's in the hands of an invisible entity.
 

dratsablive

Senior Member
Feb 20, 2011
1,325
248
HARRISBURG
Just reading the release notes and not sure if it's me being paranoid but it says this latest release fixes a vulnerability to the kernel etc, this seems to have happened with the release that ccmt released with notifying @Chainfire and this new release has fixed the security risk.

Normally I wouldn't question this as I've used SuperSU for as long as I've had android but with the knowledge that an unknown Chinese company is in control and suddenly there is a security vulnerability in an app that can pretty much have few reign of your system begs the question as to the actual security behind this app anymore. We all know these Chinese dev companies are renowned for spamming apps or provide back door security issues in apps.

Like I said I may just be being paranoid and reading to much into this but it just raised the question as to how secure is this app becoming now it's in the hands of an invisible entity.
Wot you talking about Willis? SuperSU is now a Chinese company?

Sent from my Nexus 6P using XDA-Developers mobile app
 

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.