Ja_som
Senior Member
- Apr 1, 2013
- 3,720
- 2,045
[BETA][2017.10.01] SuperSU v2.82 SR5
- Thread starter Chainfire
- Start date
Can someone help when I flash ss v2.56 my phone won't boot so I have to restore my phone. I have root but I don't have a root manager app it's just the default where the only thing it does is ask you if you would like to grant root access then you can't even disable it
I'm wondering this too. Scared to try it.
EDIT - Rebooted to fastboot, flashed latest TWRP, then used the fastboot menu to reboot directly to recovery, from there flashed 2.61 via TWRP and it worked!
Last edited:
Working flawless with 6.0.1 and a custom kernel ?
Edit: Somebody go tell TWRP team that asking users to install SuperSU is not necessary anymore lol
Inviato dal mio Nexus 5 utilizzando Tapatalk
Last edited:
Both of you should be readers in this thread at best, not posters. There will be test reports when users have tried it (and there have been some already). Asking the hour a firmware is released if it works with device X is just counterproductive.
I'm at work , I can't till tonight . But if no one has confirmed I will for sure
---------- Post added at 12:30 PM ---------- Previous post was at 12:29 PM ----------
I did read and didn't see my answer . Maybe I missed it . Sorry...
Last edited:
@Chainfire flashed v2.61 on Galaxy Tab S2 SM-T710. Working fine, except that whenever I open the SuperSU app, it tells me that there is no binary installed. What do I do?
For locked bootloader devices it depends on a working exploit being available for your firmware. This is not the place to find those, as I do not make nor involve myself with them.
Well, that means it really doesn't work at all. But at least it didn't bootloop. Not sure what the answer is here, as I have no idea what the problem is for you.
Works fine on N6 with 2.61
Works fine on N6 with 2.61
Flashed Android 6.0.1, copied SU2.61 and then flashed in TWRP
Works fine on N6 with 2.61
Flashed Android 6.0.1, copied SU2.61 and then flashed in TWRP
Last edited:
Oh sure, now I gotta go sideload all my devices again. Gee thanks! 
Seriously, though, thanks for this. I've tested 2.6.0 on S4 GPE 5.1, Note 10.1 2014 5.1.1, and my NX6 6.0.1 and all 3 work. So this will be a cake walk to sideload them all with 2.6.1.
Seriously, though, thanks for this. I've tested 2.6.0 on S4 GPE 5.1, Note 10.1 2014 5.1.1, and my NX6 6.0.1 and all 3 work. So this will be a cake walk to sideload them all with 2.6.1.
Wouldn't work, there currently is no version of CyanogenMod for the Tab S2.
Captain_Throwback
Recognized Developer
Not every device that TWRP supports is running Marshmallow . . . but trust me, they already know about this.
Frack. Hey @Chainfire trying to update my S4 GPE that's got 2.6.0 on it:
...
Checking patch status
Already patched, attempting to find stock backup
restore failed, aborting
I'll just go back to stock and reflash but I thought you'd like to know.
...
Checking patch status
Already patched, attempting to find stock backup
restore failed, aborting
I'll just go back to stock and reflash but I thought you'd like to know.
Maxr1998
Recognized Developer
SuperSU 2.60 works fine on my 6.0.1 Nexus 6P, though I wonder why the settings of the SuperSU app get removed when updated?
d.cortez
Senior Member
@Chainfire, i successfully installed 2.61 to my Note 5 SM-N9208, used Root Explorer to successfully rename a filed in the data app folder, opened SuperSU 2.61 Pro and i was not prompted to update the binary. rebooted to recovery to install Viper4A fix (from foreverLoco) and xposed and everything is working so far. initial 2.61 installation steps were:v2.61 posted in the WIP thread. Changelogs are in the STABLE thread.
Gentlemen, start your testing!
These Systemless SuperSU BETA's are slowly approaching what I want them to be. Soon they will be the only BETA's (they'll still be non-systemless for pre-6.0 devices aside from Samsung 5.1, but I won't keep 2.52 around anymore). Might even be time to start updating the CF-Auto-Roots finally. And FlashFire!
1 ODIN flashed 5.1.1 AOK2 firmware (latest release for my device)
2 after ODIN flash is complete, ODIN initiates a reboot and installs system update
3 after system update, i rebooted to Download mode and installed TWRP
4 install SuperSU 2.61 via TWRP
5 rebooted device and at the "Galaxy Note 5 boot screen" device rebooted itself
6 got expected "Android is updating message" due to ODIN flash (w/message that Kernel is not SEANDROID enforcing, expected)
7 rebooted to recovery to install Viper4A fix and xposed ver 78, rebooted device and no issues
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2531This 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.616unSU 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.
Previous download counts: 58944; 158506; 59850; 226692578f2fs 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.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.
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.
