Executing magiskinit causes fatal crash on some devices

[sgs2ofameer]

I have the k20 pro indian global rom, so every thing was running smooth until latest MIUI 11 update, I installed magisk ( differnet versions 20.1, 20 and 19.7) using twrp and my device always boots back to recovery any advice??

[topjohnwu]

This same issue happens on latest Oneplus 7T, according to @osm0sis

[osm0sis]

Seems that way, unfortunately:

:/ $ magiskpolicy
 Bad system call
 159|:/ $ su
 :/ # magiskpolicy
 Aborted
 134|:/ # ls
 /system/bin/sh: /system/bin/ls: No such file or directory
 1|:/ # 

Then the global system shell is broken (see the ls command above) until a reboot. :face_with_head_bandage:

[androidacy-user]

Wtf is causing this? I assume the usual was attempted, eg selinux permissive, clean install, etc?

[skvalex]

Can confirm this bug for Galaxy S9+ with Android 10 beta (rooted stock). Also, got many reports from users of my app, mostly from devices with custom ROMs. Pixels have no issue.

[skvalex]

Here's the kmsg log:

<11>[  571.992710]  [5:       supolicy:30166] supolicy: mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC)) failed Device or resource busy
<11>[  571.992753]  [5:       supolicy:30166] supolicy: mount("sysfs", "/sys", "sysfs", 0, NULL) failed Device or resource busy
<11>[  571.992771]  [5:       supolicy:30166] supolicy: mount("selinuxfs", "/sys/fs/selinux", "selinuxfs", 0, NULL) failed Device or resource busy
<10>[  571.992823]  [5:       supolicy:30166] supolicy: Init encountered errors starting first stage, aborting

Even supolicy --help causes this problem:

$ adb shell
star2lte:/ $ su
star2lte:/ # supolicy --help
Aborted
134|star2lte:/ # ls
/system/bin/sh: /system/bin/ls: No such file or directory

[osm0sis]

Permissive also has no effect on the issue.

[auutlol]

works fine here mi 9t miui 11 eea and magisk 20.3

[Vanman989]

works fine here mi 9t miui 11 eea and magisk 20.3

What install method did you use? I assume itll work for global now

[auutlol]

works fine here mi 9t miui 11 eea and magisk 20.3

What install method did you use? I assume itll work for global now

Hey! i used the magisk manager to patch the boot.img from the ota file (https://xiaomifirmwareupdater.com/miui/) < --download the ota from here (select your miui type eea or global and whatever and select the same version) and then i rebooted to fastboot mode and tested it with fastboot boot magisk_patched.img (after pacthing with magisk manager it's located in downloads) after execute fastboot boot magisk_patched.img it should boot normal after that go to magisk manager and If it says installed go to fastboot again and type fastboot flash boot magisk_patched.img i hope that will help you ! :) sorry for that long text haha

EDIT 1 : i made a picture so you know what's miui type and miui version (somehow it changed to global but i never modified the type but the version code still says PFJ(EU)XM so it's still EEA weird)

[osm0sis]

I managed to get a useable full dmesg log of what happens during boot when simply magiskpolicy was attempted (as early as post-fs-data), and the good news is @topjohnwu thinks he knows what's going on, so stay tuned. :grin:

[osm0sis]

I can confirm @topjohnwu's suspicion that somehow the wrong init binary was being saved and linked to magiskpolicy, etc. on at least some 2-stage init (2SI) devices.

After booting my device I checked and /init is symlinked to /system/bin/init (which is likely the new normal), but then /sbin/.magisk/rootdir/init appears to be a copy of /system/bin/init (where it should probably be the ramdisk 1st stage init from /.backup/init), and /sbin/magiskinit appears to be a copy of the ramdisk 1st stage init. So no magiskinit anywhere! I'm surprised this isn't affecting more devices!

I added a post-fs-data.d script with the following and it got things working normally on my device until @topjohnwu can work out a proper fix; mileage may vary!

/data/adb/post-fs-data.d/magiskinitfix:

#!/system/bin/sh

cp -f /data/adb/magisk/magiskinit /sbin;

[skvalex]

