[MOD]: Sqlite3 (v3.8.11.1) binary.

[ianmacd]

That's actually also been known to cause issues on some systems. While investigating issues like this, a while back, I believe it was found that it was most compatible to use xbin if it exists and bin if it doesn't.

Thank you, both.

I used /system/xbin simply because others already had, and because the Linux FHS doesn't seem to have any significance on Android. I didn't know that /system/xbin doesn't exist on some devices, but it doesn't surprise me to discover that this is the case.

I'll add the necessary code to the installation script when I have a moment. I should probably spend a few minutes getting to grips with Unity at some point, too.

 

[jcmm11]

That's actually also been known to cause issues on some systems. While investigating issues like this, a while back, I believe it was found that it was most compatible to use xbin if it exists and bin if it doesn't.

Are you sure that the issue didn't have something to do with overwriting existing commands? eg - busybox
I can see possible problems if you replace a default command with something that functions, even slightly, differently but other than that it should work, I would think.

That being said there's certainly no harm in checking for xbin first and using it if it exists

 

[ianmacd]

That's actually also been known to cause issues on some systems. While investigating issues like this, a while back, I believe it was found that it was most compatible to use xbin if it exists and bin if it doesn't.

@jcmm11 @manos78 @Didgeridoohan

Hi chaps,

As promised, I have added the necessary logic to the installation script, and the binary is now installed in /system/xbin if it's available, otherwise /system/bin.

I've already pushed v1.1 of the module to the official repo. Thanks for the bug report and tips on how best to fix it.

 

[ianmacd]

Good point... Check for /sbin/.core/mirror/system/xbin. That's the untouched /system mirror.

Actually, that also seems to include the files from any currently installed active modules, so upgrading this module from the previous version may erroneously place the binary back in /system/xbin, even if that directory was created just to host the previous version.

If this happens, the solution is to uninstall and reinstall the module, rather than doing an upgrade.

 

[jcmm11]

Actually, that also seems to include the files from any currently installed active modules, so upgrading this module from the previous version may erroneously place the binary back in /system/xbin, even if that directory was created just to host the previous version.

If this happens, the solution is to uninstall and reinstall the module, rather than doing an upgrade.

Are you sure about that? I have an xbin and the mirror does show files in there, but not from any modules. (No busybox files, no dnscrypt-proxy etc - even though these are installed modules with xbin entries).
If the mirror does show xbin files from modules on the phones with no native xbin I'm guessing that's a bug. (The operative word there is guessing)

 

[ianmacd]

Are you sure about that? I have an xbin and the mirror does show files in there, but not from any modules. (No busybox files, no dnscrypt-proxy etc - even though these are installed modules with xbin entries).
If the mirror does show xbin files from modules on the phones with no native xbin I'm guessing that's a bug. (The operative word there is guessing)

Well, I was just updating another of my modules that needs to overwrite a system library, say foo.so. foo.so is usually found in /system/lib, but on some devices it's found in /system/vendor/lib.

Up until now, I was simply installing my replacement lib in both locations to be sure I overwrote the original, wherever it happened to be located, but I decided to update the module to check where the current foo.so is installed, and to copy my replacement lib only to that directory.

Unfortunately, however, when the installation script of the updated module ran, it found a foo.so in both possible locations, not just the original foo.so actually installed on /system. When I checked, one was the real foo.so installed in one of the two possible locations, and the other was my replacement foo.so installed in the second location. I can't explain that any other way than by concluding that the mirror also includes the files of active modules.

Possibly there's an alternative explanation, and I don't understand Magisk well enough to identify it.

 

[jcmm11]

Well, I was just updating another of my modules that needs to overwrite a system library, say foo.so. foo.so is usually found in /system/lib, but on some devices it's found in /system/vendor/lib.

Up until now, I was simply installing my replacement lib in both locations to be sure I overwrote the original, wherever it happened to be located, but I decided to update the module to check where the current foo.so is installed, and to copy my replacement lib only to that directory.

