Magisk fails on Huawei devices since 28102: installed state not detected

[SkipM4]

On Huawei devices, Magisk has not been working properly since build 28102.

After patching the ramdisk partition , flashing the image and reboot, the Magisk app does not show installed version.

If SELinux is set to permissive, the app does show as installed version , but root authorization still does not work — Magisk cannot properly trigger or handle root requests.

HWCET:/ $ su
Permission denied
13|HWCET:/ $

Steps to reproduce:

Patch the ramdisk partition with Magisk.
Flash the patched image.
Reboot the device.
Open the Magisk app and check its status.

Expected behavior:
Magisk should remain detected as installed after reboot, and root authorization should work normally.

Actual behavior:

With enforcing SELinux: Magisk app shows Not installed.
With permissive SELinux: Magisk app shows as installed, but root authorization does not work.

Device: Huawei Mate 50
Android version: 12
Magisk version name: 30.7
Magisk version code: 30700

logs.zip

[canyie]

How did you unlock its bootloader?

[SkipM4]

How did you unlock its bootloader?

Engineering machine

[jhooaa80-hue]

29.0

[dushane-smith]

digital glass

…

On Mon, Jul 20, 2026, 9:43 PM jhooaa80-hue ***@***.***> wrote: *jhooaa80-hue* left a comment (topjohnwu/Magisk#9950) <#9950 (comment)> 29.0 — Reply to this email directly, view it on GitHub <#9950?email_source=notifications&email_token=ADMYDDC5MSMFTCMIPQMTVO35F3DEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSHEZDKOBWGU22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5029258655>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMYDDHMNHKPYHLBZJZGLJL5F3DEDAVCNFSNUABEKJSXA33TNF2G64TZHM3DONZQGIYTQNB3JFZXG5LFHM2DQNRXGE3DCNBXGOQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADMYDDAPVGDMWWJ3WHIDCQD5F3DEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSHEZDKOBWGU22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/ADMYDDGFSRE2B6CIHY7D5RD5F3DEDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSHEZDKOBWGU22M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Buer-Nahida]

Try /debug_ramdisk/su, if it works, then I meet the bug as same as you.

This bug also happens on my Huawei Honor 9 Youth (LLD-AL10 also hi6250) with CrDroid ROM. (It was subsequently determined that the issue was not caused by that custom ROM)

I created a module by using AI to fix it (Remount /debug_ramdisk/magisk to /system/xbin/magisk, not a good idea but it works), if you need it, here is the repo's link https://github.com/Buer-Nahida/hi6250-magisk-bin-fix

I'll add more details and the troubleshooting process later.

[Buer-Nahida]

Note

Sorry for my bad English, it's not my native language, there are many technical words I don't know, I complete this comment with the translator together.

The Magisk binary injection is initially successful, but during the post-fs-data cleanup phase, the mount for /system/xbin/magisk is removed, finally re-exposing the original zero-byte placeholder file in the /system/xbin/.

Device Info

• Device: Honor 9 Lite / LLD-AL10
• SoC: Kirin 659
• Kernel: 4.9.148
• Vendor: EMUI 9.1 / Android 9 / VNDK 28
• System: Project Treble + A-only + system-as-root + ARM64 GSI
• Magisk: 30.7
• Installation: recovery mode, patch recovery_ramdisk, flash it in fastboot
• Zygisk: Disable
• Magisk DenyList: Disable

Symptoms

Running su from a normal ADB：

$ su
/system/bin/sh: su: can't execute: Permission denied

The relevant files look like this:

/debug_ramdisk/magisk
mode=755
size=394232

/system/xbin/magisk
mode=000
size=0

/system/xbin/su -> ./magisk

Therefore, /system/xbin/su points to a mode 000, size 0 placeholder.

Manually remount it can restores root access:

mount --bind /debug_ramdisk/magisk /system/xbin/magisk
/system/xbin/su -c id

Output:

uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

So the magiskd and the SU daemon are still work, but the mountpoint of magisk has been lost.

Mount timeline

I disabled the automatic repair script and left only a mount watcher and raw syscall tracing enabled, all magisk modules also disabled.

The watcher confirms that the original /system/xbin/magisk mount is created successfully and back to a zero-byte file later.

Mount timeline

watcher started: Sat Aug  1 10:13:09 +08 2026
pid=1028 namespace=mnt:[4026531840]

===== transition =====
uptime=42.85 iteration=0
initial-state-that-cannot-match -> mounted:107
mode=755 size=394232 inode=10823 device=17 path=/system/xbin/magisk

107 105 0:17 /magisk /system/xbin/magisk ro,relatime shared:11 \
    - tmpfs magisk rw,seclabel,mode=755

===== transition =====
uptime=47.24 iteration=79
mounted:107 -> plain
mode=0 size=0 inode=22360 device=23 path=/system/xbin/magisk
no mountinfo entry

===== final =====
mode=0 size=0 inode=22360 device=23 path=/system/xbin/magisk

The watcher is a shell process and was delayed by trace processing and repeated /proc reads, kernel timestamps from the raw syscall trace below are more accurate.

Raw syscall trace

This kernel provides：

/sys/kernel/tracing/events/raw_syscalls

I traced the native ARM64 mount and umount2 syscalls, and the relevant calls were all issued by:

exe=/debug_ramdisk/magisk
cmdline=magiskd
context=u:r:magisk:s0
namespace=mnt:[4026531840]

Relevant syscalls

magiskd-1015 ... 42.785355:
sys_enter: NR 39 (..., 2, ...)

magiskd-1015 ... 42.830477:
sys_exit: NR 39 = 0

magiskd-1015 ... 42.830504:
sys_enter: NR 40 (0, ..., 0, 44000, 0, ...)

magiskd-1015 ... 42.830529:
sys_exit: NR 40 = 0

magiskd-1015 ... 42.830532:
sys_enter: NR 39 (..., 2, ...)

magiskd-1015 ... 42.881959:
sys_exit: NR 39 = 0

On ARM64：

NR 39 = umount2
NR 40 = mount

umount2 flags 2 = MNT_DETACH
mount flags 0x44000 = MS_PRIVATE | MS_REC

Before the second umount2, the caller's mount namespace still have:

105 19 0:23 /system/xbin /system/xbin ...
107 105 0:17 /magisk /system/xbin/magisk ...
108 105 0:17 /magiskpolicy /system/xbin/magiskpolicy ...

After the second umount2 returned 0, the next mountinfo is:

105 19 0:23 /system/xbin /system/xbin ...
106 105 259:4 /system/xbin/empty /system/xbin/empty ...
108 105 0:17 /magiskpolicy /system/xbin/magiskpolicy ...

In other words:

/system/xbin/magisk: disappeared
/system/xbin/magiskpolicy: remained mounted
/system/xbin parent tmpfs: remained mounted

Correspondence with the Magisk source sequence

In Magisk 30.7, post_fs_data() calls:

self.handle_modules();
clean_mounts();

The order is:

module_mnt.unmount();

worker_dir.set_mount_private(true);
worker_dir.unmount();

The syscall sequence captured on the device matches this exactly:

umount2(MNT_DETACH)
mount(MS_PRIVATE | MS_REC)
umount2(MNT_DETACH)

Based on the evidence above, I can confirm the following:

1. inject_magisk_bins() initially creates /system/xbin/magisk successfully.
2. The mount is not being removed by Zygisk, DenyList, PHH, Magisk modules, or another long-running userspace daemon.
3. The mount disappears after the cleanup calls issued by magiskd, corresponding to clean_mounts().
4. Only the magisk child mount is lost. The magiskpolicy mount and the parent /system/xbin mount remain present.

I still cannot determine whether this is caused by the Magisk mount topology itself, an old Huawei kernel behavior involving MNT_DETACH and mount propagation, or an interaction between both.

Factors already excluded

Zygisk Next、Sui and Play Integrity Fix (Magisk Modules)

During the boot, they were not running, but the issue still reproduced.

I also tested the Zygisk Next service-stage separately. A manually created probe bind mount remained intact before the script, immediately after the script, and for another 20 seconds.

Built-in Magisk Zygisk and DenyList

The Magisk database contains:

key=zygisk|value=0

The CLI reports:

Denylist is not enforced

There are historical entries stored in the DenyList database, but enforcement is disabled and no DenyList unmount activity occurred during the failing boot.

Mount namespace mismatch

The following processes were all in the same mount namespace:

init      mnt:[4026531840]
magiskd   mnt:[4026531840]
watcher   mnt:[4026531840]
ADB root  mnt:[4026531840]

Therefore, this is not a case where the mount exists only in a private Magisk namespace and is invisible to ADB.

PHH dynamic root

The GSI does contain phh-root.sh, but it runs much later during boot, and the /system/xbin/magisk mount is lost during the end of post-fs-data, well before the PHH dynamic root event.

Simple child-namespace umount propagation

I also tested lazy-unmounting /system/xbin/magisk from a private child mount namespace. The mount disappeared from the child namespace but remained present in the global namespace.

This test does not reproduce the exact shared propagation topology used by Magisk, but it shows that a normal private-child unmount does not by itself explain the global mount loss.

Minimal reproduction test

I constructed a simplified worker mount tree:

1. Created a separate tmpfs worker.
2. Bind-mounted magisk and magiskpolicy into the worker.
3. rbind the worker into another target directory.
4. Applied MS_PRIVATE | MS_REC to the worker.
5. umount -l worker。

In this simplified test, both the target magisk and magiskpolicy mounts remained intact.

Therefore, the issue is not simply that any worker lazy-unmount always removes the target mounts. It appears to require the actual Magic Mount topology created by Magisk, the Huawei legacy kernel, or both.

Current workaround

My temporary workaround is to restore the lost bind mount after clean_mounts() finishes:

mount --bind /debug_ramdisk/magisk /system/xbin/magisk
mount -o bind,remount,ro /system/xbin/magisk

This does not modify the system partition, recovery image, Magisk database, or kernel, only restores the missing bind mount for the current boot.

My assessment

At minimum, this appears to be a compatibility issue between Magisk Magic Mount and an older Huawei kernel. The trigger has been narrowed down to the cleanup stage performed by clean_mounts().

Because the simplified mount tree does not reproduce it, I don't want to describe it as a purely kernel-independent Magisk logic bug yet.

I also compared the relevant code against the current master branch on 2026-08-01. The relevant logic in post_fs_data(), clean_mounts(), and Magisk binary injection still appears unchanged from 30.7, and I did not find a fix for this specific condition.

But I have some questions

Could this be the same class of Huawei-specific problem reported in this issue? If not then could I need open a new issue?

Is there a recommended debug or canary commit that I should test? I can retest if the maintainers needs it.

Would it make sense for Magisk to verify after clean_mounts() that the injected magisk and magiskpolicy mounts are still present?

And

I can provide the full syscall trace, complete mountinfo snapshots, and the diagnostic scripts if needed.

Note

Sorry for my bad English, it's not my native language, there are many technical words I don't know, I complete this comment with the translator together.

[canyie]

@Buer-Nahida your issue looks more likely to be a distinct issue. i think in case of #9950 the su binary being called is correct, but for some reason it outputs permission denied. maybe it's better to file a new issue.
also, I think it's ok to speak Chinese here

[Buer-Nahida]

@Buer-Nahida your issue looks more likely to be a distinct issue. i think in case of #9950 the su binary being called is correct, but for some reason it outputs permission denied. maybe it's better to file a new issue. also, I think it's ok to speak Chinese here

@canyie thanks for your reply, I'll open a new issue later.

[canyie]

@SkipM4 Looks like the logs are collected on release builds, which does not contain enough info. Please switch to debug builds and re-grab log.
I am currently thinking it to be a regression of c9eac0c. That commit switched sepolicy strategy for 2SI devices to only use LD_PRELOAD, which seems to be broken on your device (different function signature? #6296). Please also upload /system/bin/init.
I may also directly talk to you via Telegram 😸

[SkipM4]

@SkipM4 Looks like the logs are collected on release builds, which does not contain enough info. Please switch to debug builds and re-grab log. I am currently thinking it to be a regression of c9eac0c. That commit switched sepolicy strategy for 2SI devices to only use LD_PRELOAD, which seems to be broken on your device (different function signature? #6296). Please also upload /system/bin/init. I may also directly talk to you via Telegram 😸

Yeah I'd like to patch ramdisk via debug version but after the patch it would become 2.23MB size instead of 2.00MB which is greater than the partition itself so I can not flash it in,so I can only patch via release apk

And here is the init from system/bin (init is the original one,init-perm is the one I modified via IDA to boot in selinux permissive mode to get logs)

init.zip

[canyie]

It looks like security_load_policy and related functions get compiled into the executable and thus unable to be hooked by LD_PRELOAD. Not sure what is the proper way to handle that case, maybe we should hook __write_chk instead? 🤔

[Buer-Nahida]

@Buer-Nahida your issue looks more likely to be a distinct issue. i think in case of #9950 the su binary being called is correct, but for some reason it outputs permission denied. maybe it's better to file a new issue. also, I think it's ok to speak Chinese here

@canyie thanks for your reply, I'll open a new issue later.

@canyie sorry to bother you, I finally found that's not an issue about Magisk, it's an PHH root's issue

on my device:

/system/xbin/su -> ./magisk
/debug_ramdisk/magisk

but the /system/bin/phh-root.sh only check the /sbin/magisk:

  if [[ "$prop_value" != "0" && "$prop_value" != "1" ]] || [ -e /sbin/magisk ]; then
    stop sudaemon
    rm -rf /data/su || true
    exit 1
  fi

and if the persist.sys.phh.dynamic_superuser == 0, it'll run

phhnoroot() {
  blockdev --setrw /dev/block/mapper/system
  mount -o rw,remount /
  stop sudaemon
  rm -rf /data/su || true
  umount /system/xbin/su # <-- That's why the su has been umounted
  rm -rf /system/xbin/su
  pm disable me.phh.superuser
}

finally I wrote phh-magisk-su-guard to fix it.