I added a post-fs-data.d script with the following and it got things working normally on my device until @topjohnwu can work out a proper fix; mileage may vary!

Thanks! I have checked and it fixed the problem on my device too

[topjohnwu]

Fixed in commit ba55e2bc3288963d093b5fbd88f18c4622e3a43c

[Vanman989]

Awesome, Will this be implemented in v20.4?

[ccaapton]

I have a k20 davinci, using magisk canary debug version ce7cb1ee. I got the same bootloop problem. Changing busybox to 644 fixed the bootloop but magisk would be crippled.

I tried @osm0sis 's script: https://github.com/topjohnwu/Magisk/issues/2133#issuecomment-576095312 but it does not solve the bootloop problem.

I noticed @Vanman989 and @sgs2ofameer formated the data partition and got it fixed. But I'm reluctant to format. Did you guys format it as ext4 or f2fs? I noticed the stock miui 11 use f2fs + encryption on data partition, is it due to f2fs bugs?

@topjohnwu Below is a /cache/magisk.log. I could not find any problem in it, yet it reboots to recovery. How can I get more detailed information, like dmesg or init coredump?

--------- beginning of main
--------- beginning of system
09-24 00:59:28.114   606   606 I Magisk  : Magisk vce7cb1ee(20306) daemon started
09-24 00:59:28.114   606   606 I Magisk  : * Device API level: 29
09-24 00:59:28.125   606   607 D Magisk  : resetprop: getprop [ro.crypto.state]: [encrypted]
09-24 00:59:28.125   606   607 D Magisk  : resetprop: getprop [init.svc.vold]: [running]
09-24 00:59:28.135   606   607 I Magisk  : ** post-fs-data mode running
09-24 00:59:28.137   606   607 I Magisk  : * Initializing Magisk environment
09-24 00:59:28.157   606   607 I Magisk  : * Mounting mirrors
09-24 00:59:28.157   606   607 I Magisk  : mount: /sbin/.magisk/mirror/vendor <- /sbin/.magisk/block/vendor
09-24 00:59:28.157   606   607 I Magisk  : mount: /sbin/.magisk/mirror/data <- /sbin/.magisk/block/data
09-24 00:59:28.157   606   607 I Magisk  : link: /sbin/.magisk/mirror/system <- /sbin/.magisk/mirror/system_root/system
09-24 00:59:28.157   606   607 I Magisk  : link: /sbin/.magisk/mirror/product <- /sbin/.magisk/mirror/system/product
09-24 00:59:28.158   606   607 I Magisk  : * Setting up internal busybox
09-24 00:59:28.168   606   607 I Magisk  : * Running post-fs-data.d scripts
09-24 00:59:28.170   606   607 D Magisk  : magiskdb: query magiskhide=[1]
09-24 00:59:28.175   606   614 I Magisk  : * Starting MagiskHide
09-24 00:59:28.175   606   614 I Magisk  : hide_policy: Hiding sensitive props
09-24 00:59:28.175   606   614 D Magisk  : resetprop: getprop [ro.boot.verifiedbootstate]: [orange]
09-24 00:59:28.175   606   614 D Magisk  : resetprop: setprop [ro.boot.verifiedbootstate]: [green] by modifing prop data structure
09-24 00:59:28.175   606   614 D Magisk  : resetprop: getprop [ro.boot.flash.locked]: [0]
09-24 00:59:28.175   606   614 D Magisk  : resetprop: setprop [ro.boot.flash.locked]: [1] by modifing prop data structure
09-24 00:59:28.176   606   614 D Magisk  : resetprop: getprop [ro.debuggable]: [0]
09-24 00:59:28.176   606   614 D Magisk  : resetprop: getprop [ro.secure]: [1]
09-24 00:59:28.176   606   614 D Magisk  : resetprop: getprop [ro.build.type]: [user]
09-24 00:59:28.176   606   614 D Magisk  : resetprop: getprop [ro.build.tags]: [release-keys]
09-24 00:59:28.176   606   614 D Magisk  : hide_list: initialize
09-24 00:59:28.182   606   614 I Magisk  : hide_list init: [com.google.android.gms/com.google.android.gms.unstable]
09-24 00:59:28.184   606   614 I Magisk  : hide_list init: [org.microg.gms.droidguard/com.google.android.gms.unstable]
09-24 00:59:28.190   606   614 D Magisk  : proc_monitor: nothing to monitor, wait for signal
02-20 13:49:18.598   606   614 D Magisk  : proc_monitor: nothing to monitor, wait for signal
02-20 13:49:18.606   606   614 D Magisk  : proc_monitor: nothing to monitor, wait for signal
02-20 13:49:20.631   606  1132 I Magisk  : ** late_start service mode running
02-20 13:49:20.631   606  1132 I Magisk  : * Running service.d scripts

