[Magisk] tdhite:
Code Error -- Recovery based Create Image can Never Work!

I have another code issue (no logs needed -- again, code is herein). I may issue a PR against this to the extent I have time to build/test/etc. If someone else wants to take what I discuss below and issue a PR against it, feel free, but it's not a simple fix.

The issue is this: because the magisk binary is effectively unaware of the environment in which it executes, commands will fail in recovery though may work in normal Android boot. However, the expectation remains that recovery based flashing will work, which it does in some cases, but only because recovery flashes are getting lucky.

The issue I ran in to is this: recovery *cannot* create or resize the magisk image due to running in TWRP and depending on /system/bin/??? binaries, in particular, /system/bin/make_ext4fs and /system/bin/resize2fs. These are not correct for recovery based operations on most *if not all* TWRP recoveries; /sbin/make_ext4fs and /sbin/resize2fs are the correct binaries.

The culprit code is here (which totally assumes *non-recovery binaries*): https://github.com/topjohnwu/Magisk...96efa3ec775109a5b5/native/jni/utils/img.c#L63 and https://github.com/topjohnwu/Magisk...6efa3ec775109a5b5/native/jni/utils/img.c#L108

When that causes in recovery (in my case, some devices may or may not work, depends on your luck level):

~ # /system/bin/make_ext4fs
CANNOT LINK EXECUTABLE "/system/bin/make_ext4fs": cannot locate symbol "canned_fs_config" referenced by "/system/bin/make_ext4fs"...
Aborted
~ # /system/bin/resize2fs
CANNOT LINK EXECUTABLE "/system/bin/resize2fs": cannot locate symbol "__write_chk" referenced by "/system/bin/resize2fs"...
Aborted

Therefore, a recovery based flash can *never* safely believe in creating or resizing a magisk image, though that is a necessary functionality for *any* module. Module flashes may fail due to resize failure; worse kernel bootstrap modules, debloating modules (so first boot of Android does not install all the bloat that the debloating modules actually seek to prevent), etc. may never really work well at all (create image is necessary to do that correctly in recovery, not after a Magisk altered Android boot.

One might also think that recovery based image create/resize was not intended, but that cannot be the case due to this module template code: https://github.com/topjohnwu/magisk...INF/com/google/android/update-binary#L97-L101

That is specifically attempting to modify the size of the image, or create it, based on this code: https://github.com/topjohnwu/Magisk/blob/master/scripts/util_functions.sh#L361-L375

The is actually a pretty bad bug that has plagued for module writers for a while, I just finally took the time to dig in to figure out the true issue.

The fix? The magisk binary will need to make two attempts at exec'ing commands: 1) where recovery expects them (/sbin/???); or failing that 2) where standard Android expects them (/system/bin/??? at a minimum; could be other paths). In the latter case, if binaries in standard Android boots are found at /sbin, they are correct, and where not, generally /system/bin/??? is correct (often the target of links in /sbin anyway).

Just FYI for folks having troubles with things. This is also another 64->32 bit conversion issue, which makes for a more difficult issue: LD_LIBRARY_PATH is set on running the magisk binary, which would pass through to the child process, thus causing linkage errors. :(