Nothing installed in Lineage /system/addon.d/ via Magisk app Direct Install + fix_env

[mdoggydog]

I installed Magisk by using the "patch boot.img and flash with fastboot" method, since the installation instructions say that using the installer zip via a custom recovery is no longer recommended. On the next LineageOS OTA update, Magisk was not preserved, and I had to manually patch the boot.img and flash with fastboot again.

I discovered that /system/addon.d/99-magisk.sh was never installed, thus the OTA update would have no way to preserve Magisk.

Digging through the code, it appears that /system/addon.d/99-magisk.h is only installed when a Magisk installer zip is used via a custom recovery.

A related problem: even if Magisk is initially installed via installer-zip/custom-recovery, it appears that updating Magisk via the MagiskManager app will never update an existing /system/addon.d/99-magisk.sh either.

This issue is basically a duplicate of #3782, which I think got prematurely closed because I did not explain the problem well enough the first time. Please see my last comment in #3782 for more analysis of this problem.

[osm0sis]

It's supposed to install at some point via the app Direct Install too:

Magisk/app/src/main/java/com/topjohnwu/magisk/core/tasks/MagiskInstaller.kt

Lines 133 to 134 in cd96454

	// Extract scripts
	for (script in listOf("util_functions.sh", "boot_patch.sh", "addon.d.sh")) {

There was a plan to remove the unneeded installer code duplication and have everything run and maintained in one place via the shell scripts, but I'm not sure where that's at now.

[mdoggydog]

Yep... all the bits are there. This probably needs just a one- or two-line fix MagiskInstaller.kt, along the lines of cp /data/adb/addon.d.sh /system/addon.d/99-magisk.sh spelled the correct way (well, after testing if the /system/addon.d/ directory exists). But maybe there is some tricky subtlety involving security contexts or file ownership or something; this android system-level stuff is all new to me.

Half of the lines of code in

Magisk/scripts/flash_script.sh

Lines 78 to 85 in b6643b7

	if [ -d /system/addon.d ]; then
	ui_print "- Adding addon.d survival script"
	blockdev --setrw /dev/block/mapper/system$SLOT 2>/dev/null
	mount -o rw,remount /system || mount -o rw,remount /
	ADDOND=/system/addon.d/99-magisk.sh
	cp -af $COMMONDIR/addon.d.sh $ADDOND
	chmod 755 $ADDOND
	fi

are just ensuring that the target directory exists and is writable; I don't know if the writeability is an issue outside of the recovery environment.

[osm0sis]

So looks like this was intentional. John said "I do not want to involve system rw at anytime during boot. This just opens up a whole can of worms..."

I won't close this as #wontfix since he may still change his mind. It would just need to use Magisk's own system mirror and rw it if the addon.d directory exists. 🤞

[mdoggydog]

I'm sorry if I'm missing something, but I just don't understand that comment in the context of this bug report, which is about install-time not boot-time. The essential core of this issue is:

• If your device's OS has a /system/addon.d/ directory, then:
  • If Magisk is installed via installer .zip in recovery, then 99-magisk.sh is installed.
  • If Magisk is installed via Magisk app (MagiskInstaller.kt), then 99-magisk.sh is not installed.

That means that some devices out there are getting 99-magisk.sh and some are not, and it only depends on how the user decided to install Magisk (and in neither case does this installation happen at boot time).

How does "system rw at anytime during boot" come into this?

[mdoggydog]

(To rephrase again: logically, either 99-magisk.sh should be installed, or it shouldn't, so either MagiskInstaller.kt has a bug, or the .zip installer has a bug. And people installing via the .zip do not seem to be complaining....)

[osm0sis]

He means "while booted", hopefully that clears up the context for you.

[mdoggydog]

Ohhhhhhh! Yes, that clears it up a lot! Thank you! I now understand why it is the way it is right now.

It would be really nice if this difference between the two installation methods was mentioned in the installation documentation (https://topjohnwu.github.io/Magisk/install.html), because it is a pretty significant difference in behavior for a ROM that supports addon.d. One way, Magisk magically survives future OTA updates; the other way, the user has to manually intervene before the next reboot....

(In any case, at least the next confused schmuck like me that is trying to figure out what is going on will have this bug report to stumble upon. :^))

[Tremolo4]

Could this issue appear as well when updating magisk through the app, after having initially installed via zip?

And is the only result that Magisk is not installed after the update?

Context: Me and other users of my device (beryllium) recently started getting bootloops after each system update. Reflashing the same system update (1), opengapps (2) and Magisk zip (3) fixes it, I'm trying to rule out Magisk.

I'm thinking maybe we were getting the bootloops because of an outdated 99-magisk.sh, since it was never updated during magisk update via magiskmanager.

[twu2]

please re-open issue #3908 , I think it's different issue with this.

[outloudvi]

Hi. Just reporting that the survival script worked through manual LineageOS zip flashing after a fresh install of Magisk 22.
Previously since several weeks (I think maybe 5-6) ago the survival script had stopped working on my device, even after uninstalling and re-flashing Magisk's latest 21. LineageOS version is 17.1.

[ElCoyote27]

I think I'm also seeing this on LOS:
#4394
Magisk doesn't install on LOS 18.1 and 17.1 unless an old zip is used.