After updating the ROM through OpenDelta I constantly have to reinstall SuperSu app, even though I put the relevant zipfile in /sdcard/OpenDelta/FlashAfterUpdate/
Any ideas as to why's this? And, even more important, how to solve it?
I did already enable survival mode and backup script for custom ROMs, but that didn't help
husky69 said:
After updating the ROM through OpenDelta I constantly have to reinstall SuperSu app, even though I put the relevant zipfile in /sdcard/OpenDelta/FlashAfterUpdate/
Any ideas as to why's this? And, even more important, how to solve it?
I did already enable survival mode and backup script for custom ROMs, but that didn't help
Click to expand...
Click to collapse
That's strange... If you enabled the backup script it SHOULD be staying around.
husky69 said:
After updating the ROM through OpenDelta I constantly have to reinstall SuperSu app, even though I put the relevant zipfile in /sdcard/OpenDelta/FlashAfterUpdate/
Any ideas as to why's this? And, even more important, how to solve it?
I did already enable survival mode and backup script for custom ROMs, but that didn't help
Click to expand...
Click to collapse
did you disabled the "secure mode" in OpenDelta setting? Because if you don't the system won't flash any .zip in the FlashAfterUpdate folder..
maximancini said:
did you disabled the "secure mode" in OpenDelta setting? Because if you don't the system won't flash any .zip in the FlashAfterUpdate folder..
Click to expand...
Click to collapse
If he installed SuperSu as a system app and installed the backup script he shouldn't have to worry about "secure mode" ...I think?
Maybe using the flashably zip AND the backup script is source of the issue, since they are different versions? It's just my guess though.
chuSmu said:
If he installed SuperSu as a system app and installed the backup script he shouldn't have to worry about "secure mode" ...I think?
Maybe using the flashably zip AND the backup script is source of the issue, since they are different versions? It's just my guess though.
Click to expand...
Click to collapse
May depend on recovery as well.
Given that TWRP does not work with 4.4.2 builds on my device my only choice is to use CWM and manually flash updates...which requires manually restoring SuperSU each time.
chuSmu said:
If he installed SuperSu as a system app and installed the backup script he shouldn't have to worry about "secure mode" ...I think?
Maybe using the flashably zip AND the backup script is source of the issue, since they are different versions? It's just my guess though.
Click to expand...
Click to collapse
Backup script should work fine with "secure mode" - just like gapps does.
Entropy512 said:
Backup script should work fine with "secure mode" - just like gapps does.
Click to expand...
Click to collapse
Hmmm I'll double check my setting before tonight's nightly gets put up. I don't recall the "enable backup script" being anything other than grayed out as installing SuperSU into /System from the app never seemed to take.
(have SuperSU Pro installed ofc)
Secure mode is disabled in OpenDelta. Yet problem still as described
Related
So I was having a similar problem to the users in this thread
http://forum.xda-developers.com/showthread.php?t=2434063
and I did a full unroot as someone suggested, and the update went through and updated my phone finally. I go back and flash SuperSU (1.51), and CWM says that it successfully flashed the zip, but there is no SuperSU app or root access on my phone. Any ideas on how I can fix this?
Try flashing SU v1.60. You are flashing an outdated version.
Version 1.55 is already reworked. Maybe flashing an updated SU will work for you.
Send from my Nexus 4
Nope. No go. I tried flashing 1.55 and 1.60, but neither create the SU app even though CWM says it flashed correctly. Maybe I will try installing a different recovery.
Edit: New recovery didn't work either.
MildewMan said:
Nope. No go. I tried flashing 1.55 and 1.60, but neither create the SU app even though CWM says it flashed correctly. Maybe I will try installing a different recovery.
Edit: New recovery didn't work either.
Click to expand...
Click to collapse
Make sure you have USB debugging enabled in settings menu. Same happened to me today and it turns out that I only found out that this had become unticked when I flashed v1.55 and tried to run titanium backup and it gave me a message that USB debugging was not enabled. Ticked that on and reflashed and viola! SuperSU sat grinning away in my app drawer.
I can't explain why it had become unticked in the first place. I suspect it was when I uninstalled SuperSU initially by doing full cleanup method in SuperSU settings menu.
Im on Purity Rom latest with twrp 2.6.2.0
carlos67 said:
Make sure you have USB debugging enabled in settings menu. Same happened to me today and it turns out that I only found out that this had become unticked when I flashed v1.55 and tried to run titanium backup and it gave me a message that USB debugging was not enabled. Ticked that on and reflashed and viola! SuperSU sat grinning away in my app drawer.
I can't explain why it had become unticked in the first place. I suspect it was when I uninstalled SuperSU initially by doing full cleanup method in SuperSU settings menu.
Im on Purity Rom latest with twrp 2.6.2.0
Click to expand...
Click to collapse
Yeah I noticed it had become unticked when I tried to use adb to install the new recovery, but turning it back on didn't help either. :/
MildewMan said:
Yeah I noticed it had become unticked when I tried to use adb to install the new recovery, but turning it back on didn't help either. :/
Click to expand...
Click to collapse
Update: I just went to the play store and downloaded SuperSU, and it installed correctly and added the app to the drawer if anyone else has this issue. Opened up Titanium backup, and it was able to get root access.
Hi everyone!
I installed a few days ago OmniROM on my freshly unlocked Nexus 4, with Franco's kernel and I really like it! I love that there are updates everyday!
But I never succeeded to perform it with built-in OTA updater. So I always flashed it as usual, and it works. But downloading the entire file everyday is boring.
So, when I start the installation via the built-in OTA updater, it reboots the phone into recovery (I use ClockworkMod Recovery v6.0.4.3), and then it says that it failed the installation. There are no problem after that, I just reboot normally. It actually says:
"Error processing ROM Manager script. Please verify that you are performing the backup, restore, or ROM installation from ROM Manager v4.4.0.0 or higher. /tmp/recovery.log was copied to /sdcard/clockworkmod/recovery.log. Please open ROM Manager to report the issue".
I attached to the thread the log quoted in the error message.
So am I doing something wrong? I don't have the premium option of ROM Manager, and I saw there is an OTA option in the app. Does it mess with the built-in OTA updater?
Thanks in advance!
OTA updater won't work on CWM as it doesn't have "openrecoveryscript"
TWRP has this and works with no issues
Okay, thanks.
For installing it, as I now have CWM, is it possible to install TWRP from their Android app and erase CWM?
Tiwenty said:
Okay, thanks.
For installing it, as I now have CWM, is it possible to install TWRP from their Android app and erase CWM?
Click to expand...
Click to collapse
Install GooManager and flash TWRP from it.
I think we're going to have to add some sort of message to the updater indicating that it won't work with any official CWM release (anything compiled with I_AM_KOUSH set) - These CWM releases block anything but ROM Manager from using the extendedcommands interface.
Philz Touch CWM works fine with OTA
mithun46 said:
OTA updater won't work on CWM as it doesn't have "openrecoveryscript"
TWRP has this and works with no issues
Click to expand...
Click to collapse
I'm using the Philz Touch CWM and OTA is working fine, in fact everything seems to be working just fine.
http://forum.xda-developers.com/showthread.php?t=2552673
This is on a T-Mobile Galaxy Note 2.:good:
Okay, thanks everyone. I flashed TWRP and I am now waiting for an OTA to test this!
PhilZ has openrecoveryscript support
Okay, so the OTA worked. Thanks you guys!
A question, is it normal that SuperSU is removed each time I upgrade?
Entropy512 said:
I think we're going to have to add some sort of message to the updater indicating that it won't work with any official CWM release (anything compiled with I_AM_KOUSH set) - These CWM releases block anything but ROM Manager from using the extendedcommands interface.
Click to expand...
Click to collapse
It's on my todo list ...
Tiwenty said:
Okay, so the OTA worked. Thanks you guys!
A question, is it normal that SuperSU is removed each time I upgrade?
Click to expand...
Click to collapse
If you don't install the backup script from the SuperSU settings menu - yes for the time being.
Okay, I installed the backup script for SuperSU. It now stays when I upgrade.
But each time I upgrade, when I return from recovery, it optimizes all of my apps. It takes around 15 minutes. Maybe it is because I use ARC, if I go back to Dalvik will it stop?
Tiwenty said:
Okay, I installed the backup script for SuperSU. It now stays when I upgrade.
But each time I upgrade, when I return from recovery, it optimizes all of my apps. It takes around 15 minutes. Maybe it is because I use ARC, if I go back to Dalvik will it stop?
Click to expand...
Click to collapse
This is standard - usually happens any time the frameworks get touched. Shouldn't be taking 15 minutes though...
Oh wait, you're using ART, that's probably it. ART is notorious for VERY long bootup optimization times.
tl;dr: fastboot boot to stock boot.img, log in to snapchat, reboot.
Hello All,
I was trying to log in to Snapchat and I discovered that it won't let you log in if you're rooted. I searched the forums and I found a lot of different solutions, but they required me to install Xposed or fully unroot, which seemed like a hassle. So, I decided to make a guide for the best way to do this on a stock rooted ROM.
1. Download the full system image for your device + build (https://developers.google.com/android/images)
This worked on my Pixel, it should work for other Nexus/Pixel/Pixel XL devices as well though.
2. Unzip the file
3. Unzip the image-sailfish-XXXXXX.zip inside the new folder
4. Connect your device to your computer with ADB and reboot to bootloader
5. fastboot boot path/to/boot.img (inside the folder from step 3.)
NOTE: Please make sure to fastboot BOOT, NOT fastboot FLASH.
6. Once booted, log in to Snapchat. It should work.
7. Reboot.
8. Backup Snapchat in Titanium Backup so you don't have to do this again.
You should now be logged in to Snapchat! Since you only booted to the stock unrooted image, you should still be rooted after you reboot in step 7.
Doesn't work babe
I just use magisk yes it's limited but it does what it need it for
avenator14 said:
tl;dr: fastboot boot to stock boot.img, log in to snapchat, reboot.
Hello All,
I was trying to log in to Snapchat and I discovered that it won't let you log in if you're rooted. I searched the forums and I found a lot of different solutions, but they required me to install Xposed or fully unroot, which seemed like a hassle. So, I decided to make a guide for the best way to do this on a stock rooted ROM.
1. Download the full system image for your device + build (https://developers.google.com/android/images)
This worked on my Pixel, it should work for other Nexus/Pixel/Pixel XL devices as well though.
2. Unzip the file
3. Unzip the image-sailfish-XXXXXX.zip inside the new folder
4. Connect your device to your computer with ADB and reboot to bootloader
5. fastboot boot path/to/boot.img (inside the folder from step 3.)
NOTE: Please make sure to fastboot BOOT, NOT fastboot FLASH.
6. Once booted, log in to Snapchat. It should work.
7. Reboot.
8. Backup Snapchat in Titanium Backup so you don't have to do this again.
You should now be logged in to Snapchat! Since you only booted to the stock unrooted image, you should still be rooted after you reboot in step 7.
Click to expand...
Click to collapse
This method wont work with the stock kernel. You would need to use a kernel that includes the safetynet patch since Snapchat checks against this. Magisk does work though. Just select Snapchat from the Magisk Hide settings menu once you get it installed properly.
uodii said:
This method wont work with the stock kernel. You would need to use a kernel that includes the safetynet patch since Snapchat checks against this. Magisk does work though. Just select Snapchat from the Magisk Hide settings menu once you get it installed properly.
Click to expand...
Click to collapse
I got this to work on my own stock rooted Pixel with the stock kernel. You are booting into an unrooted image using my method, so the SU binary will not be present. This was sufficient to allow me to log in to Snapchat, even though my bootloader was still unlocked. This works because the Pixel uses a systemless root.
real_stacky said:
Doesn't work babe
Click to expand...
Click to collapse
Are you using the right image? Make sure you are downloading the factory image, not the OTA image. This will only work if you are on stock firmware, and make sure to download the right factory image for your device and version.
avenator14 said:
Are you using the right image? Make sure you are downloading the factory image, not the OTA image. This will only work if you are on stock firmware, and make sure to download the right factory image for your device and version.
Click to expand...
Click to collapse
SafetyNet checks for an unlocked bootloader. That's why I said a patched kernel is required...Unless they changed something again, but this was definitely required a few months back.
uodii said:
SafetyNet checks for an unlocked bootloader. That's why I said a patched kernel is required...Unless they changed something again, but this was definitely required a few months back.
Click to expand...
Click to collapse
Hm yeah I can't really speak to the inner workings of SafetyNet, however I did have an unlocked bootloader at the time of performing this, so from my own anecdotal experience I can say that this method allows Snapchat to log in with an unlocked bootloader (I haven't tried it with other apps) on build NHG47K.
avenator14 said:
Hm yeah I can't really speak to the inner workings of SafetyNet, however I did have an unlocked bootloader at the time of performing this, so from my own anecdotal experience I can say that this method allows Snapchat to log in with an unlocked bootloader (I haven't tried it with other apps) on build NHG47K.
Click to expand...
Click to collapse
If that's the case, then it's good info. Maybe it only does a SU check instead of SafetyNet. Good info.
avenator14 said:
Are you using the right image? Make sure you are downloading the factory image, not the OTA image. This will only work if you are on stock firmware, and make sure to download the right factory image for your device and version.
Click to expand...
Click to collapse
Nvm i found an app on the play store that does the trick called Hide Rooting Lite. (Can't link it soz)
thanx this actually worked flawlessly. latest build twrp rc1 and rooted. I follow your instruction and it worked. now TB backup. thanx and rep for u.
Edit: after doing this I actually did a TB backup. deleted snapchat app and restore app+data using TB. having root and it still works.
Failed to boot boot.img ..... "dtb not found"....?
+1 mate
Titanium backup is also good for me cause I use the app kik and when you sign out you lose all your messages so I make backups and when restoring all my messages are back!!
Going be using that app more often now!!
https://www.youtube.com/watch?v=a-PtwtQFBWg
I made a video on how to increase your snap score. Hope you enjoy it!
cgrimm9 said:
I just use magisk yes it's limited but it does what it need it for
Click to expand...
Click to collapse
What do you mean it's limited? More features than SuperSU
---------- Post added at 11:29 AM ---------- Previous post was at 11:14 AM ----------
eduardmc said:
thanx this actually worked flawlessly. latest build twrp rc1 and rooted. I follow your instruction and it worked. now TB backup. thanx and rep for u.
Edit: after doing this I actually did a TB backup. deleted snapchat app and restore app+data using TB. having root and it still works.
Click to expand...
Click to collapse
Just use Magisk m8
I'm on a rooted OP 6T, I installed TWRP and Magisk when I first got it on release day. I was using systemize to system install my GCam apk, rebooted and now I cant go any further than the dots loading screen. I tried a date wipe, still cant get any further. I want to try uninstalling magisk or the individually modules but I can't figure out how I do that. When I try to access my files through recovery they seem to be encrypted so I don't know how to get the uninstall zip flashed. Can someone please help
update
I got the magisk uninstaller sideloaded but it says magisk is not installed, is there a way I can just go back to stock and clear everything? I havent installed a custom rom just unlocked and rooted
If you're able to go to download mode then ADB sideloading should help you.
There's bunch of tutorials on how to do that on the forum.
geminium said:
If you're able to go to download mode then ADB sideloading should help you.
There's bunch of tutorials on how to do that on the forum.
Click to expand...
Click to collapse
not sure what downloading mode is, but I did get into ADB sideload mode. I tried sideloading the magisk uninstallers so I could get rid of whatever module caused the issue, but I got the reply that magisk isn't installed. So now Im not sure what to do from here besides trying to go fully back to stock, which Id rather not
Grab a stock boot.img in the fastboot stock ROM thread in general section and flash it with fastboot to replace the magisk modified one
Striatum_bdr said:
Grab a stock boot.img in the fastboot stock ROM thread in general section and flash it with fastboot to replace the magisk modified one
Click to expand...
Click to collapse
The system is modified. Maybe gonna have to sideload the whole firmware package ~1gb. I'm pretty sure this is the reason everything in magisk is systemless. Maybe contact the developer about the mod and see if they know a way to get it to work for your situation?
stryver said:
The system is modified. Maybe gonna have to sideload the whole firmware package ~1gb. I'm pretty sure this is the reason everything in magisk is systemless. Maybe contact the developer about the mod and see if they know a way to get it to work for your situation?
Click to expand...
Click to collapse
It is not the system partition that is modified (that's the point for a systemless app...) It's boot and data (magisk puts here the img it needs to mount virtually and execute all the magisk modules you installed). You got nothin to lose to flash boot.img first and if it doesn't work you restore system and data
Striatum_bdr said:
It is not the system partition that is modified (that's the point for a systemless app...) It's boot and data (magisk puts here the img it needs to mount virtually and execute all the magisk modules you installed). You got nothin to lose to flash boot.img first and if it doesn't work you restore system and data
Click to expand...
Click to collapse
OP stated that they used a systemizer app to install gcam to the system, doesn't that mean there is now a modification in the system? Which would explain why the data format is not working.
stryver said:
OP stated that they used a systemizer app to install gcam to the system, doesn't that mean there is now a modification in the system? Which would explain why the data format is not working.
Click to expand...
Click to collapse
No it's all virtual, the physical partition system is not modified.
Again, what do you have to lose by flashing boot.img...
Striatum_bdr said:
No it's all virtual, the physocal partition system is not modified
Click to expand...
Click to collapse
That's true for magisk, but installing any apps to system via 3rd party root app will cause the apps to survive factory resets, right? So if say, new system app was causing any conflicts, those conflicts will also survive.
stryver said:
That's true for magisk, but installing any apps to system via 3rd party root app will cause the apps to survive factory resets, right?
Click to expand...
Click to collapse
Again what do you have to lose by flashing boot img? Your phone doesn't boot... At worse it won't boot and you'll have to come back to factory by fastboot the would system
Striatum_bdr said:
Again, what do you have to lose by flashing boot.img...
Click to expand...
Click to collapse
Sorry I'm not trying to be argumentative, I'm merely speaking what makes sense to me
Endless speculation can be ended by experimentation...
Striatum_bdr said:
Endless speculation can be ended by experimentation...
Click to expand...
Click to collapse
Agreed, now where is OP to confirm our speculation??
And by the way App Systemizer is systemless so it doesn't touch system partition, first sentence of the module description
Striatum_bdr said:
And by the way App Systemizer is systemless so it doesn't touch system partition, first sentence of the module description
Click to expand...
Click to collapse
I was just going to check this, never used it myself. Probably should have checked before speaking. Lesson learned lol oh well
Again, sorry if I came off argumentative.
Next thing that comes to mind for OP is that there is a difference between 'wiping data' and 'formatting data'. If you just wiped, try to format data. I had a bootloop from uninstalling a magisk module and quickly recovered by formatting.
stryver said:
Agreed, now where is OP to confirm our speculation??
Click to expand...
Click to collapse
I ended up just downloading the OnePlus tool and stock fajita rom and taking it back to stock. Still not sure exactly what caused the problem, I did everything over again with no issues the second time around
Hi, just got around to rooting my Kindle. Currently using SuperSu, curious if anyone has used Magisk with this tablet? Any reason not to do so?.
Thanks in advance.
I've debated doing this as well, as I don't like having to default grant everything root access.
As far as I understand though, none of your root apps/su requests can modify the system partition, so I haven't tried it yet.
@diplomatic is this true for the bootless root method without dm-verity?
No, you can modify /system if there's no dm-verity, @Kctucka
diplomatic said:
No, you can modify /system if there's no dm-verity, @Kctucka
Click to expand...
Click to collapse
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Kctucka said:
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Click to expand...
Click to collapse
Thanks, guys!
SuperSU access workaround
Kctucka said:
I've debated doing this as well, as I don't like having to default grant everything root access.
.....
Click to expand...
Click to collapse
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Dan_firehd said:
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Click to expand...
Click to collapse
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Kctucka said:
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Click to expand...
Click to collapse
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Yeah will do! I'll probably try it tomorrow or the day after.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
So far, all of my root apps detect root, except for titanium backup. I've messed around with it for a bit but haven't been able to figure it out. I'm guessing it has something to do with the location of the su binaries.
Also of note, FlashFire did not work at first. I realized that this is because the timebomb method we used along with the older app version, was from before Magisk existed. I grabbed the latest version of FlashFire from apk mirror, and it started without issues. I haven't tested by flashing anything yet though.
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
All in all, this is a pretty solid root method, but obviously non ideal due to the locked bootloader.
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Kctucka said:
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
Click to expand...
Click to collapse
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into this after so long I feel like a n00b again.
koop1955 said:
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into thhis after so long I feel like a n00b again.
Click to expand...
Click to collapse
That option was all I did to remove SuperSu. Then I followed the instructions here:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
Didn't take long to get it working.
And the time change was to get the version of FlashFire working that was compatible with the version of SuperSu we could run. See this post for more info if you're curious:
https://forum.xda-developers.com/hd8-hd10/general/hd-10-2017-xposed-t3722252
But with this new method, the most recent version of FlashFire works, as it's compatible with Magisk. The older version of FlashFire I had is not.
Also, I'm a noob myself. That's why I tagged diplomatic again, to correct the dumb things I might have said
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
koop1955 said:
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
Click to expand...
Click to collapse
That's awesome! Would that pass signature verification? Or would it be through hacked fastboot?
Also, that'd make it much easier to set up the device after a softbrick. FlashFire would be good to flash backups right away.
Kctucka said:
.....
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
.....
Click to expand...
Click to collapse
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Dan_firehd said:
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Click to expand...
Click to collapse
My kernel tweaks were done with KA Mod Reborn, using the "apply on boot" setting:
https://forum.xda-developers.com/android/apps-games/approot4-0-ka-mod-reborn-v18-t3714105
I added 260 MB ZRAM with a swapiness of 10. You can also tweak low memory killer, laptop mode, and a whole bunch of other dials that I don't mess with as I don't fully understand what they do.
Kernel changes could also be done with a number of different apps that do similar things.
Unfortunately, the bootless root method doesn't give root on boot, so it and also most Magisk modules won't work. Can't think of a workaround currently.
Kctucka said:
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Click to expand...
Click to collapse
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
That's super beneficial then, you can swap back and forth easily depending on what you need.
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
How about just swapping the install-recovery.sh script for suboot.sh on devices that don't have dm-verity?
I think that's pretty much what SuperSU does as well.
That would give root much earlier during boot and not depend on the extra App.
Probably doesn't even need to run mtk-su each boot then either.
Yeah, that's on the right track, @k4y0z. What you can probably use is a modified SU_MINISCRIPT section of suboot.sh, at least as a starting point. That is the code that needs to be run as root. What should be changed is the path to the magiskinit & magisk binaries. Those could be placed somewhere on /system. You would only need mtk-su if selinux needs to be permissive. But I suspect it does for the 'magiskpolicy --live' call. (But then how does SuperSU handle it with enforcing?)