modules_update.img doesn't get processed during initial KSU setup boot

[osm0sis]

Describe the bug
On non-GKI devices the AnyKernel3 installation zip for a KernelSU-supporting custom kernel may also require to change .ko kernel modules for feature support, and these could be needed for the device to boot correctly into the ROM.

This can normally be done with a Magisk/KernelSU helper module that AK3 creates during installation, however if it's the initial installation of KernelSU the modules_update.img doesn't appear to get processed during boot, and instead shows as a pending module until the next reboot.

Expected behaviour
During the initial KSU setup boot (i.e. when KernelSU itself is first installed), KernelSU should setup its /data/adb files and then look for an existing modules_update.img and process it as it normally would.

Smartphone (please complete the following information):

• Device: OnePlus 7T
• OS: Lineage 20
• Version: KernelSU 11191 + Manager v0.6.7 (11210)

Additional context
In case it's of use, I discovered this behavior while adding KernelSU helper module support to AK3 in osm0sis/AnyKernel3@4030d36 (see the NOTE at the bottom of the commit message).

[tiann]

KernelSU's module system can only work after it is initialized once after the manager is launched. If you only flash the kernel without launching the manager, the module will not work; in this case, there is no way to process modules_update.img.

If the manager has been initialized once and you want the manager to process modules_update.img instead of modules.img, you can create /data/adb/ksu/update: https://github.com/tiann/KernelSU /blob/main/userspace/ksud/src/event.rs#L132

[osm0sis]

Hmm, yeah I've already got the update flagged: osm0sis/AnyKernel3@4030d36#diff-703f70c41865bc8e07b7f5da93d9d052658d938a58435ee3f04f5df3a4e65794R422

So seems we've got a chicken-egg situation, unfortunately, where KernelSU processing the modules_update.img requires the app be run once while already rooted... I guess non-GKI device custom kernels may have to supply a more generic build for initial flashing, then once KernelSU is initialized they could get their users to switch to the more complex build which requires overlayed kernel modules to boot. 🤔

[tiann]

There is a workaround: pack the ksud to module and copy it to /data/adb. This is the only thing manager do now.

[osm0sis]

There is a workaround: pack the ksud to module and copy it to /data/adb. This is the only thing manager do now.

Ahah! Thank you for this clue, I think we can do one better and dump the ksud directly from the KernelSU Manager APK from recovery and then all will be seamless for custom KSU kernels that require the helper module to boot! 🤠

[osm0sis]

@tiann, I'm confused though.. if I can dump ksud before first install and the KernelSU app only needs to have been installed (and not even run) for me to dump that, and then it'll process the modules_update.img like normal, then couldn't KernelSU itself just do that during boot?

Edit: Oh wait, you need decrypted data to dump ksud, so that's too late to then use it to set up the overlays, of course! 🤦‍♂️🙃

[tiann]

@tiann, I'm confused though.. if I can dump ksud before first install and the KernelSU app only needs to have been installed (and not even run) for me to dump that, and then it'll process the modules_update.img like normal, then couldn't KernelSU itself just do that during boot?

This is of course possible, but we didn't know this was the case at the time; we are considering embedding ksud into the kernel image without relying on the manager. #130 #929