yashsingh1/xdaforums huggingface dataset:
[SuperSU] RolfFrie:
PIXEL C seems to work

Preliminary root for ODP1 on 5X and 6P:

Rooting works fine on a Pixel C and Titanium, Flashify, BusysBox, EsExplorer, QuickReboot(PhingIT) seem to work, too. :o

FlashFire: Root was found, bout no access :crying:
[SuperSU] suzook:
https://pastebin.com/dQ8KVx7T
[SuperSU] Ibuprophen:
[MENTION=2313936]suzook[/MENTION], HOLY MOLEY BATMAN!!!

That couldn't be uploaded as a txt file?

LMAO!!!

Sent on my Communicator [SCH-I535] from the Bridge of the U.S.S. Enterprise...
[SuperSU] ashyx:
[MENTION=631273]Chainfire[/MENTION] as you can see no boot device listed in recovery mode, No idea why, but this is why the fstab has the partitions defined as block devices instead of by-name.
[SuperSU] ulxerker:
[MENTION=2313936]suzook[/MENTION] and [MENTION=4899305]ashyx[/MENTION] please use HIDE tags in post editor next time to prevent our mouse wheels from breaking - thanks :)
[SuperSU] ashyx:
What are you posting that to me for? I already pointed suzook to pastebin.com to post logs and not here, which he has done, you don't need to repeat it.
[SuperSU] ulxerker:
oh ok, sorry then.
[SuperSU] Chainfire:
I have not heard of this forced encryption before. My S7 at least doesn't suffer from it.

Do you have a few specific examples that suffer from this? Can you point out some exact models that suffer from this with links to pdadb.net ?

How does your modified ZIP work around this issue?

