[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

Sr. Zé Alguém

Senior Member
Nov 3, 2016
789
819
Then you have an extra reason to write with good grammar, because any good mobile keyboard is able to properly correct grammar and typos automatically -- this doesn't happen with a real keyboard. Unless you want to give a bad impression -- as you have already achived, I guess.

Want to learn something in your life? Start by listening other's suggestions. Repeating your errors is not the way to go. Bye.
[/end-ot]
 
Last edited:

edward566

Member
Nov 4, 2010
6
0
Google Pixel 7 Pro
Attached test version - for the Pixel (XL) only - should fix both remounting /system as well as the TWRP/recovery ramdump issue. No other issues have been fixed. Let me know if it works right for you.

I suggest flashing back the stock boot image before flashing (TWRP and) this.
Perfect. Used Flashfire to flash SuperSU-2.82-SR1-20170615211546-PixelFix.zip onto NKG47L, both remounting /system as well as the TWRP/recovery ramdump issue has been fixed.
 

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
Root is only a security hole if you see it from the perspective of Google. Not having root and not having control over my data is a security hole from my perspective as a device owner.
So much this.

When you don't have control over your own security, you really can't even gauge how secure your device really is, yeah qcom and Google totes have my security in their hands, pretty arrogant for a non security based company. I still get "YOU'RE A WINNER!" pop ups in chrome mobile, and these guys control my security, I'm totes secure (sarcasm). It's like not being able to opt out of McAfee when installing flash in windows, then it running with admin privileges.

I'm more worried about chimera, gms, qcoms services, is etc.

When I helped substratum go rootless, I was majorly disappointed in myself.
It was the single hugest bummer of my life.

(late reply, I know)

/end off-topic lol

(also half of the above is meant to be humorous, trying to see if we can actually get a cf "lol", dude never laughs)

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

guitar1238751

Senior Member
Mar 25, 2015
381
1,630
New York City
So much this.

When you don't have control over your own security, you really can't even gauge how secure your device really is, yeah qcom and Google totes have my security in their hands, pretty arrogant...
Lol, well said man. I agree with you. It's one of the main reasons I run arch instead windows. First thing I always do across all my devices is root.
 
  • Like
Reactions: Surge1223

AJ

Senior Member
Aug 8, 2012
344
67
a very weird problem on the Pixel :

root checker says i have root , but all rooted apps don't work properly ( Adaway , emojiswitcher )
 

DEVILOPS 007

Senior Member
May 24, 2016
3,866
1,668
Colchester
Anyone else having problems getting AdAway to install hosts in systemless mode with this release?
If you're using SuperSu then why use systemless adaway? Isn't magisk what you would want if you want to leave the system alone? If you wish to use adaway systemlessly with supersu then go to the adaway thread and search systemless and you should find a link to a mod that makes adaway work systemlessly with supersu.

Edit: Here is the link to systemless hosts for adaway to work systemlessly with supersu for you.
https://www.androidfilehost.com/?fid=24438995911977059
 
Last edited:
  • Like
Reactions: bigron77

ktmom

Retired Forum Moderator
Apr 22, 2015
5,176
3,387
Deep Space Station K7
Anyone else having problems getting AdAway to install hosts in systemless mode with this release?


If you're using SuperSu then why use systemless adaway? Isn't magisk what you would want if you want to leave the system alone? If you wish to use adaway systemlessly with supersu then go to the adaway thread and search systemless and you should find a link to a mod that makes adaway work systemlessly with supersu.

Edit: Here is the link to systemless hosts for adaway to work systemlessly with supersu for you.
https://www.androidfilehost.com/?fid=24438995911977059
You do *NOT* need this additional script for systemless Adaway anymore. Not for a very long time. It's built into the app. Just use the newest release and check the systemless option in Adaway settings (for supersu , different method for Magisk).
@ecsnead69, if you still need help, the Adaway thread is pretty active.
 
  • Like
Reactions: Sh0X31 and bigron77

j1gga84

Senior Member
Jun 21, 2012
4,620
2,730
Bremen
www.android-hilfe.de
@Chainfire
Okay I had the same strange behaviour on my Galaxy S5 (klte) than on my Galaxy Tab S (T805) when I flashed N (official ResurrectionRemix 5.8.3).
I flashed SuperSU 2.82 SR1 in the recovery because latest RR build comes without root.
Now the external SD is not visible and accessible via file browsers and I get a message about the external SD in the status bar.
I removed SuperSU inside the app, rebooted to recovery and installed 2.82 final, now the external SD is visible and accessible without any issues and the message about the external SD does not appear.
I don't know it you can reproduce this behavior.

Regards

Gesendet von meinem SM-G900F mit Tapatalk
 
@Chainfire
Okay I had the same strange behaviour on my Galaxy S5 (klte) than on my Galaxy Tab S (T805) when I flashed N (official ResurrectionRemix 5.8.3).
I flashed SuperSU 2.82 SR1 in the recovery because latest RR build comes without root. Now the external SD is not visible and accessible via file browsers and I get a message about the external SD in the status bar. I removed SuperSU inside the app, rebooted to recovery and installed 2.82 final, now the external SD is visible and accessible without any issues and the message about the external SD does not appear. I don't know it you can reproduce this behavior. Regards, Gesendet von meinem SM-G900F mit Tapatalk
Are you referring to the Adoptable Storage Notification (example image attached)?


***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise...
 

Attachments

  • 1497893276335.jpg
    1497893276335.jpg
    67.8 KB · Views: 895

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,856
www.chainfire.eu
(also half of the above is meant to be humorous, trying to see if we can actually get a cf "lol", dude never laughs)

Nonsense, I was mildly amused by something just last week.

If you're using SuperSu then why use systemless adaway? Isn't magisk what you would want if you want to leave the system alone? If you wish to use adaway systemlessly with supersu then go to the adaway thread and search systemless and you should find a link to a mod that makes adaway work systemlessly with supersu.

Gah, the misinformation that has been going on for ages. SuperSU is systemless itself, and includes components designed to allow developers to make systemless mods. Very few devs actually made use of that, but Systemless Xposed and Magisk actually started as exactly such mods. There have been systemless AdAway versions for a long time using that system. In fact, the code to make AdAway systemless on SuperSU was a one-liner.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer
Oct 2, 2007
11,452
87,856
www.chainfire.eu
@Chainfire
Okay I had the same strange behaviour on my Galaxy S5 (klte) than on my Galaxy Tab S (T805) when I flashed N (official ResurrectionRemix 5.8.3).
I flashed SuperSU 2.82 SR1 in the recovery because latest RR build comes without root.
Now the external SD is not visible and accessible via file browsers and I get a message about the external SD in the status bar.
I removed SuperSU inside the app, rebooted to recovery and installed 2.82 final, now the external SD is visible and accessible without any issues and the message about the external SD does not appear.
I don't know it you can reproduce this behavior.

Unfortunately I cannot reproduce this.

I flashed NN 5.8.3 latest nightly on my S5/klte and tested with and without SuperSU v2.82 SR1 both, with SD card both in adoptable storage and portable storage mode, and did not run into any issues. There's a missing component to reproducing this.

Does the issue go away if you flash SR1 and disable the "mount namespace separation" option in SuperSU settings (and reboot) ?
 
  • Like
Reactions: *ReZa*

jerryasher

Senior Member
Aug 30, 2010
55
4
On Google+, Chainfire writes:

Android 5.1 and older
A small number of users have reported dalvik-cache rebuilds on every boot on 5.1 with v2.82. We have not been able to reproduce this on our 5.x devices. If you're seeing this issue, please come to the BETA thread (linked below) and help us figure out the problem.

So yes, I have a Moto E 2nd Generation 2015 running a stock rooted rom that has been experiencing the Dalvik Cache rebuild with every reboot.

SuperSU reports it is v.282

Has there been a fix for that posted yet or what can I do to help get that fix made?
 
  • Like
Reactions: IronTechmonkey

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.