[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

The Analog Kid

Senior Member
Dec 5, 2013
841
166
He has an XDA thread.

Alright. Finally used @osm0sis unSU.zip, reverted back to stock kernel (was on @flar2 ElementalX), cleared caches, rebooted back to TWRP, flashed ElementalX back again, flashed v2.82-SR5 once more and rebooted... just to find a tiny little mess. Although a couple apps normally requested root permission, "root checker" was telling me no root was present, as well as most other root apps. Weird. Rebooted to no avail and apps started to close in sequence. Decided to reflash SuperSu once again, rebooted and now things are working as expected, SuperSu included. As to what caused the initial no log, SuperSu crashing issue, my guess is that it was some clean up I did with SDMaid, probably getting rid inadvertently of some useful thing related to SuperSu. Not sure... Whatever, thanks for the suggestion.

Sent from my Moto G4 Plus using XDA Labs
 
Last edited:

mwilky

Recognized Developer
Feb 21, 2011
6,588
16,441
Manchester
Google Pixel 6 Pro
Google Pixel 6
Seems like latest sepolicy blocks dex2oat accessing data/dalvik-cache/arm and data/dalvik-cache/arm64 folders. I've tried

/sbin/supolicy --live \
"allow dex2oat dalvikcache_data_file file { write read execute }" \
"allow dex2oat dalvikcache_data_file dir { write read execute }" \
"allow dex2oat dalvikcache_data_file dir create_dir_perms" \
"allow dex2oat dalvikcache_data_file file create_file_perms"

And a few others to no avail, anyone know if it is possible?
 

Eures

Senior Member
Sep 2, 2012
54
3
Hello, I have a question: is the SuperSU-v2.82-20170528234214-TEST-1.zip (for Xperia users) rolled out in the SR5-SuperSU-v2.82-SR5-20171001224502.zip? In other words, can it be said that the former is obsolete?...
 

SlimSnoopOS

Senior Member
Jan 29, 2011
8,052
3,348
Hello, I have a question: is the SuperSU-v2.82-20170528234214-TEST-1.zip (for Xperia users) rolled out in the SR5-SuperSU-v2.82-SR5-20171001224502.zip? In other words, can it be said that the former is obsolete?...
Depends but likely yes. Whenever Chainfire would release test zips for specific issues, if it fixed issues then he'd incorporate that into his next SR# zip. Try SuperSU beta SR5 just know that there's no further support if anything goes awry.

Sent from my Nexus 5X using Tapatalk
 
G

GetOffMyLawn&!+¢#{$

Guest
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.
I just thought some of you might like to see this.
Edit: I almost forgot, I did give credit and linked the post.
Sent from my Moto E (4) Plus using XDA Labs
 

Attachments

  • Screenshot_20180108-175439.png
    Screenshot_20180108-175439.png
    170.5 KB · Views: 1,558
  • Screenshot_20180108-175451.png
    Screenshot_20180108-175451.png
    98.2 KB · Views: 1,550
  • Screenshot_20180110-132735.png
    Screenshot_20180110-132735.png
    107 KB · Views: 1,115
Last edited:

Razor10707

Senior Member
May 23, 2017
545
92
Budapest
Hey sorry this Will most likely sound nooby but I didn't used supersu alot till Now

No matter which version I choose either Way doesnt work if I used a version 2.80 or before it fails in the flashing procedure at patching sepolicy failure aborting

Or if I use v2.82 sr2 or sr5 they both flash but then ask for binary update which fails and even after relfashing in twrp still nothing fixes it

My device is a p9 liter (vns-l21c432)
Running Elite rom 7.3

TIA.
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
@Razor10707, I take it you tried 2.80 then tried newer versions? How did you remove the previous flash before flashing the next version?

I'd first do a nandroid backup, then dirty flash your ROM again to get everything back to a known condition. Boot first to make sure everything is working then try SR5 and see if it flashes correctly.



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

Razor10707

Senior Member
May 23, 2017
545
92
Budapest
@Razor10707, I take it you tried 2.80 then tried newer versions? How did you remove the previous flash before flashing the next version?

I'd first do a nandroid backup, then dirty flash your ROM again to get everything back to a known condition. Boot first to make sure everything is working then try SR5 and see if it flashes correctly.



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

Yes I tried older versions but as I said other Than 2.82 all fails at flashing in recovery only 2.82 gets trough that but it fails at binary update
 

deloj

Senior Member
Oct 17, 2017
486
28
After I dirty flashed Nougat and Odined TWRP, I still cant get root. I Odined SuperSu but after that I got this message: "Verification Failed, Unable to restart your device. The Integrity verification has failed. You need to reset your device to factory default settings. This will erase all your data."

I then dirty flashed Nougat and everything is ok. But I still dont have root. I used this SuperSu: SR5-SuperSU-v2.82-SR5-20171001224502.

What do you suggest to get root?

.
 

Badger50

Senior Moderator / Moderator Committee
Staff member
After I dirty flashed Nougat and Odined TWRP, I still cant get root. I Odined SuperSu but after that I got this message: "Verification Failed, Unable to restart your device. The Integrity verification has failed. You need to reset your device to factory default settings. This will erase all your data."

I then dirty flashed Nougat and everything is ok. But I still dont have root. I used this SuperSu: SR5-SuperSU-v2.82-SR5-20171001224502.

What do you suggest to get root?

.

Since SU is no longer being activity developed at this time, you might wanna try this.

https://xdaforums.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
 

Razor10707

Senior Member
May 23, 2017
545
92
Budapest
@Razor10707, I take it you tried 2.80 then tried newer versions? How did you remove the previous flash before flashing the next version?

I'd first do a nandroid backup, then dirty flash your ROM again to get everything back to a known condition. Boot first to make sure everything is working then try SR5 and see if it flashes correctly.



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

Thanks for your help i kinda fixed it now i have root only thing doesn't work is Ksettings but I'm gonna deal with that later
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
After I dirty flashed Nougat and Odined TWRP, I still cant get root. I Odined SuperSu but after that I got this message: "Verification Failed, Unable to restart your device. The Integrity verification has failed. You need to reset your device to factory default settings. This will erase all your data."

I then dirty flashed Nougat and everything is ok. But I still dont have root. I used this SuperSu: SR5-SuperSU-v2.82-SR5-20171001224502.

What do you suggest to get root?

.
What jumps out at me is that you used odin to flash SuperSu. I stay away from Samsung devices but even for Samsung I don't think using odin is right. SuperSU gets flashed in twrp.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
 
  • Like
Reactions: Didgeridoohan

saspo59

Senior Member
Aug 11, 2012
562
240
Hi ,i am on 1+3t Nos 8.1 ,was running magisk till now i wish to try su ,i unindtalled magisk and installed SR5-SuperSU-v2.82-SR5-20171001224502.zip
I am rooted cose all apps that need root work and ver root app says all ok but i don't see any kind of su app in app drow do i need to install another app tu see something
Thanks

Sent from my ONEPLUS A3010 using Tapatalk
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
Hi ,i am on 1+3t Nos 8.1 ,was running magisk till now i wish to try su ,i unindtalled magisk and installed SR5-SuperSU-v2.82-SR5-20171001224502.zip
I am rooted cose all apps that need root work and ver root app says all ok but i don't see any kind of su app in app drow do i need to install another app tu see something
Thanks

Sent from my ONEPLUS A3010 using Tapatalk
How did you uninstall Magisk? It's often a good idea to dirty flash your ROM after removing systemless root.

Have you checked in your settings for root management? Some ROMs don't show the app in the app drawer but rather put it in settings.

In the SuperSu zip file, in the common folder is a copy of the apk. You could try installing that.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
 
  • Like
Reactions: saspo59

saspo59

Senior Member
Aug 11, 2012
562
240
How did you uninstall Magisk? It's often a good idea to dirty flash your ROM after removing systemless root.

Have you checked in your settings for root management? Some ROMs don't show the app in the app drawer but rather put it in settings.

In the SuperSu zip file, in the common folder is a copy of the apk. You could try installing that.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Thanks for repaying now all ok with su app ,one more question why titanium backup app says there is no root and it dosnt open

Sent from my ONEPLUS A3010 using Tapatalk
 

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
Thanks for repaying now all ok with su app ,one more question why titanium backup app says there is no root and it dosnt open

Sent from my ONEPLUS A3010 using Tapatalk
Double check that TiBu was granted root access. If it's listed as denied, then it won't prompt again, TiBu just reports no root access.

An app can get listed as denied if it requests root and the request times out. While you were having trouble with the SuperSu app, if you opened TiBu, then that's when the request timed out.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
 
  • Like
Reactions: saspo59

saspo59

Senior Member
Aug 11, 2012
562
240
Double check that TiBu was granted root access. If it's listed as denied, then it won't prompt again, TiBu just reports no root access.

An app can get listed as denied if it requests root and the request times out. While you were having trouble with the SuperSu app, if you opened TiBu, then that's when the request timed out.

"Good judgment comes from experience, and a lot of that comes from bad judgment." - Will Rogers
Thanks,its not listed and wasn't denide just directly says it not detect root did i have to instal it as system app there is an option for that in setting

Sent from my ONEPLUS A3010 using 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.