Which exact device model is this? What is the chipset? Can you post those fstab files? ( /*fstab*, /res/*fstab* )
[SuperSU] ashyx:
I have uploaded the FSTAB's from the device in question the Samsung Galaxy S3 SM-T820 - http://pdadb.net/index.php?m=device...-t820_galaxy_tab_s3_9.7_wifi&d=detailed_specs

The others are examples of where the forceencrypt patch in supersu and the no-verity-opt-encyrpt patch doesn't work. This is because both your patch and the patch created by Jcadduono change forceencrypt/forcefdeorfbe to encryptable.

As you can see the FSTAB flag in these devices is already encyrptable=footer

/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_async_commit,errors=panic wait,check,encryptable=footer

The work around to disable forced encryption is to simply remove that flag altogether if it is found. This does have the effect of not being able to re-encrypt later on, but that is easily solved by reflashing the stock boot.img.

We have also found if Supersu is flashed after the boot image patcher then Supersu breaks the edit in the FSTAB as it puts back the encryptable=footer flag, so I have advised people to flash Supersu first then the boot patcher, which has been working succesfully.

There are many, many devices affected by this, pretty much all the A series, the J series and the T series.

Samsung FSTAB

[MENTION=2313936]suzook[/MENTION] has also reported that root is breaking the stock camera.

I think I have come across people reporting this issue on other devices before, but not sure what the fix is, permissions maybe?

Or using a third party app?

Anyway, thanks for taking time to look at this.

.
[SuperSU] Chainfire:
So, if I understand correctly:

- These devices do not come with forceencrypt/forcefdeorfbe out-of-the-box

- They do come with the encryptable=... flag

- If encryptable=... is present, the device is always force encrypted, essentially behaving as if forceencrypt was present.

- So if you format /data in TWRP as ext4 and boot, the device becomes encrypted if this flag is present (?)

Additionally, the am I correct in seeing that the partition names being present is only true in TWRP, but not the case in booted Android ? If I look in the stock recovery fstab, the names are also present there. In other words, isn't this just a TWRP issue?
[SuperSU] ashyx:
Correct.

Are you referring to the issue of SuperSU not finding the boot partition?

In TWRP the partition names are nor present as for some reason there is no bootdevice listed under /dev/block/

Because of this TWRP needs to use paths to the block devices in the fstab to mount the partitions.

However irrespective of that as you can see from the previous recovery log that the no-verity-opt-encrypt patcher finds and patches the boot.img no problem.

Yet SuperSU cannot even though it is clearly mountable by TWRP.
[SuperSU] Chainfire:
(1) Do you know if this is only affecting 7.x firmwares or also 6.x ?

(2) The question was if these partition names are present in fully booted Android...? Because then it is an issue with TWRP itself for this device.

If so that doesn't mean I won't work around it (it won't be the first nor the last time some snag in TWRP needs to be worked around), but it would certainly be beneficial to know which is the case.

(3) What happens if you remove the encryptable flag on an encrypted device? Does it still boot and remain encrypted?
[SuperSU] ashyx:
1. This started with MM firmwares and now showing up it seems on NN firmware.

2. Maybe you're right it could be an issue with TWRP or the kernel/ramdisk itself. Irrespective of that the workaround is to mount by block device rather than having to faff around by trial and error to nail the underlying issue.

The block device is normally defined in the command line. On this kernel it is not, so tracking down how and where the boot device is defined, so TWRP can see it seems like unnecessary strife for something that works perfectly well as it is.

At the end of the day if TWRP can see the boot partition , JC's patch can unpack/repack it why not SuperSU?

3. Removing the flag from a device that is encrypted would render it unbootable as I assume removing the flag means the device doesn't know where to look for the encryption data.

In relation to this point, is it really necessary to remove encryption for root to succeed?

For encrypted devices would it not be possible to create the su.img in /cache first then copy it over to /data at first boot?

I realise this may require a reboot for root to work.
[SuperSU] umair786:
dev what is the difference between SuperSU 2.79 s3 & SuperSU 2.79 s4....as i want to install the most stable one plz let me know...
[SuperSU] Licaon_Kter:
SR4 is only for Android O preview and for those devices mentioned in that post.
[SuperSU] Ch3vr0n:
If you want the latest stable one you're in the wrong thread. This one is clearly marked as [BETA]. Stable version is found here https://xdaforums.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703. Neither SR3 nor SR4 are "stable" releases.
[SuperSU] KaMyKaSii:
Not exactly. It was recommended to install only on these devices, but I am using on MM without problem. Because it has the name "SR4", I hope it contains changes in addition to compatibility with O preview. And I like to keep everything I can up to date :silly:
[SuperSU] Chainfire:
Ok.

Look, I am just asking a simple question: are the partition names present (under /dev/block/platform/..../by-name ) on fully booted Android ?

I really don't understand why it needs to be argued about. Didn't I already state I was going to implement a work-around? I am not asking you to faff around by trial and error to nail the underlying issue. We are not going to try and fix TWRP. Heck, the boot device being passed on the command line or not isn't even related, and even if it was, TWRP itself doesn't care. It's just a simple question to satisfy my curiosity about the issue. I am sorry I asked.

Obviously it could, the script just needs an adjustment. Historically I dislike relying on fstab because fstabs aren't always correct. Keep in mind that TWRP isn't the only installer for the SuperSU ZIP, and patched stock recoveries can and are booted on 'sibling' devices that may be able to boot the same kernels but may not have the same partition layout. Trying to find the boot partition via partition names is vastly more reliable in those scenarios.

That being said, adding a fallback to reading fstab if the boot partition cannot be located by name is an easy fix. I will PM you a link to a test version later.

I thought the same thing. I thought you might have actually tried it and could say from experience. That means I won't have SuperSU do this change automatically, then.

No, it is not necessary at all to remove encryption for root to succeed. These are two completely unrelated issues. The SuperSU installer does it by default, and if there's an issue with that I'd like to know about it, and fix it if possible. In this case, it seems not possible to auto-fix it because it will prevent encrypted users from booting, and thus I will not. I'll probably create a flag you can set to force this behavior manually though.

If the installing environment (TWRP, other custom recoveries, patched stock recoveries, app-based installers, etc) doesn't support decrypting /data, installing to /cache and copying to /data during first boot is indeed exactly what happens, but this is again a different issue.
[SuperSU] ashyx:
I think we've took a wrong turn here? It wasn't my intention to come across argumentative. I thought I'd already answered that the partitions were visible by name when booting to Android, as indeed they are to answer that question.

Only in recovery are they not.

I know I've mentioned unrelated stuff to the issue in hand.

It's just feedback.

Many people have reported being unable to gain root until removing encryption from /data then installing supersu.

I agree not a great idea to auto patch this encryption flag issue with supersu as it will cause encrypted users failure to boot.

Making it a manual option is the best way, let the user decide.

Most only want to remove encryption so twrp can mount /data, to make backups and fix the seemingly reported issue of not being able to gain root if the partition is encrypted.

It's certainly your call if you want to fix up supersu to use the fstab as fallback, something I thought would already be present, but seems not.

This may just be an isolated case for this device, who knows?

Looking at your script I see it searches for the by-name partitions.

As a work around I have modified the init.rc of TWRP to Symlink the block devices to the named partitions under /dev/block/by-name

If I'm reading your script correctly this should mean it should be able to locate the /boot partition.

My tester hasn't got back to me yet if it works, but don't see why it shouldn't.

(EDIT: confirmed working.)

Anyway your efforts are greatly appreciated and I hold you in the highest regard as far as the development community goes.

Peace.
[SuperSU] Chainfire:
I just PM'd you a link to a SuperSU version that falls back to fstab based detection if it cannot detect the boot partition by name. Please let me know if that works.

Additionally, REMOVEENCRYPTABLE flag has been implemented, and can be activated so:

echo "REMOVEENCRYPTABLE=true">>/cache/.supersu

(or /data/.supersu if that is available). This should remove the 'encryptable=' flag from the fstab and allow new Samsung devices to run unencrypted.

If you have example cases for this, please direct them to me. It is designed to work regardless of /data, but it's always possible there's an issue with that on some devices, if so I would like to know.

CF-Auto-Root doesn't even attempt to mount /data. In my personal experience it only doesn't work if TWRP itself cannot cope without mounted /data (on some devices it can, on some devices it can't, not sure what the difference there is). But again, if there are other cases, I'd like to know about them.
[SuperSU] ashyx:
I have forwarded the test build to my tester. So await a report on the results.

You will have to bear with me regarding reported cases of where SuperSU fails to root on encrypted devices.

So many threads to look over and pick out the ones that aren't just user error.

Maybe [MENTION=2313936]suzook[/MENTION] would be prepared to put his device back to stock with encryption and test this out?

Great news on the flag.

Thanks for all your time with this.
[SuperSU] umair786:
Today I updated my redmi note 3 8.1 to 8.2( latest) and after flashing recovery rom I flashed supersu 7.9 s3 and rebooted the system upon booting to my surprise there is no supersu app in my phone... What should I do to get it back please help...
[SuperSU] iXaidyiu:
Download SuperSU app by Chainfire on Google Play.
[SuperSU] umair786:
Installed from play store and now the app notifying me there is no supersu binary installed
[SuperSU] Bakica:
Check under settings...
[SuperSU] Chainfire:
NOTICE

The SuperSU application in the Play Store has been transferred from my developer account to CCMT's developer account. As such, it no longer shows the Chainfire name as publisher.
[SuperSU] umair786:
No supersu even under settings
[SuperSU] veez21:
But the development is still with you right? :crying:
[SuperSU] oldman_58:
Nexus 7 2012/3g Tilapia getting the following:

04-02 19:29:55.468 26990 26990 W am : type=1400 audit(0.0:1088): avc: denied { getattr } for path="/system/bin/app_process32" dev=mmcblk0p3 ino=120 scontext=u:r:rild:s0 tcontext=u:object_r:zygote_exec:s0 tclass=file permissive=0

I am losing 3G connectivity until I reboot, could SR3-SuperSU-v2.79-SR3-20170114223742 be a cause of the issue?
[SuperSU] umair786:
Anyone help me please consider my above posts
[SuperSU] ktmom:
If I understand your post, you're on O? Have you tried sr4? I'm not sure if that is the right one for your device, look for the release post for it in this thread. I'd save the twrp log after flashing and see what's happening.
[SuperSU] umair786:
I tried flashing twrps inbuilt SuperSU and later updated to latest SuperSU using reinstall option under setting then rebooted and it worked
[SuperSU] suzook:
I can try flashing back stock encrypted and try out the new SuperSU sometime this week, and post results.
[SuperSU] peterlee928:
hi yall

is sr4 still incompatible with pixel xl?

just checking b4 i install 7.1.2

much thx :)
[SuperSU] dev70194:
Where would I get the download link for SuperSU for 7.1.2?
[SuperSU] Badger50:
A simple Google search would have yielded this!

http://www.apkmirror.com/apk/chainf...elease/supersu-2-79-sr4-android-apk-download/
[SuperSU] dev70194:
My bad I see it now. Thanks anyways.
[SuperSU] Ja_som:
For 7.1.2 you can use SR3 from the first post.
[SuperSU] jandia7381:
Yes, i'm using it on NOS 7.1.2 without a probs :cool:
[SuperSU] Wandeta:
7.1.1----supersu systemmode phone bootloops.
[SuperSU] spainter:
I wrote the fix you need and left it sitting on my desk next to the info about your phone etc.
[SuperSU] Ch3vr0n:
[MENTION=631273]Chainfire[/MENTION] or anyone else for that matter. I need to send my 6p in for a repair to the USB port (hardly connects, difficult to charge). So I ordered myself an inexpensive 'general mobile ''android one GM5'' '. Anyone know if SR3 roots it with system or systemless mode and if FlashFire works?

Verstuurd vanaf mijn Nexus 6P met Tapatalk
[SuperSU] Ibuprophen:
Here are some threads that should help you get a start on this.

https://xdaforums.com/gm-5-plus/help/gm-5-plus-root-problem-t3395280

https://xdaforums.com/gm-5-plus/help/access-problem-to-file-t3412269

https://xdaforums.com/crossdevice-d...l/mobile-iq-ii-mobile-4g-how-to-root-t3173802

Sent on my Communicator [SCH-I535] from the Bridge of the U.S.S. Enterprise...
[SuperSU] Ch3vr0n:
Thanks for the effort 1st & 2nd thread are for the PLUS version, mine will be the non-plus. I found those too. 3rd isn't even relevant. That's the previous generation. Then i also need to find out where/how to get the stock rom (factory) images. I remember seeing some listed on the nexus page at one point but they're not there anymore.
[SuperSU] Ibuprophen:
Why not try posting that question on the plus forums?

Maybe someone will help you out with some guidance on where to find one.

Sent on my Communicator [SCH-I535] from the Bridge of the U.S.S. Enterprise...
[SuperSU] Ch3vr0n:
Cause then it'll show up permanently in my tapatalk topics ^^ and i only want those to show that i actively visit / Participate in. (stupid reason i know, but thats just me)
[SuperSU] abhipanthi:
Thank you bro [MENTION=631273]Chainfire[/MENTION]

Working perfectly on my Redmi Note 4 Snapdragon, Using AEx v4.0 based on AOSP having android version 7.1.1...
[SuperSU] habylab:
Do people have better experiences with SR3 or the last Stable? I see conflicted opinions everywhere... Can't tell myself. 7.1.1.
[SuperSU] Ibuprophen:
That's because those members doesn't read and compare both the threads OP's first.

Then they should be able to understand the differences.

Sent on my Communicator [SCH-I535] from the Bridge of the U.S.S. Enterprise...
[SuperSU] ZRK_NanDRD:
I bought my lil bro a Vodacom Power Tab 10 & rooted it using King root as there isn't a Custom Recovery or CF Auto Root for the device. Thereafter I switched from king root to supersu SR3, did the process well & the binaries were successfully updated then I rebooted without checking if the King root apk was still installed (app drawer icon) or not then the device went into a bootloop. I formatted the device with it's stock recovery then cleared the EMMC Data from the device as I noticed that the firmware is a clone from that of the Alcatel Pixi3 (google search research) & it's best to clear the EMMC data, but still it's stuck in a bootloop, I'm considering sending it in for in-shop repair/firmware restore. So I wanted to know if when I get it back from repair, should I re-do the steps, but this time un-install the king root app or install the stable supersu instead of this beta
[SuperSU] habylab:
Stable it is.

Wish the man in your profile pic was around...!
[SuperSU] Ibuprophen:
He's working on a Netflix movie now LOL!

Sent on my Communicator [SCH-I535] from the Bridge of the U.S.S. Enterprise...
[SuperSU] andrew2432:
He he props for enterprise crew for advocating a second chance :)

Speaking of, does Netflix work on rooted phones? I have everything hidden on the phone I have Netflix on

King root leaves files left over that are very difficult to remove if I'm not mistaken. This could be causing you some problems. My g2 needed flashed to stock after using kr
[SuperSU] casouzaj:
Netflix works in my Sony Xperia Z3C phone with unlocked bootloader, rooted by Magisk. It is not even in Magisk hide's list.
[SuperSU] ZRK_NanDRD:
So in short, I shouldn't redo the procedure & remain using king root....
[SuperSU] Strephon Alkhalikoi:
[MENTION=7217322]ZRK_NanDRD[/MENTION]: Sure, if you want malware.
[SuperSU] bdwilk:
Well, many people will advise you not to use king root at all, but if that's what you need to do then there is a paid app called Super-Sume Pro It's sole purpose is to remove all of king root and it's binaries and install SuperSU instead.

https://play.google.com/store/apps/details?id=darkslide.com.supersumepro
[SuperSU] joint.striker:
Thank you, you're a life saver!

I had recently updated my firmware to Lollipop and when I installed SuperSU, via TWRP, the phone started to optimize ALL apps at boot, EVERY TIME the phone was rebooted - it would take 25 minutes per boot.

I took me ages before I figured that the issue was caused by SuperSU, but the curious thing is that it only happens if you do the final install through TWRP.

The first time I booted into recovery TWRP asked if wanted to install SuperSU, and yeah I wanted to so I accepted and it booted normally. The problem started when I first opened SuperSU (pre-installed) and it asked me to update the binaries, in which case I could choose between "normal" or via recovery boot (TWRP/CWM; using recovery was recommended by SuperSU). I chose via recovery, it started downloading binaries directly and booted into TWRP and ran the install script. After this, the phone was completely garbage, as mentioned earlier, optimizing 150+ apps at every boot.

I was unable to unroot it using SuperSU's own "unroot" feature and any other trick to properly uninstall this crap failed, that is until I found your wonderful script :victory:

I'm not sure what the problem actually is and if it is related to any unstable SuperSU version that might have been downloaded or TWRP's method was the problem, I just know that installing the normal way without going through recovery was the key to not have to wait 25 minutes at every boot. I'd like to point to this thread which I also read when I was trying to confirm my issue: http://android.stackexchange.com/a/170982

Thanks again!
[SuperSU] Rush94:
Facing several issues trying to edit a file in a root folder tried super su 2.79 stable as well as sr 2.79rc3 the root folder is not at all opening even after grating root access. It keeps loading and keeps notifying me the root access is granted to the root explorer also tried solid explorer no luck I think systemless versions aren't stable for my device can some one suggest me a non systemless super su which support 7.1.1 with the April security patch !

Thanks in advance
[SuperSU] ZRK_NanDRD:
Malware* from SuperSu or King root?

Cos none of the 2 is regarded as Malware from my understanding.

Replacing King root with SuperSu using SuMe is what I did & the procedure succeeded including the updating the binaries then I pressed Reboot after binary update & the device went into a bootloop.
[SuperSU] Strephon Alkhalikoi:
Kingoroot. The original is supposedly safe, but it has been cloned endlessly, and the clones have been known to add malware to both device and PC. Thus, it's generally a bad idea to use Kingoroot.
[SuperSU] ashyx:
The issue is this. Anything android 6 and onwards (5.1.1 if Samsung) requires a patched boot image due to selinux policies.

SuperSUME does not patch the boot image as required when converting to SuperSU leading to a bootloop.

SuperSU does this automatically if installed via the zip. However this is not possible on bootloader locked devices or if Knox is required to remain untripped.

The only other option is a permissive kernel, not something that usually comes as stock.
[SuperSU] ZRK_NanDRD:
I download King Root from XDA only....so in that case I'm safe:good:
[SuperSU] Strephon Alkhalikoi:
Safe? Probably. But you could have saved yourself a lot of grief had you done some research before messing around with the phone and taking the easy way out.
[SuperSU] ktmom:
Don't know your device, but it sounds like an old version of TWRP. Since lollipop, using TWRP's build in root causes boot loops.
[SuperSU] RandomPooka:
TWRP doesn't even offer to root anymore, does it? I thought that got removed AGES ago
[SuperSU] joint.striker:
Device is bq Aquaris E4.5

The version of TWRP is quite recent in fact: TWRP 3.1.0-0
[SuperSU] andrew2432:
If you're unrooted I think it will still ask to install su in system! And yeah I've heard kr has been a gateway to nefarious activity with users devices lately, a bummer when its one of the only way to root your devices

---------- Post added at 12:31 AM ---------- Previous post was at 12:27 AM ----------

I used to use es file explorer but heard negative things like or recently haha and you can flash this as system, adb shell...someone will surely fix this code I'm about to butcher but here it goes!!

echo "systemless=false" >/data/.SuperSU

I will look for the actual code I have it somewhere, I'm missing some <> and who knows what else :p
[SuperSU] ktmom:
There's always the system version of SuperSU.
[SuperSU] Strephon Alkhalikoi:
Check the link in my signature.
[SuperSU] andrew2432:
Woahhhhh updated!!!!

Dude that was awesome
[SuperSU] Eugene729:
Hi guys, is the link on the first page and post of the thread the systemless su root method? Sorry amd thanks.
[SuperSU] Badger50:
Yes sir. The second link in the first post is the most used one currently.

http://download.chainfire.eu/1021/SuperSU/SR3-SuperSU-v2.79-SR3-20170114223742.zip
[SuperSU] .::Alien::.:
Not working on my Samsung Note 5 (SM-N9208) Android 7.0, Struck on creating image while flashing through TWRP.
[SuperSU] radasx:
I testing this, and i think that is the best of best ;)
[SuperSU] KyeWalker:
Does this pass safety net on s7 edge latest nougat?
[SuperSU] Ch3vr0n:
No, and as stated by chainfire in op the goal of SuperSU is root and he has no intention of making it pass SN. Any passing is a bug in SN and not a feature of SuperSU.

Verstuurd vanaf mijn Nexus 6P met Tapatalk
[SuperSU] Yaoshi_2000:
This is a known bug. Take a look at post 9167 in this thread.