So ... I dug a bit deeper into what was going on.
It turns out that because our device is 32bit, it uses an older kernel zImage format despite using A/B partitions and newer the Two-Stage-Init, System-As-Root boot process.
That zImage format looks like: "Header" -> "zImage" -> "Footer"
The header consists of a binary loader that is used to both decompress the gzip'ed image and boot the kernel, as well as a listing of offsets within the file to other important bits like the signature and Device Tree Blob, or (DTB).
Once you decompress the actual zImage and patch it, there's no guarantee that it will re-compress back down to the exact size of the previous one.
If it's not the same size, then all the offsets to the other bits of the boot image get out of sync.
On top of that, topjohnwu says that it's too difficult to generically fix up the offsets across all the phones that might use this scheme, so he's
not going to fix it.
Apparently, someone put in a bug report for the G7 Play before, and that
was closed over a year ago for basically the same reason.
So I decided, why not try to get the re-compressed zImage to exactly match the original and see what happens.
To do this I used:
Android Image Kitchen by
@osm0sis
A capable hex editor
7zip
I started by unpacking the boot.img with AIK.
I then used my hex editor to extract the gzip'ed kernel.
You can usually recognize a gzip file because it starts with 0x1F8B08.
Finding the end of the gzip file is a bit more tricky, since AFAIK, they don't all end the same way. You could likely parse the offset out of the gzip header, but for me it was just faster to look for a likely end of the file, extract to that point, then test it with 7zip. Once you get no errors out of 7zip, you've found the end.
Now you can extract the actual compressed kernel and search for "skip_initramfs" and replace it with "want_initramfs".
Then use gzzip.exe from the AIK to compress it back down using "gzip.exe -9 -n cKernel" and check its file size.
If it's an exact match, you're almost done. If not, we're going to have to do some more work.
Gzip is fairly consistent. So if you're only a few bytes off, you'll need to change a few things in your uncompressed kernel that don't really matter. Datetime stamps are good for that, because nobody really cares exactly what time it was compiled. So, since I was only 1 byte short of an exact match, I added some complexity to the timestamp, so now it reads "Tue Sep 29 19:59:49 CDT 2020". If you need less bytes, try reducing the complexity of the timestamp, like "Tue Sep 29 00:00:01 CDT 2020" instead.
Now that we've got a re-compressed kernel, insert it back into the zImage file, replacing the existing one.
When that's done, we re-pack the boot image using AIK with: repackimg.bat --original
The "original" option just means "don't rebuild the ramdisk". Since we didn't change it, we don't need to.
Now you can use Magisk Manager to build the image using the "recovery" option against your newly packed image.
Then do a "fastboot flash boot magisk_patched.img" and reboot normally.
If that seems like a bit of work; It is. So I can understand why it would be difficult to implement directly into Magisk.
That said, I'll follow the ticket I put in and see why it's not at least generating an error.
This is especially problematic considering that the option to force Recovery Mode seems to now be missing if a ramdisk is detected.
If all this seems outside your comfort zone or skill level, I get that too.
That's why I did the work and saved you the trouble:
https://androidfilehost.com/?fid=10763459528675594222
This boot image is from RETUS_10_QPYS30.85-23-3 and is pre-flashed with Magisk 21.1
It may work on other variants with patch level 2020-10-01, but I can't guarantee that.
Worst case, just re-flash your already working "Recovery Mode" patched image.
Once flashed (if it works for your variant), Magisk will be active on a normal reboot.
Unfortunately, it also overrides the Moto Recovery mode, so you probably shouldn't take an OTA with it.
Note that I will likely not be updating these images, as my primary phone is a Pixel 5.
This is why I have outlined the steps required to reproduce the work.
