Asking for help/reporting bugs
Asking for help
If you can't fix the problem yourself, start by looking in the support thread where you might find that someone else have had this problem as well. Search for your device and/or problem. If you can't find anything (it's a big thread), search again. If you still can’t find anything, provide as much information as possible (in the support thread). For example:- Detailed description of the issue and what you've tried so far, what has worked and what hasn't (as an example, did you test MagiskHide?).
- Details about your device, Android version, ROM, custom kernel, mods, etc.
- Logs! A bug report or a report about some kind of issue that is not accompanied by logs will likely be ignored. Always provide logs! And when providing logs, do NOT paste them into your post. Attach as a file or upload the file somewhere and provide the link. If you can't provide logs for some reason, at least try to give detailed instructions on how to reliably reproduce the issue.
Reporting a bug
When reporting a bug, make sure you have the latest Canary bleeding edge build installed on your device. Otherwise any bug you're reporting may already be fixed upstream. It will also have much more detailed logging enabled (see below).All bug reports should be made on the the Magisk Github repo. The same tips that are outlined above apply.
Logs
But what if I can't get logs?
Most of the time you can get some kind of log showing what is going on. Keep reading below to see what tools you have at your disposal.But, if you really cannot get hold of any logs at least try to give as detailed instructions as possible on how to reliably reproduce the issue.
Which log?
Certain issues require different kinds of logs. Here's a list of examples (see further down for details on how to acquire the logs in question), but it's far from a complete list and only meant as an example of what logs may be useful:- Installation of Magisk or modules fail - If installing from recovery, you'll need the recovery log and if installing from the Magisk app you need to save the installation log.
- Magisk/modules/MagiskHide isn't working as it should - The Magisk log should as a rule always be included whenever there are issues with Magisk core features. Some modules provide their own logging for if there are issues (see the specific modules thread/documentation).
- The Magisk app crashes - A logcat when the crash occurs will be necessary.
- Other apps/my system are/is misbehaving/crashes - A logcat showing the issue will be necessary.
- The device randomly reboots - After the reboot, grab the console-ramoops and/or last_kmsg.
- The device doesn't boot/bootloops - A logcat during boot (either through ADB or a boot script) or dmesg are the only thing that really could show what's going on. A Magisk log might be good for complementary information.
- The device only boots to bootloader/recovery - After the reboot, grab the kmsg file.
- Something doesn't work right -If something about your system or Magisk just doesn't work right, a dmesg or boot logcat might show what's wrong.
- Etc...
Get the log
- Recovery log from installation (in TWRP, go to Advanced - Copy log). If you experience errors when installing Magisk or modules through recovery. Note that this log HAS to be saved right after you've done whatever you're trying to save a log of. If you reboot inbetween there is a good chance that the info will be lost. The log might still be found in /cache/recovery after rebooting, but any subsequent reboots to recovery will overwrite the relevant information.
- Installation log from the Magisk app (press "Save log" after installing Magisk or a module). If you experience errors when installing Magisk or modules in the Magisk app.
- Magisk log save from the Magisk app or in /cache (or /data/cache on A/B devices) through recovery if you don't have root access. If the log is empty, see "The Magisk log is empty" below. Note that when reporting about issues and bugs it is required to use verbose logging (see "Verbose logging" below).
- Logcat. Grab it via ADB, an app or a logcat bootscript (see below). It might be a good idea to start by clearing the log so you don't end up with a lot of useless info before whatever you're trying to catch; "logcat -c" with ADB and there's usually an option for it in the app. Useful when other parts of the system are aren't working properly or if it's something that doesn't show up in the Magisk log. Also immensely useful if the Magisk app is crashing or having other issues. If you can't get root access it's easiest to hook up your device to a computer and use ADB. If your device isn't booting, it might be possible to grab a logcat during boot with ADB.
- Logcat boot script. This is useful if your device won't boot for some reason, or if you're experiencing other boot related issues. The script might even work when ADB logcat doesn't (since ADB won't work until later in the boot process). Place a file (doesn't matter what you name it) in /data/adb/post-fs-data.d, give it execution permission and put the following code snippet in it (thank you jenslody and jcmm11 for help with the script). Tip: press the "Grab" button below the code block to download a file ready to be renamed and placed in post-fs-data.d.
#!/system/bin/sh { logcat -f /cache/bootlog.log & sleep 30 kill %1 Loc='/data/media/0' until [ -e ${Loc}/testx ] do sleep 1 touch ${Loc}/testx done rm -f ${Loc}/testx [ -e ${Loc}/bootlog.log ] && mv -f ${Loc}/bootlog.log ${Loc}/bootlog_last.log cp -f /cache/bootlog.log ${Loc}/bootlog.log rm -f /cache/bootlog.log exit } &
- dmesg Can be run directly from the device or through ADB, but root is necessary. The command is simply "dmesg > /sdcard/dmesg.txt" (or whatever path you want to use or file name you want to give it). If running through ADB, put "adb shell su -c" in front of the command.
- Module log Sometimes modules have their own set of logs that might be useful when troubleshooting issues with a particular module. See the module documentation for details.
- console-ramoops If experiencing random reboots, the console-ramoops file, found in /sys/fs/pstore, might show what's going on.
- kmsg/last_kmsg If experiencing random reboots or booting to bootloader/recovery, the kmsg files, found in /proc, might show what's going on.
Verbose logging
When reporting about issues and bugs, it's useful to have more verbose logging. To get the most information possible, make sure to install the Canary bleeding edge build. It has debug logging active and will show much more useful information. The log is then saved just as the normal Magisk log, described above. When reporting about Magisk bugs, this is a requirement.The Magisk log is empty
If your Magisk log is empty, it's likely that you have Android logging disabled. Try enabling it.Could also mean it's faulty somehow. Try grabbing a logcat and see what happens (see above).
It might also be that your kernel/ROM wipes the /cache directory during boot, thus removing the log. See here for details.