Unfortunately, however, when the installation script of the updated module ran, it found a foo.so in both possible locations, not just the original foo.so actually installed on /system. When I checked, one was the real foo.so installed in one of the two possible locations, and the other was my replacement foo.so installed in the second location. I can't explain that any other way than by concluding that the mirror also includes the files of active modules.

Possibly there's an alternative explanation, and I don't understand Magisk well enough to identify it.

Hopefully a silly question but are you sure you were checking /sbin/.core/mirror and not /system, /vendor ? Hmm, actually in TWRP you should just mount /system and /vendor and check them directly since the mirror doesn't exist until boot, however make sure you're not doing that accidentally in a Magisk Manager install.

 

[ianmacd]

Hopefully a silly question but are you sure you were checking /sbin/.core/mirror and not /system, /vendor ? Hmm, actually in TWRP you should just mount /system and /vendor and check them directly since the mirror doesn't exist until boot, however make sure you're not doing that accidentally in a Magisk Manager install.

Yes, I have the code in front of me. I was definitely checking /sbin/.core/mirror. I've worked around this at present by detecting when the foo.so that is on the system is the same as the one that my module places. If so, that's a false positive, so no action is taken.

This all happens in the booted system, however. The code definitely wouldn't work in TWRP, for the reason you state.

 

[Didgeridoohan]

Yes, I have the code in front of me. I was definitely checking /sbin/.core/mirror. I've worked around this at present by detecting when the foo.so that is on the system is the same as the one that my module places. If so, that's a false positive, so no action is taken.

This all happens in the booted system, however. The code definitely wouldn't work in TWRP, for the reason you state.

That's interesting. I can definitely confirm that the mirror /system is untouched by Magisk on my devices, and that's the way it should be... Magisk needs the default /system, to be able to mount the Magisk files over it and then unmount them when MagiskHide is triggered. And if the default /system would be modified, it wouldn't be a systemless modification.

 

[ianmacd]

That's interesting. I can definitely confirm that the mirror /system is untouched by Magisk on my devices, and that's the way it should be... Magisk needs the default /system, to be able to mount the Magisk files over it and then unmount them when MagiskHide is triggered. And if the default /system would be modified, it wouldn't be a systemless modification.

I believe you. By far the most likely explanation is that I somehow made a mistake, because the alternative is that Magisk works differently for me than for everyone else.

The code in question was this, in config.sh, called from update-binary:

mask_lib(){
  if [ -f /sbin/.core/mirror/system/lib/liboemcrypto.so ]; then
    ui_print "- Installing to /system/lib"
  else
    # Remove files from module to avoid installation at this location.
    rm -rf $MODPATH/system/lib
  fi

  if [ -f /sbin/.core/mirror/system/vendor/lib/liboemcrypto.so ]; then
    ui_print "- Installing to /system/vendor/lib"
  else
    rm -rf $MODPATH/system/vendor
  fi
}

During a test installation, I was surprised when both conditional sections ran. A live system definitely contains only one copy of liboemcrypto.so at one of those two locations. When I looked with a file manager, I found the original at one location, and my replacement at the other, so the code appeared to be looking at a /system that included the files from the currently installed version of the module. Even if I had accidentally looked at /system, that wouldn't explain why both sections of code actually ran. The only other explanation I could imagine is that I have an actually modified /system, but I've verified that that is not the case, either.

I can't explain it, but I'm happy to accept that I must have made a mistake. There's really no other conclusion to draw, given your explanation of how Magisk works.

I have a long drive to France ahead of me today, but I'll try to get back to this in the next couple of days and figure out what happened.

 

[cipga]

I have Evolution X 4.0 installed from scratch. Every update i´ve tried to install give me an Orangefox recovery error. "invalid zip file format error installing zip file". Any idea how that can be fixed? I¨ve tried both OTA update and direct download of the latest rom.

 

[jcmm11]

I have Evolution X 4.0 installed from scratch. Every update i´ve tried to install give me an Orangefox recovery error. "invalid zip file format error installing zip file". Any idea how that can be fixed? I¨ve tried both OTA update and direct download of the latest rom.

Need a full install log from recovery.
Try installing from Magisk rather than thru l recovery.