[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

niko26

Senior Member
May 5, 2010
252
106
Yes. I've flashed every ota for the last few months (including 8.1) with flashfire. Keeping root is kinda the point of flashfire... The few times that bootloader or radios updated I used fastboot although.
Nexus 6p

Can you tell me the exact steps please? That would be really much appreciated. I wasn't able to install the OTAs and it was a pain in the a**.
 

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,767
40,432
Halifax
GT-i9250
Google Nexus 4
Last edited:

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,767
40,432
Halifax
GT-i9250
Google Nexus 4
Supporting Pixel 2 is going to require AVB v2 signing. The signing utility, avbtool, is Python, so that's a bit trickier for on-device signing.

From further testing by @topjohnwu it seems that AVB v2 signing might not be enforced currently on unlocked Pixel 2 bootloaders, so that's good news... for now at least, since we know Google also likes to change the rules, sometimes month-to-month, like they did on the Pixel with AVB v1. ;)

Regardless, here's some fun I whipped up for anybody semi-savvy wanting to play around with on-device AVB v2 signing.

It's straight up using Python (all credit there to QPython) to run avbtool with a simple little wrapper script I wrote. This is labeled "-arm" because of this Python dependency, which is only built for ARM, but it should/does work on ARM64, and possibly x86 and x86_64 with the libhoudini compatibility layer. I'm not sure if MIPS/64 has a similar compatibility layer, so MIPS devices may be out of luck for now.

Unpack to /data/local/avbtool-arm or anywhere that isn't under /sdcard so that you can set executable permissions to my avbtool script and be able to run it.

Syntax is pretty straightforward, but it's complicated slightly by avbtool wanting the size of the partition so that it can pad the entire partition and place a footer at the end denoting the signature. So:
Code:
./avbtool add_hash_footer --image boot-new.img --partition_size $(wc -c < boot-original.img) --partition_name boot
where boot-new.img is your unsigned, repacked image, and boot-original.img is an untouched signed dump from the target device.

There's an embedded default testkey in avbtool, but I've also thrown in the other rsa testkey .pem files which can be used with some of the avbtool command-line options.

Happy hacking! :cowboy::cool:
 

Attachments

  • avbtool-arm.zip
    7.5 MB · Views: 1,333
Last edited:

Andi17

Senior Member
Mar 23, 2015
715
192
Nürnberg
Hello all,

Sorry for my Bad question, but i read in a thread that chainfire will stop developing of supersu. Is it true or not? I hope not.

Thanks in advanced
 
Hello all, Sorry for my Bad question, but i read in a thread that chainfire will stop developing of supersu. Is it true or not? I hope not. Thanks in advanced
Unfortunately Chainfire has Retired from the SuperSU side of the development as he had announced it on his following G+ post.

https://plus.google.com/+Chainfire/posts/6Sp6t9LxtQZ


~~~~~~~~~~~~~~~
I DO NOT PROVIDE SUPPORT VIA PM UNLESS ASKED/REQUESTED BY MYSELF.
PLEASE KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
 
  • Like
Reactions: Andi17

defens23

Senior Member
Jan 22, 2012
187
19
Hi. just installed the latest November update to my XL.
Powered phone down.
Fastboot boot to twrp.
Flashed SuperSu config for systemless sbin.
Then tried to flash SU 2.82 sr5.
Each time I try to flash it I get an error at the end saying "failed to mount '/system' (device or resource busy).
Couldn't get root
Any ideas?

Flashed SU 2.82 sr3 and got same message at the end but when I hit reboot it did it's thing and I have root again.
 
Last edited:

AP2FTW

Senior Member
Jul 26, 2013
416
114
Mia
Hi. just installed the latest November update to my XL.
Powered phone down.
Fastboot boot to twrp.
Flashed SuperSu config for systemless sbin.
Then tried to flash SU 2.82 sr5.
Each time I try to flash it I get an error at the end saying "failed to mount '/system' (device or resource busy).
Couldn't get root
Any ideas?

Flashed SU 2.82 sr3 and got same message at the end but when I hit reboot it did it's thing and I have root again.
I don't believe SuperSU config is necessary any more...at least I'm pretty sure I read that somewhere and it wasn't listed in the steps I followed to root my XL
 
  • Like
Reactions: defens23

Alxoom33

Senior Member
May 18, 2011
5,184
1,857
New York
www.sack-ip.com
Google Pixel Tablet
Hi. just installed the latest November update to my XL.
Powered phone down.
Fastboot boot to twrp.
Flashed SuperSu config for systemless sbin.
Then tried to flash SU 2.82 sr5.
Each time I try to flash it I get an error at the end saying "failed to mount '/system' (device or resource busy).
Couldn't get root
Any ideas?

Flashed SU 2.82 sr3 and got same message at the end but when I hit reboot it did it's thing and I have root again.
I am not sure the rooting procedure on the Pixel XL. I know on the Pixel 2 XL it is much more complex than just flashing​ the SU 282 SR 5.zip. In fact we don't even have a working TWRP yet. It is just in the Alpha stage. You should probably read some in your device threads.

Sent from my Pixel C using Tapatalk
 
  • Like
Reactions: defens23

jcmm11

Recognized Contributor
Feb 10, 2012
3,589
3,614
Google Pixel 4a 5G
awesome!

flashed it and got an error message that it couldnt mount... but phone is rooted... am i missing something?

also... does latest version of stericson busybox pro work with the latest supersu?

much thanks! :)
I switched from stericson to osm0sis' version, but checking the play store for stericson the latest "What's new" says "Added Busybox 1.27.2, also added support for systemless root within sbin (Oreo support)" so it should work.
 

peterlee928

Senior Member
Oct 16, 2014
950
405
I switched from stericson to osm0sis' version, but checking the play store for stericson the latest "What's new" says "Added Busybox 1.27.2, also added support for systemless root within sbin (Oreo support)" so it should work.
got it. i suspect the issue is with how supersu was flashed. i started by doing a clean install of the nov update. then fastboot boot twrp, then flashed sr5. but got the error message that it didnt mount. any thoughts as to what the issue is here and/or potential solution? much thanks in advance :)

EDIT
so as a point of reference, i flashed sr1 pixelfix on my verizon google pixel xl and stericson busybox withthe october update with no issues (either supersu mounting or busybox).
 
Last edited:

defens23

Senior Member
Jan 22, 2012
187
19
I don't believe SuperSU config is necessary any more...at least I'm pretty sure I read that somewhere and it wasn't listed in the steps I followed to root my XL

Thanks. I use SuperSU config because it's needed for SUhide otherwise I can't use Netflix or Directvnow because they block you from using the services if they detect root.

---------- Post added at 05:14 PM ---------- Previous post was at 05:12 PM ----------

awesome!

flashed it and got an error message that it couldnt mount... but phone is rooted... am i missing something?

also... does latest version of stericson busybox pro work with the latest supersu?

much thanks! :)

Same issue I had. Said mount was busy but root finally worked after a couple of tries.
 

AP2FTW

Senior Member
Jul 26, 2013
416
114
Mia
Thanks. I use SuperSU config because it's needed for SUhide otherwise I can't use Netflix or Directvnow because they block you from using the services if they detect root.

---------- Post added at 05:14 PM ---------- Previous post was at 05:12 PM ----------



Same issue I had. Said mount was busy but root finally worked after a couple of tries.
But I am using suhide to use Android pay and I didn't flash suconfig
 

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.