[SuperSU][System-Mode][2.82 SR5]
- Thread starter mauam
- Start date
On Oreo, you need systemless root. It's just the way root is installed, it doesn't change what your access is. Systemless was developed back in Lollipop days to overcome changes Google made in Android.
If you do use Magisk instead of the defunct SuperSu, you could make build.prop changes "systemlessly" [emoji6]. The advantage would be that you would still be able to take OTAs, assuming that's an option for your device.
i've almost tried everything to system root but always failed.. as u said i can't system root on Oreo.. I think one thing can system root my phone is a custom ROM .. but I prefer rooted stock ROM
I'm missing why you're so focused on a system root. Could you explain what you're thinking?i've almost tried everything to system root but always failed.. as u said i can't system root on Oreo.. I think one thing can system root my phone is a custom ROM .. but I prefer rooted stock ROM
i think that system root is kinda useful for me than systemless bcz easily and directly u can use root apps.. like root uninstaller to uninstall system apps.. I tried Debloater + busybox with Magisk to uninstall system apps but it seems like it's just hiding them lol when I enabled Magisk core Only Mode all the uninstalled system apps came back after I restarted my phone lol it's just a fake uninstalling.
That's a Magisk anomaly that has nothing to so with system vs systemless. There are no inherent limitations w/systemless root for the tasks you are describing.
okay let's say that's magisk's problem.. you're saying that I can uninstall system apps with systemless root, so prove it or let me try an app or something lets me uninstall sys apps !
Let me do a little recap of systemless root. While this is OT for this thread, the thread is kinda dead anyway [emoji56]
All systemless root means is the root "exploit" is installed into the boot partition (boot.img also called the kernel). BTW, that's different than the bootloader.
In pre-Lollipop days, there was no problem putting the root exploit into the system partition. Then, starting with lollipop, Google started implementing restrictions that made inserting root into the system partition unworkable. By Marshmallow, the only way to root was by using the boot partition. This is called "system-less" root. It could have been called "boot-root" [emoji16], but systemless is the name given.
Now, just because root is installed into the boot.img (and sometimes elsewhere on modern devices), doesn't mean you can't go in and mount the system partition and delete folders/files if you want. (There's an exception to this that I'll note later, and you device doesn't fall into that exception).
There are reasons that Magisk modules use a "system mask" instead of just modifying the system partition directly. For one, the device will no longer be able to accept OTA updates because once the system partition is mounted to be able to write to it, the checksum for the partition will change and the OTA will fail. Just mounting it with write permissions will break OTA, even if you haven't changed anything.
Another problem is many apps use safetynet and CTS to verify that the device is not modified. These are additional checks done by the software to reassure apps (Google Pay, banking apps, Netflix, etc) that the device is secure. By using a "system mask", Magisk modules can make "changes" to the system partition, without actually writing, or even mounting the system partition.
If you used a systemless debloater module in Magisk, the module writes a empty file over the debloated APK's path inside of the "system mask". This effectively removes the APK from being installed during the boot process. It does not, however, actually remove the APK, because to do that, system would have to be mounted and the world will end. The debloat module has to stay installed, because without it, the empty file hiding the actual APK gets removed and the app reappears.
Apps like Adaway that modify the /etc/hosts file do that systemless-ly also. With the systemless host module enabled in Magisk, the new hosts file is mounted at boot time over top of the original hosts file. Again, without ever actually touching the system partition.
If you don't care about all of these consequences, and for some reason are dead set on reclaiming the small amount of space the system apps use, then just use a root explorer or terminal and mount system then remove the offending APKs.
The exception I noted above is what is being enforced with Android 10 (Q). System is now mounted at / That may not make much sense if your not particularly familiar with Linux systems, but the end result is, as devices age out, and what's left are A/B partition devices shipped with Pie or newer, systemless mods will be the only way forward. The "system" partition just can not be mounted.
Last edited:
Thank you so much for your taking some of your time explaining me all of that.. I knew the principle of systemless root and why it exists... my device (S7) probably will not get OTAs in the future and I if it does I don't care about OTAs lol .. I said I prefer system root bcz u can easily and freely use apps that need mounted /system.. and i'm also talking about effectiveness I want to uninstall system apps some space I don't wanna hide em if I do I will just disable them or hide em lol.. so what's the point of using Debloater with Magisk if it just hiding the system apps ?
---------- Post added at 03:20 AM ---------- Previous post was at 03:17 AM ----------
lol I love u, specially when u said grasshopper <3
---------- Post added at 03:41 AM ---------- Previous post was at 03:20 AM ----------
btw I used root explorer to uninstall system apps. dunno why regular root uninstallers can't mount system to do it lul.
That's not entirely true. It has more to do with SElinux Enforce vs Permissive in some cases. On my Moto G5s Plus the Oreo ROMs I use are permissive by default. I have system mode SU on a few of them (I multiboot). Even on other devices running older Android, Marshmallow and Nougat f.i, system mode will not work with Enforce but usually works with Permissive.
Of course sometimes a ROM's security setup will cause a ROM not to boot with SU system mode regardless of SELinux status.
Essential PH-1, /e/OS 0.7-n ROM, microG (NoGapps), XDA Legacy
---------- Post added at 07:51 ---------- Previous post was at 07:29 ----------
I have about five devices, three of those are multibooters. So I literally run over a dozen ROMs (silly, I know). KitKat thru Oreo, all with SuperSU or Lineage SU. What you say above has nothing to do with system vs systemless (mentioned already by others). There are no restrictions or differences between systemless and system (in SuperSU) with regards to what you want to do. I can do whatever or manipulate /system apps regardless.
I don't do Pie so don't know if it's more restrictive, even with root. I also don't use/like/want Magisk so can't comment on that.
Essential PH-1, /e/OS 0.7-n ROM, microG (NoGapps), XDA Legacy
What you say has truth, but only as far as the user understands what they are doing. There are so many variables that in specific use cases, the details might have to be worked out. You clearly don't fit the typical use case.
The thing is, the user I was responding to was complaining that systemless can't do what was wanted. That was flat not true. Using a systemless debloater then being surprised that the apks came back in core only mode was a dead giveaway.
Unless a user knows what they are doing, maybe if they are on a custom ROM, or are on an old release, Magisk is the "best" solution.
Primarily what I was trying to do is provide a cliff's note update for those still looking for SuperSu to be the premier rooting option. It's just not any longer.
not working for me, Asus Zenfone 4 Max Nougat, Im stuck in Loading "Zenfone with a wave of dots". can anyone help me to gain a full system root on my phone? Thanks you
@leinadark: Your ROM's kernel probably has Selinux set to be enforcing on boot. System mode SuperSU does not work without permissive mode. Find a custom kernel that sets it to permissive on boot. This is the #1 mistake I see alot of users making, they flash the zip without reading this topic, then they complain that their phone won't boot.
Thanks for the info, i just don't understand what is Selinux
, Anyway I'm giving up cause I can't find a way to gain full root access.SELinux is "Security Enhanced Linux", designed by the NSA if I remember correctly. Google adopted it for Android but changed a few things. It is basically a Linux kernel module (Android kernel is based on Linux) that loads at boot. Think of it as an advanced antivirus for Android, it can block/allow certain things. It can even restrict root powers. It runs on a set of allow/deny rules (which can be modified), similar to a firewall.
Enforcing: SELinux runs in the background, actively enforcing rules, and denying/allowing things.
Permissive: SELinux still runs in the background, but it is in a passive mode where it does nothing. It still keeps logs of what is happening, but that's about it.
If you want to run system mode SuperSU, then either install a permissive kernel, build your own kernel with permissive as default, or rebuild your ROM's boot.img with the kernel command line parameters specifying permissive.
Enforcing: SELinux runs in the background, actively enforcing rules, and denying/allowing things.
Permissive: SELinux still runs in the background, but it is in a passive mode where it does nothing. It still keeps logs of what is happening, but that's about it.
If you want to run system mode SuperSU, then either install a permissive kernel, build your own kernel with permissive as default, or rebuild your ROM's boot.img with the kernel command line parameters specifying permissive.
The only way to know for sure is to try it yourself. Just make sure you flash a permissive kernel BEFORE flashing the SuperSU system mode zip, or else you will certainly encounter a stalled boot/boot loop.
The best way for you to test:
Flash custom kernel zip, WITHOUT flashing SuperSU zip. Boot into Android, open a terminal app, type "getenforce", without quotes. If it returns 0 or permissive as the result, you should be good to flash SuperSU zip.
If you get 1 or enforcing:
Flash the kernel_permissive_patcher.zip from:
Kernel permissive patcher
After that, reboot and run the terminal commands again. If you get 1 or permissive, try the SuperSU zip. Even after all this, it's still not guaranteed that you'll be able to boot with SuperSU in system mode, but it will likely work. It just depends on the installed ROM/kernel.
Note: if you get "permission denied" when using the getenforce command, use the su command, then getenforce. This of course requires that you be temp rooted with something else.
Edit: you can also check SELinux status in in the About (or similarly named) section of the Settings app. An app called TeMeFi can also retrieve the status. I only suggested the terminal way first, because I'm so used to using commands in a terminal to do many things.
Last edited:
