[Magisk] nisavid:
Workaround: Module install: Mounting /dev/magisk_merge fails

Workaround for module installation issue: Mounting /dev/magisk_merge fails

As I mentioned a few days ago (albeit somewhat vaguely), I encounter this issue—or a similar one—commonly when installing Magisk modules, and I have found a workaround that works for me reliably.

Issue: Module installation fails when mounting /dev/magisk_merge

[IMG="Greenify4Magisk module failing to install"]https://lh3.googleusercontent.com/U2tyMKmAEV9zwOxuNzf8DwyG19ntZ3eL1iuzdUI-rZttNvh-rZ2Bd1Ct3hTpk9nAxAgkNqaptHKKAMyauECUG_LndnvBZryTgGnEPLp7SThUukjnnUrqfTz0CcHJalHiBe465r91SdbfS6nLKZgWMCeSzVa4cjUtlERcveTJTaSgtwj3OpeNFQLbqHhWVijzVcIERtcudbCsC_MWoiQ4wdK54FCQykSXFsmoM7jofOsx354op7quSTvuZHI_ltM0hgB_9ZJdmUQ6qAmnPkGPyUVgxRo051JQgMD6OFXWSlrmmQ068DVjhjMOCNQabgAsazohXsYFS7NdPh32O_MLOKfF81J1zLFT9ZqPRwwOqKLlaLpbwZkYnioW7vTQ3TID5KO7JYjiPEDxN45pyaVFPIqnYholoNlCne-ab0mCcMgIRcOANdQcNOimPBhUIusJVDaDPJ9fczvhLOsIAe5ub6GO9pPkGbSn2t-n0Kjev56IwrVJ9J3WjVxmz2tc1G8L4u3T_F8l3pyWTHSpC63Pa1MdVyd7hhU87SP0rCcEmP_6F7aE_tQMuHL7VIm_mAmUrpoKWrtE3Xp1cTNzSKqYnZIHAFauf66dscFrpOMNXZHa0tpzccNssLEw-791kRgVJI-_S57-txSRkX1Nu59Z2_tn0Gw7NaCHawWc=w293-h521-no[/IMG]

Installing a module fails, showing the following messages at the end of the installer's output:

- Mounting /data/magisk_merge.img to /dev/magisk_merge
! /data/magisk_merge.img mount failed...
Failed!
Installation error!

The Magisk debug log at /data/magisk_debug.log provides slightly more detail:

mount /dev/block/loop1->/dev/magisk_merge failed with 22: Invalid argument

If your magisk_debug.log contains a different error message (for example, Permission denied instead of Invalid argument), you probably have a different issue, and the workaround below may or may not work for you.

Workaround: Install Busybox for Android NDK

The workaround is to (re)install Busybox for Android NDK, then (before rebooting) install modules that encounter this issue. Something about the Busybox module's installer leaves the system in a state that lets other modules avoid the issue, I can successfully install any number of modules that would normally fail due to this issue. Rebooting will reset the effect of the workaround; reinstall Busybox again before (re)installing more modules.

For example, if you're encountering this error when installing Greenify4Magisk, try this:

In Magisk Manager, install Busybox Installer for NDK (via Modules or Downloads). Verify that it succeeds. Tap Close.

In Magisk Manager, install Greenify4Magisk. Verify that it succeeds. Tap Close.

Repeat step 2 for each other module that you want to install.

Reboot.