[osm0sis]

@ccaapton, it pretty clearly sounds like a different issue than this.

If you need any further help you should ask in the Magisk Discussion/Help thread on xda or start your own GitHub issue, but from your description it sounds like you might just have a rogue module or post-fs-data.d/service.d script. Make sure you're on the latest Canary, then try Magisk in Core Only/Safe Mode.

[ccaapton]

I just fixed my issue by copying the canary-manager apk file to /data/adb/magisk/magisk.apk . Turns out @androiddisk is right

According to the code below, the boot daemon will copy MANAGERAPK to /data/magisk.apk and install it, but if MANAGERAPK does not exist, the daemon will generate /data/magisk.apk out of the blue, but this file is much smaller than a real apk, thus may cause a big problem in the boot process.

if (access(MANAGERAPK, F_OK) == 0) {
        // Install Magisk Manager if exists
        rename(MANAGERAPK, "/data/magisk.apk");
        install_apk("/data/magisk.apk");
} else {
        // Check whether we have manager installed
        if (!check_manager()) {
                // Install stub
                exec_command_sync("/sbin/magiskinit", "-x", "manager", "/data/magisk.apk");
                install_apk("/data/magisk.apk");
        }
}

[osm0sis]

Again, that's a very different issue from the one we resolved above. Start a new issue with the information from your last 2 posts so that your issue can be properly looked into.

[Vanman989]

I can confirm @topjohnwu's suspicion that somehow the wrong init binary was being saved and linked to magiskpolicy, etc. on at least some 2-stage init (2SI) devices.

After booting my device I checked and /init is symlinked to /system/bin/init (which is likely the new normal), but then /sbin/.magisk/rootdir/init appears to be a copy of /system/bin/init (where it should probably be the ramdisk 1st stage init from /.backup/init), and /sbin/magiskinit appears to be a copy of the ramdisk 1st stage init. So no magiskinit anywhere! I'm surprised this isn't affecting more devices!

I added a post-fs-data.d script with the following and it got things working normally on my device until @topjohnwu can work out a proper fix; mileage may vary!

/data/adb/post-fs-data.d/magiskinitfix:

#!/system/bin/sh

cp -f /data/adb/magisk/magiskinit /sbin;

Would you be kind enough to explain how I do this and when in the process of installing magisk I do this to stop the recovery bootloop.

[Vanman989]

I just fixed my issue by copying the canary-manager apk file to /data/adb/magisk/magisk.apk . Turns out @androiddisk is right

According to the code below, the boot daemon will copy MANAGERAPK to /data/magisk.apk and install it, but if MANAGERAPK does not exist, the daemon will generate /data/magisk.apk out of the blue, but this file is much smaller than a real apk, thus may cause a big problem in the boot process.

if (access(MANAGERAPK, F_OK) == 0) {
        // Install Magisk Manager if exists
        rename(MANAGERAPK, "/data/magisk.apk");
        install_apk("/data/magisk.apk");
} else {
        // Check whether we have manager installed
        if (!check_manager()) {
                // Install stub
                exec_command_sync("/sbin/magiskinit", "-x", "manager", "/data/magisk.apk");
                install_apk("/data/magisk.apk");
        }
}

How do I see these file locations. Do you install magisk manager and then find those locations and move it? Sorry still learning

[osm0sis]

Would you be kind enough to explain how I do this and when in the process of installing magisk I do this to stop the recovery bootloop.

Just use the latest Canary. The bug described by this issue and my script has been resolved.

For any other problems people should start their own GitHub issue, since they're not the same.