Related
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
Hello everyone
Well... Not much to say.
I've made that very simple module for my personal use and just sharing it with the community in case anyone needs it.
What it does it really simple.
It installs (or replaces) sqlite3 binary in /system/bin to be used by any app or from terminal.
It's for ARM7 only.
Have fun
Credits: @topjohnwu for the template and @tech128 for the binary used.
Thank you for your effort... Do you have binary of sqlite of 64bit?
lssong99 said:
Thank you for your effort... Do you have binary of sqlite of 64bit?
Click to expand...
Click to collapse
I'm currently on G5 which is 64bit and binary works just fine.
Yes, it will work. However my situation is a bit complex that I call sqlite from Tasker and there is a bug in Tasker's that Tasker will invoke 64 bit libraries and throw error even if sqlite is 32 bit.
There is a work around but a bit complex so I am searching for 64 bit binary...
Sorry but what is SQLite
kwanthenewbie said:
Sorry but what i SQLite
Click to expand...
Click to collapse
You don't need it probably xD
It's the "program" to manipulate sqlite databases.
lssong99 said:
Yes, it will work. However my situation is a bit complex that I call sqlite from Tasker and there is a bug in Tasker's that Tasker will invoke 64 bit libraries and throw error even if sqlite is 32 bit.
There is a work around but a bit complex so I am searching for 64 bit binary...
Click to expand...
Click to collapse
https://github.com/stockrt/sqlite3-android
Build one by yourself. I guess you need arm64-v8a ?
DenyDarko said:
I'm currently on G5 which is 64bit and binary works just fine.
Click to expand...
Click to collapse
DenyDarko said:
https://github.com/stockrt/sqlite3-android
Build one by yourself. I guess you need arm64-v8a ?
Click to expand...
Click to collapse
Haha! Thanks.... Actually I had been trying very hard to resist the urge to build one myself (too lazy....). Maybe I should starting setup the tool train now....
Anyway thanks!
lssong99 said:
Haha! Thanks.... Actually I had been trying very hard to resist the urge to build one myself (too lazy....). Maybe I should starting setup the tool train now....
Anyway thanks!
Click to expand...
Click to collapse
It's not that hard and it's fun. Plus this git contains a customised sqlite for android.
It's not like building a kernel or smth. Give it a try xD
Hi @DenyDarko,
Please, can you update your module? It doesn't install with last version of Magisk. Futhermore, it will be interesting to include all binaries: sqlite3.arm; sqlite3.arm64; sqlite3.x64; etc. and add a symlink for the run architecture to "sqlite3". And last, publish it in the official repository.
Thank you!
manos78 said:
Hi @DenyDarko,
Please, can you update your module? It doesn't install with last version of Magisk. Futhermore, it will be interesting to include all binaries: sqlite3.arm; sqlite3.arm64; sqlite3.x64; etc. and add a symlink for the run architecture to "sqlite3". And last, publish it in the official repository.
Thank you!
Click to expand...
Click to collapse
@ianmacd added an updated version to the official repo already
DenyDarko said:
@ianmacd added an updated version to the official repo already
Click to expand...
Click to collapse
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
ianmacd said:
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
Click to expand...
Click to collapse
I even use yours now myself xD
@DenyDarko
Can you somehow check if this sqlite3 works ?
ianmacd said:
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
Click to expand...
Click to collapse
Hi @ianmacd,
I installed your Magisk module. However, I found a trouble: when enabling your module, the SafetyNet check never completes or indicates "the response is invalid".
So, please verify or review your module. Only disabling it the SafetyNet continues working well.
Or almost, put this info in the description, because your module is now in the official repository.
Regards.
manos78 said:
Hi @ianmacd,
I installed your Magisk module. However, I found a trouble: when enabling your module, the SafetyNet check never completes or indicates "the response is invalid".
So, please verify or review your module. Only disabling it the SafetyNet continues working well.
Or almost, put this info in the description, because your module is now in the official repository.
Regards.
Click to expand...
Click to collapse
The issue might be that the module mounts the binary to /system/xbin, and that your device doesn't have a xbin folder by default. This has been known to cause issues, and seem to be even more prevalent on recent Magisk releases. Try changing the modules xbin folder to bin and reboot, to see if it makes any difference.
@ianmacd It's a good idea to look for the existence of xbin at installation and use bin instead if it doesn't exist.
Didgeridoohan said:
The issue might be that the module mounts the binary to /system/xbin, and that your device doesn't have a xbin folder by default. This has been known to cause issues, and seem to be even more prevalent on recent Magisk releases. Try changing the modules xbin folder to bin and reboot, to see if it makes any difference.
@ianmacd It's a good idea to look for the existence of xbin at installation and use bin instead if it doesn't exist.
Click to expand...
Click to collapse
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
ianmacd said:
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
Click to expand...
Click to collapse
Good point... Check for /sbin/.core/mirror/system/xbin. That's the untouched /system mirror.
ianmacd said:
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
Click to expand...
Click to collapse
Alternately you can just use bin and forget about xbin. There's really no technical reason to use xbin unless you're installing alternate forms of existing commands.
jcmm11 said:
Alternately you can just use bin and forget about xbin. There's really no technical reason to use xbin unless you're installing alternate forms of existing commands.
Click to expand...
Click to collapse
That's actually also been known to cause issues on some systems. While investigating issues like this, a while back, I believe it was found that it was most compatible to use xbin if it exists and bin if it doesn't.
I'm using official Omni 8.1. The issue I'm facing is that the Magisk Manager can't seem to remember the apps it has granted Superuser permission. Even in the Superuser tab it shows "No apps found". Result being I have to grant Superuser permission every time when I open an app like Root Explorer.
Please look into this issue.
Magisk Manager: v5.5.2
Magisk Root: v15.1 Stable
I don't have this issue on version 5.5.0 and 15.1 on the latest Omni 8.1 weekly on my Oneplus 3T.
Edit: You didn't mention what device, so I doubt anyone would be able to help you. But I guess you're running a Oneplus 3T or a Oneplus 5 since there are no 8.1 Omni weeklies for any other devices, yet. Maybe you could try to attach some logs.
For me Magisk v15.1 doesn't boot anymore, it just fails and goes back to recovery.
v14.6 works fine.
Omni 8.1 on Oneplus 5T
Same problem here. Any solution?
Look into this issue, doesn't boot, solutions?
Where are the logs?
How do you expect someone to help you without that?
For all the praise Magisk seems to get, it sure does have some issues. Lately, it's been kind of a lottery figuring out which version will work with which ROM... These things never happend to me on SuperSu
Jazavchar said:
For all the praise Magisk seems to get, it sure does have some issues. Lately, it's been kind of a lottery figuring out which version will work with which ROM... These things never happend to me on SuperSu
Click to expand...
Click to collapse
I'd say it has to do with the incredible speed that the Magisk development has been going at. Looking back over the past year, a lot has happened. This kind of speed can cause instabilities...
Now, it's most likely at a point where the focus will be on stability and compatibility development.
Having said that, though, all users experiencing issues can help with that by providing as much details as possible and relevant logs.
I can confirm this. It seems Magisk has a problem opening the sqlite3 database, on OmniROM 8.1 at least.
The Superuser request can be granted, and it goes through (as in the app gets its root access), however nothing is permitted "forever".
Superuser log in Magisk Manager is empty, so is the list of apps granted Superuser access.
From my log:
Code:
sqlite3 open failure: unable to open database file
Either the sqlite3 database is located somewhere else, or Magisk didn't get the correct writing rights during the install. Did something change regarding this in 8.1?
There is also a somewhat unrelated issue with Magisk Hide, where the hidelist-file doesn't exist/wasn't initially created upon installation:
Code:
fopen: /sbin/.core/img/.core/hidelist failed with 2: No such file or directory
Full log attached.
debichu said:
I can confirm this. It seems Magisk has a problem opening the sqlite3 database, on OmniROM 8.1 at least.
The Superuser request can be granted, and it goes through (as in the app gets its root access), however nothing is permitted "forever".
Superuser log in Magisk Manager is empty, so is the list of apps granted Superuser access.
From my log:
Code:
sqlite3 open failure: unable to open database file
Either the sqlite3 database is located somewhere else, or Magisk didn't get the correct writing rights during the install. Did something change regarding this in 8.1?
There is also a somewhat unrelated issue with Magisk Hide, where the hidelist-file doesn't exist/wasn't initially created upon installation:
Code:
fopen: /sbin/.core/img/.core/hidelist failed with 2: No such file or directory
Full log attached.
Click to expand...
Click to collapse
Two things I'm curious about (at the moment):
What are the permissions for /data/adb/magisk.db?
Do you now have a hidelist file in /sbin/.core/img/.core?
Didgeridoohan said:
Two things I'm curious about (at the moment):
What are the permissions for /data/adb/magisk.db?
Do you now have a hidelist file in /sbin/.core/img/.core?
Click to expand...
Click to collapse
There is no such file in that location. There is a magisk.img in that folder with -rw-r--r--, and a magisk/ folder but not containing any magisk.db file either.
Yes, there is now a hidelist file in /sbin/.core/img/.core with -rw-rw-rw-
Bonus info:
I did a complete wipe (I initially did that but I wanted to be certain), and I got this error while installing Magisk right after OmniROM (also see attached):
Code:
! System installed root detected, mount rw :(
Now, OmniROM doesn't ship with root built in - at least not to my knowledge. So I don't know what this "system installed root" Magisk is detecting.
debichu said:
There is no such file in that location. There is a magisk.img in that folder with -rw-r--r--, and a magisk/ folder but not containing any magisk.db file either.
Yes, there is now a hidelist file in /sbin/.core/img/.core with -rw-rw-rw-
Bonus info:
I did a complete wipe (I initially did that but I wanted to be certain), and I got this error while installing Magisk right after OmniROM (also see attached):
Code:
! System installed root detected, mount rw :(
Now, OmniROM doesn't ship with root built in - at least not to my knowledge. So I don't know what this "system installed root" Magisk is detecting.
Click to expand...
Click to collapse
Number 1 is an issue, because that's the su database... If there is none, it's no wonder why granted superuser requests aren't saved.
Hi, do you have a solution?
@Didgeridoohan i am facing same issue like this . it keeps asking for superuser req .
cpt.macp said:
@Didgeridoohan i am facing same issue like this . it keeps asking for superuser req .
Click to expand...
Click to collapse
As far as I know, so far the only known working solution is to reformat /data as ext4. Or stay on an old version of Magisk.
Didgeridoohan said:
As far as I know, so far the only known working solution is to reformat /data as ext4. Or stay on an old version of Magisk.
Click to expand...
Click to collapse
which version you suggest also my /data is ext4 only .
also i would like to tell you one more thing after tinkering little bit and observed following things
as soon as i dont open the magsik app and using root by simple toast and granting the permission it works but as soon as i open the app , it starts misbehaving . i wonder why .
cpt.macp said:
which version you suggest also my /data is ext4 only .
also i would like to tell you one more thing after tinkering little bit and observed following things
as soon as i dont open the magsik app and using root by simple toast and granting the permission it works but as soon as i open the app , it starts misbehaving . i wonder why .
Click to expand...
Click to collapse
Let me guess: you're not using OmniROM...
Since you're posting in this thread, I kind of assumed you did, so my answer was given accordingly.
If you need help, post all possible details and lots of relevant logs.
I've had the same error. Magisk seems unstable on OmniROM 8.1 on OnePlus 5. Probably an issue with the ROM, but the developer seems like the kind of guy who will tell you to go f*ck yourself if you have a problem like this.
Sometimes it works sometimes it doesn't.
A temporary workaround with the permission issue on /data/adb/magisk.db, even after not working trying 0666 permissions, was to change ownership. None of many other solutions worked for me until I found the user for Magisk. You can use a shell as root or with apps like FX File Explorer with root capability to see which user owns files in "/data/adb/magisk/" . Then I applied that user as the owner of magisk.db. Verified that apps which ask for root permission get saved now. The user of Magisk will be different for you since it is marked as "app_##' which I suppose is up to the amount of apps you have installed.
I have a problem and think it caused by the same reason other users here.. My issue is after installing omni rom and gapps ONLY i can't use my banking apps because ( i guess) it thinks my device is rooted.
Device : oneplus 5
I wasn't planning to root my device to keep those kind of issues away
saidmsb said:
I have a problem and think it caused by the same reason other users here.. My issue is after installing omni rom and gapps ONLY i can't use my banking apps because ( i guess) it thinks my device is rooted.
Device : oneplus 5
I wasn't planning to root my device to keep those kind of issues away
Click to expand...
Click to collapse
No... I don't think so. This thread is about an issue with Magisk and f2fs on Android 8.1 ROMs. Your issue could be that OmniROM sets some sensitive props to triggering values.
That can be taken care of by using Magisk and MagiskHide. Take a look here for more info:
https://www.didgeridoohan.com/magisk/MagiskHide#hn_Sensitive_props
If you decide to install Magisk, this part of the guide might also be useful (all of it is useful, really):
https://www.didgeridoohan.com/magisk/MagiskHide#hn_Hiding_root_from_apps
Hi.
I have a HTC 10 running LineageOS 14.1. In the past 4 days I have had to re install Magisk 16.3 at least 4 times daily as it keeps uninstalling itself. I have always had this issue with Magisk but it appears to have gotten worse instead of being solved.
Any suggestions as to what I can do to improve the situation?
It's likely not uninstalling itself, but something is killing the daemon. If you figure out what (aggressive battery saving might be a culprit), it would be good...
Magisk manager tells me that "Magisk is not installed" and that version 16.3 is available to install. However when I reboot it's there again so looks like you're right. Guess I'll have to have a look for what's causing it.. Thanks.
This is happening to me on OOS open beta 6. It's not really uninstalled because all my modules are present, but root does not work and the Magisk app is gone from my apps in settings and app drawer. I have to go into recovery and reflash it. This is happening on reboots at random.
it seems after the april update on stock orea 8.0 MIA1 Xiaomi this issues has become frequant.
manan001 said:
it seems after the april update on stock orea 8.0 MIA1 Xiaomi this issues has become frequant.
Click to expand...
Click to collapse
Some users are experiencing this, and I suspect it's a MagiskHide thing. You could help investigating by doing two things:
Install a beta release (use v16.3 because of the 64-bit issue with v16.4), and provide the magisk_debug.log after Magisk "uninstalls itself". You might have to grab it from recovery, since you're loosing root.
Disable MagiskHide and let it be disabled for a while to see if the issue still occurs (to confirm if it's MagiskHide or not).
Can be caused by Greenify?
I have the same problem magisk uninstalled after installing sdw hide root & sdw mock location through xposed installer
same issue but xposed included.
LG G6 Rootet Oreo Stock debloatet Magisk 17.2. same problem. deinstalling itself
kerpert said:
Can be caused by Greenify?
Click to expand...
Click to collapse
I installed greenify and this happened......probably it is the cause
m1l4droid said:
@Didgeridoohan adding Magisk as an exception in the MIUI battery saver didn't work. Not sure what to do.
Click to expand...
Click to collapse
Me neither...
There's a relatively active GitHub issue open about this issue, but there's been nothing definitive found about it yet.
The reports about this issue are so scattered, lacking in details and undefined that it's hard to say anything either way. Some users have success if disabling MagiskHide, some not so much, etc.
Someone that is experiencing the issue need to figure out what it's about. Until then there's not much to do...
It causes because of Busybox... uninstall busybox module fixed the problem for me
Didgeridoohan said:
... but something is killing the daemon. If you figure out...
Click to expand...
Click to collapse
Definition for daemon: https://www.linux.org/threads/android-services-and-daemons.10847/
How can one figure out?
kerpert said:
Can be caused by Greenify?
Click to expand...
Click to collapse
Nope. I've uninstalled greenify and magisk stopped anyway. So it's not related to greenify.
dan60 said:
How can one figure out?
Click to expand...
Click to collapse
Possibly by saving logs at the moment the daemon is killed off. Can be tricky...
If you don't want to, or don't have the skill to figure that out, you could try this meanwhile:
https://forum.xda-developers.com/apps/magisk/magisk-installed-workaround-t3908748
Would be interesting to know if it works for everyone.
Didgeridoohan said:
If you don't want to, or don't have the skill to figure that out, you could try this meanwhile:
https://forum.xda-developers.com/apps/magisk/magisk-installed-workaround-t3908748
Would be interesting to know if it works for everyone.
Click to expand...
Click to collapse
I should probably state that the module was made using a 17 template so min magisk ver. 17. There's really no telling what's killing the daemon. Also I note in the thread if magiskd is killed manually my module doesn't work. Don't know what all that is about... I've been playing around trying to kill it off manually and restart with no success using SSH as my root access. I don't expect this to work for everyone because I don't know how their daemon is dying. For some odd reason the module works for me when my daemon dies randomly so I'm happy with that. BTW I included logging which prints time and date script detects magisk not running and if it successfully restarted. The logs located in /data/local/tmp/magiskd-helper.log. I also have .pid in /data/local/run. Create dir if non-existent and . pid should be there.
Geofferey said:
I should probably state that the module was made using a 17 template so min magisk ver. 17. There's really no telling what's killing the daemon. Also I note in the thread if magiskd is killed manually my module doesn't work. Don't know what all that is about... I've been playing around trying to kill it off manually and restart with no success using SSH as my root access. I don't expect this to work for everyone because I don't know how their daemon is dying. For some odd reason the module works for me when my daemon dies randomly so I'm happy with that. BTW I included logging which prints time and date script detects magisk not running and if it successfully restarted. The logs located in /data/local/tmp/magiskd-helper.log. I also have .pid in /data/local/run. Create dir if non-existent and . pid should be there.
Click to expand...
Click to collapse
You could let the script also dump the current logcat buffer to a file (or cyclically save logcat to a file set to a certain size) when it detects the Magisk daemon not running. Might show why it dies...
Didgeridoohan said:
... try this meanwhile:
https://forum.xda-developers.com/apps/magisk/magisk-installed-workaround-t3908748
Would be interesting to know if it works for everyone.
Click to expand...
Click to collapse
Great initiative. I installed it yesterday, but sadly my oreo moto z play got unrooted again (same as if no Magiskd-helper had been flashed). But thanks for trying to help.
dan60 said:
Great initiative. I installed it yesterday, but sadly my oreo moto z play got unrooted again (same as if no Magiskd-helper had been flashed). But thanks for trying to help.
Click to expand...
Click to collapse
When you reboot does magisk come back? Could you post output of /data/local/magiskd-helper.log? I would like to see if it even attempted.
Google Pay has stopped working over a week ago and i was hoping for a fix but nothing has come? Did I do something wrong?
Running Android 6.1.6 Magisk Manager
Edit
There is also a bug with the manager? When i select apps for Magisk Hide it doesn't save and when i reload the list all that apps are unticked again??
Thanks in advance
Logs?
Didgeridoohan said:
Logs?
Click to expand...
Click to collapse
Magisk doesn't show any logs, where do I go to turn on Android logging?
JoshuaM765 said:
Magisk doesn't show any logs, where do I go to turn on Android logging?
Click to expand...
Click to collapse
There's your problem...
MagiskHide uses Android logging to detect when it needs to hide from an app or process.
Have you disabled logd? Used something like Kernel Adiutor to disable logs? Etc... Turn it back on and things will start working again.
[HIDE[/HIDE]
Didgeridoohan said:
There's your problem...
MagiskHide uses Android logging to detect when it needs to hide from an app or process.
Have you disabled log's? Used something like Kernel Adiutor to disable logs? Etc... Turn it back on and things will start working again.
Click to expand...
Click to collapse
I don't ever remember disabling logs or using a kernel adiutor. Would I need to edit to turn it on and how would I go about doing this?
Just to confirm, run this in a terminal emulator:
Code:
su -c magiskhide --enable
If it reports that logs are disabled, we can keep on this track.
The question is what happened "over a week ago" that caused things to change. Did you by any chance update Magisk? From v15.4 there was a change that for some devices wrongly disables MagiskHide because it can't detect that Android logging is running. That's been fixed and should be in the next release. You could try the unofficial snapshots by @kantjer, if you're impatient... Just be aware that they might not be built from release ready code.
Didgeridoohan said:
Just to confirm, run this in a terminal emulator:
Code:
su -c magiskhide --enable
If it reports that logs are disabled, we can keep on this track.
The question is what happened "over a week ago" that caused things to change. Did you by any chance update Magisk? From v15.4 there was a change that for some devices wrongly disables MagiskHide because it can't detect that Android logging is running. That's been fixed and should be in the next release. You could try the unofficial snapshots by @kantjer, if you're impatient... Just be aware that they might not be built from release ready code.
Click to expand...
Click to collapse
It was working then I got Xposed for Magisk but that put it in a boot loop so i factory reset and rerooted with Magisk and its now stopped working. When I do the terminal emulator i get "Logb is not running, cannot run logcat"
JoshuaM765 said:
It was working then I got Xposed for Magisk but that put it in a boot loop so i factory reset and rerooted with Magisk and its now stopped working. When I do the terminal emulator i get "Logb is not running, cannot run logcat"
Click to expand...
Click to collapse
Is logcat running? You can test this by using an app like Matlog. If it shows the log, it is a matter of the Magisk v15.4+ bug of detecting logging fully. Solution in that case would be to wait for the next release, test an unofficial snapshot linked above, or revert to a Magisk version prior to v15.4.
Didgeridoohan said:
Is logcat running? You can test this by using an app like Matlog. If it shows the log, it is a matter of the Magisk v15.4+ bug of detecting logging fully. Solution in that case would be to wait for the next release, test an unofficial snapshot linked above, or revert to a Magisk version prior to v15.4.
Click to expand...
Click to collapse
Yes Matlog works, where would i get an unoffical snapshot from?
JoshuaM765 said:
Yes Matlog works, where would i get an unoffical snapshot from?
Click to expand...
Click to collapse
I linked it a few posts ago...
Oh, sorry missed those.
Thanks for all the help, i will report back if it works.
Thanks so much, it was solved using the custom Magisk update link that you posted, Thanks again
JoshuaM765 said:
Thanks so much, it was solved using the custom Magisk update link that you posted, Thanks again
Click to expand...
Click to collapse
Thank you. That's the first confirmation I've seen of anyone with this issue having things working with the current code. That means the fix works...
Next official release (likely a beta) will have the fix included.
I'm also having trouble getting Google pay to work. The app also automatically gets disabled by my phone, and i have to search for it in the play store to re enable it. Magiskhide is enabled. Might it be because I'm in Mexico right now?
basily said:
I'm also having trouble getting Google pay to work. The app also automatically gets disabled by my phone, and i have to search for it in the play store to re enable it. Magiskhide is enabled. Might it be because I'm in Mexico right now?
Click to expand...
Click to collapse
Kindly Do The Following
- Clear Data&Cache Of Google Pay
- Disable Telephone Permission Of Google Play Services
- Try To Use Google Pay
Dreamer(3MF) said:
Kindly Do The Following
- Clear Data&Cache Of Google Pay
- Disable Telephone Permission Of Google Play Services
- Try To Use Google Pay
Click to expand...
Click to collapse
Thanks for the advice, but i tried it and same result.
basily said:
Thanks for the advice, but i tried it and same result.
Click to expand...
Click to collapse
Send The Full Logcat Of Google Pay & Inform Me About The Installed Version Of Magisk.
Didgeridoohan said:
Just to confirm, run this in a terminal emulator:
Code:
su -c magiskhide --enable
If it reports that logs are disabled, we can keep on this track.
The question is what happened "over a week ago" that caused things to change. Did you by any chance update Magisk? From v15.4 there was a change that for some devices wrongly disables MagiskHide because it can't detect that Android logging is running. That's been fixed and should be in the next release. You could try the unofficial snapshots by @kantjer, if you're impatient... Just be aware that they might not be built from release ready code.
Click to expand...
Click to collapse
I have the same issue as my Google Pay doesn't work now (after 16.3). Now I am on magisk 16.4.
I tried this Terminal command, su -c magiskhide --enable which returns that hide is already enabled.
My Google Pay was working normal now not working. By the way, SafetyNet test pass through.
smohanv said:
I have the same issue as my Google Pay doesn't work now (after 16.3). Now I am on magisk 16.4.
I tried this Terminal command, su -c magiskhide --enable which returns that hide is already enabled.
My Google Pay was working normal now not working. By the way, SafetyNet test pass through.
Click to expand...
Click to collapse
If you have MagiskHide working (passing SafetyNet), there's no need to mess with the enable command. That was just to confirm if the user has an issue where Magisk couldn't detect if logging was running (that's been fixed in v16.4).
Does Google Pay still work on Magisk v16.0? Or is it a matter of an update to Google Pay? What happens if you disable Telephone permissions for Google Play Services (like users of the Tez app have to do)? Or If you add all phone services you the Hide list?
Dreamer(3MF) said:
Send The Full Logcat Of Google Pay & Inform Me About The Installed Version Of Magisk.
Click to expand...
Click to collapse
Ok, I'm trying to get a logcat using terminal, but it keeps coming out at over 1mb, and xda won't let me attach a text file over 512kb. Shall i get it with adb with some filtering? I'm not very familiar with logcats, so your suggestion would be welcome.
I'm on the latest stable magisk: v16.0. For safetynet check, it successes, but ctsProfile, and basicIntegrity false.
I'm on a Nexus 6P, fully updated.