[IMG="Busybox for Android NDK installing"]https://lh3.googleusercontent.com/GuMEQkBO1HIKchyjNBrYsNg0J7lnhp0I5eaqJBRD3rdxtMDka4-TeRsRPcs5L6cm_dRk1vROcCaqRKb7oWf5WVC6JvnPmbCyF404JyGYGdtG9AyBoXniVrdi0vabALwniBWpRV7G3mfTT3ivZpVETomyN3YSU5ehQx30qGs_3hPcbz5VDoXh2b3QMQWZsFkFZI2yvet2rgEAsaeifr9Qq1vWK1Wpl-XklMVwh55Mz6pk9T8O4Ttjqlj97qSRRIH8hT-yJtq5FKSUS0zjOmDp5YqpTe16H62asDqgZ4u_AtWZ-OgqWhl_ApCOd4KdUOpzGysVCFwQToilPPZYEUgUF3MHp2-GilDaHojP7kqgG0mt-c0eFYZI71S0Igtxqw9-vdALar1jMsMlC-lQbtUTi_9pME8r72UOtupulDBtepbCg5khJ9A2Jzpio7gW9Q7H8TvUm_n1tSMNUs1bQQAQA-VEYN0-IqAp26PmfJvqh4uIuuo2KTWktg97z9ySGjE9VPIKd1iXn42zHVkzoPr7zbNdSUYyJMisLsFQzNAoQXTUuy1LbuefhRaNyaZupU9HbBaNjWVxauuObHYXZDuB6kfXnNjsesdgO3VR0azkm_Szs6j1OhbTybaszGZSyy1yE3BO_aubs7bLKvzOgwilaufdPVNHR0OPaIjx=w293-h521-no[/IMG] [IMG="Greenify4Magisk installation succeeding"]https://lh3.googleusercontent.com/2X6R7pSgEbWcpvQ2tjuXx2QJMZcGYTHD_0Gad1bBHDn9JaPyUShz42ZN6RnnZ0lsIIf3TRlOBHNSQusYCETyG5-CKRK0R-muiz1Wi8KyDdiGgJy_p2CE4aLSvK-Cj6dDrpi2WUzzmpDUlcJ1H8TalPyfB-QcErtM2b5UWojHouykTRcRXI99-qb3LZZuJPsXM8ArRRCIzBU9jkdK9WULbTb_IZyH2ES3r0YEm-jtRR7NBS9Mw9K47i307NiZ6tt1pkc93qg5zkQLjkZ_Fjlr3CkziySFVXgU_vkIuQAoVOAyUW6n-kbN73YBUM-reCxxDm1ZAbK6_NoyQmfWqScgeCmH1T4eWxIDHHesSUksBN_tL6M6jyy_Nf6onkylpIAodASbt2RgSY5Ajgz3XzX2tflSWXSxqQPvIZzig4zO8ypx_Wjpu4Alm_x7b_vKEkoXuhMbtvDnFAkGvz2I5V56qaAh9i6DtHCgAzs5zIiUqZUJBLVg5tNYvXyVpBJXnIZzbpKw_rPLVffIatgr26B69B_kUAM3FxX8DA-sP9lTeZyBoYhNTWhw6U61eeG5UrJUjfI6MuwSCK1Zmj3PrMauI5Pj2wbGFr4qK4MBgP-GoF8=w293-h521-no[/IMG]

Troubleshooting

I'm not sure of the root cause of the issue, but I have found some clues. Note that I haven't developed Magisk modules and am not well versed in their internals or their installation procedure, so any deductions about those are speculative.

magisk_debug.log

Installing Greenify4Magisk

D(17555:17555) magisk_img: e2fsck 1.43.3 (04-Sep-2016)
D(17555:17555) magisk_img: Pass 1: Checking inodes, blocks, and sizes
D(17555:17555) magisk_img: Pass 2: Checking directory structure
D(17555:17555) magisk_img: Pass 3: Checking directory connectivity
D(17555:17555) magisk_img: Pass 4: Checking reference counts
D(17555:17555) magisk_img: Pass 5: Checking group summary information
D(17555:17555) magisk_img: /data/magisk_merge.img: 11/4096 files (0.0% non-contiguous), 1294/163
84 blocks
E(17555:17555) mount /dev/block/loop1->/dev/magisk_merge failed with 22: Invalid argument

Installing Busybox for Android NDK

No Magisk debug output. The Busybox installer's custom-written update-binary script does not invoke the magisk command.

Installing Greenify4Magisk after Busybox for Android NDK

D(21636:21636) magisk_img: e2fsck 1.43.3 (04-Sep-2016)
D(21636:21636) magisk_img: Pass 1: Checking inodes, blocks, and sizes
D(21636:21636) magisk_img: Pass 2: Checking directory structure
D(21636:21636) magisk_img: Pass 3: Checking directory connectivity
D(21636:21636) magisk_img: Pass 4: Checking reference counts
D(21636:21636) magisk_img: Pass 5: Checking group summary information
D(21636:21636) magisk_img: /data/magisk_merge.img: 350/4096 files (0.0% non-contiguous), 1654/16384 blocks

update-binary differences

The building and mounting of magisk_merge.img is coordinated by each module's update-binary script. Greenify4Magisk uses the exact version that is provided by Magisk Module Template version 1400. This version uses magisk --mountimg (implemented in Magisk's C code) to mount /dev/magisk_merge. Busybox for Android NDK, on the other hand, has an entirely custom-written version, which uses a shell-based approach to mount /dev/magisk_merge (via mount) and attach it to /data/magisk_merge.img (via losetup). As it turns out, this custom implementation meets greater success than the one built into Magisk.

I tried updating the Greenify4Magisk module to the 1410 template. This produced the same results.

I haven't dug into Magisk's mount_image() C code to look for functional differences compared to the Busybox script's mount/losetup shell code, but I suspect that the root cause lies somewhere therein.

It appears that the Busybox module's custom update-binary script not only avoids the issue that is encountered by magisk --mountimg, but it also leaves the system in a state that lets a subsequent magisk --mountimg avoid it. Perhaps [MENTION=4470081]topjohnwu[/MENTION] and [MENTION=4544860]osm0sis[/MENTION] can figure this out amongst each other.