LOS 17.1 Survival Script not working.

[stonerl]

I'm running Magisk 20.4 on an OnePlus 3 with encryption.

LOS 17.1 Build 20200412
LOS Recovery Build 20200412

After upgrading LOS with the built-in updater, Magisk needs to be installed manually again because it is not preserved.

I assume something is wrong with the script in adddon.d

[hotTeaFun]

LOS Recovery is surely useless as it doesn't support for many advanced functions. You may flash TWRP recovery to get it right.Hope it works.

[osm0sis]

It worked in LOS 16 Recovery via addon.d, and works with LOS 17.1 addon.d-v2 while booted, AND the upcoming TWRP addon.d-v2, so sounds like LOS 17.1 might have broken addon.d (v1) and they should probably look into that..

[stonerl]

Thank you for the reply. I'll get in touch with the LOS-devs.

[osm0sis]

Thanks, I'll look into it too once official LOS 17.1 is on one of my A-only devices.

[androidacy-user]

I can't get los recovery to flash anything here lol. Magisk zip says failed whole file verification (no TWRP available, device launched with 10)

[aleasto]

Magisk addon.d doesn't work on addon.d-v1 encrypted devices because it mandates the survival script to be launched from /data
https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh#L38
https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh#L33
The same issue would be present on TWRP (as long as you set a pin/password/pattern).

[topjohnwu]

@linuxandria if LOS recovery require verification, then no zips other than their own will work.
Anyways, this seems to be unsolvable, so closed

[aleasto]

Lineage Recovery does not require verification. It just warns if verification fails, and prompts the user to continue unverified.

[androidacy-user]

Lineage Recovery does not require verification. It just warns if verification fails, and prompts the user to continue unverified.

Idk why but here it says whole file verification failed then aborts. Nonstandard behavior but I have no idea why it happens. ADB is also crippled so you can't possibly get a shell without adding the right code

[stonerl]

Magisk addon.d doesn't work on addon.d-v1 encrypted devices because it mandates the survival script to be launched from /data
https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh#L38
https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh#L33
The same issue would be present on TWRP (as long as you set a pin/password/pattern).

Now that you mentioned it. I had the same problem with LOS 16.1 and TWRP.

[stonerl]

Lineage Recovery does not require verification. It just warns if verification fails, and prompts the user to continue unverified.

Idk why but here it says whole file verification failed then aborts. Nonstandard behavior but I have no idea why it happens. ADB is also crippled so you can't possibly get a shell without adding the right code

Here it says it cannot verify the zip, but lets me continue. But this is not the core problem of the issue.

So the problem is what @aleasto pointed out. Since data is encrypted it cannot be accessed. But this seems to be a problem with all encrypted devices, then. Regardless of the Recovery.

[aleasto]

Correct. I can imagine addon.d-v2 works because it happens in system, where data is unencrypted.

[osm0sis]

Yes, it's known that it won't work encrypted FDE since the OTAs use uncrypted storage, that's why the error display here exists: https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh#L29-L33

To be clear, nobody said addon.d-v2 was broken. I know it works since I test it regularly on my OP7Pro.

However, hopefully there isn't some regression here with addon.d (v1) since I did thoroughly test awhile back and do basic tests with unencrypted addon.d (v1) and addon.d-v2 leading up to each new Magisk release: e6bd5f2

[aleasto]

addon.d v1 unencrypted works fine here.

[stonerl]

So there is no possible solution to get this working with encrypted devices, then?

[osm0sis]

Perfect, that's what I saw with addon.d on my Nexus 7 2013 running Lineage 14.1 unencrypted as well. 👍

[osm0sis]

So there is no possible solution to get this working with encrypted devices, then?

Nope, never has been. We need the Magisk executables and they're only available with /data decrypted. Most we've ever been able to do is display that warning, though if Lineage Recovery doesn't display ui_prints then there's unfortunately no way to inform the user of the limitation, so some points to TWRP there.

[stonerl]

Thank you for the clarification.

[aleasto]

I was brainstorming with Lineage people if we could add an addon.d stage to allow copying the necessary files to /cache before rebooting to recovery for the OTA, which in the case of magisk would be its scripts and busybox.

It would only work for devices with /cache of course, but it would be an improvement in compatibility.
Thoughts?

[stonerl]

Not sure, but maybe have a look at OpenGApps? Their script does work on encrypted devices.

https://github.com/opengapps/opengapps/blob/1c4f5340a1348cc12b5f98718a6e2ec42c92f418/scripts/bkup_tail.sh#L29-L41

[osm0sis]

Not sure, but maybe have a look at OpenGApps? Their script does work on encrypted devices.

https://github.com/opengapps/opengapps/blob/1c4f5340a1348cc12b5f98718a6e2ec42c92f418/scripts/bkup_tail.sh#L29-L41

Well yeah, they don't require binaries to modify a boot partition, like I just explained to you.

[osm0sis]

I was brainstorming with Lineage people if we could add an addon.d stage to allow copying the necessary files to /cache before rebooting to recovery for the OTA, which in the case of magisk would be its scripts and busybox.

It would only work for devices with /cache of course, but it would be an improvement in compatibility.
Thoughts?

Sounds good to me. The only other option is Magisk copying more things into /system at install time, which of course would have free space issues and defeat the purpose of trying to keep it all centralized and in sync with /data/adb/magisk as the only location.

[osm0sis]

@aleasto, ooh crazy idea here, what about copying necessary files into uncrypted storage with the OTA and dump them out from there? Would be totally badass and no deprecated /cache required.

Showing ui_prints in your recovery during OTA would be nice too. 🙂