Magisk General Support / Discussion

[evil-google]

Bit vague on your setup now...

Guess RN7 with ramdisk=no (since launched w/ A9... unless has A/B(?))

So default instructions are install magisk in recovery ramdisk (recovery mode selected)... Zip install can't do this... Did you ever do that (patch recovery.img)?... But being Xiaomi you won't actually need this... Best to patch boot.img (recovery mode un-selected) using M. App and flash...

And I wouldn't use .zip install for your device... It's legacy SAR... May be fine, but zip install is fraught since legacy ramdisk booting devices (any device w/ Launch Version A8 or less, but not updated to A10+)... Whether this could impact on SD card, BT issues etc, I'm not sure, but I'd start again w/ proper patch / flash for SAR / 2SI devices...

You can use Uninstall Magisk from App; Nb. Restore Images leaves android configuration in /data/adb, so you'll want to take Complete Uninstall... (Or, if you first want to test if issue is that magisk.db or other config files are corrupted / causing issues, with root explorer or twrp simply delete everything in /data/adb and reboot and magisk daemon will rebuild config files... You'll have cleanly installed root and modules, superuser, deny lists etc will be gone too...)

For full uninstall you can also delete everything in /data/adb and flash unpatched boot image (recovery.img or boot.img or both these boot images)... If deleting data with root, don't reboot before flashing original boot image...

Issue does sound VERY like a mismatched kernel to me... Often this gives associated hardware issues...

Kernel is in boot image, so this is a common issue where users restore images to take an OTA update (even a minor one), then flash back previous boot image instead of sourcing the ROM corresponding with the OTA to obtain boot.img (or recovery.img) to patch and flash... or simply mix up boot images on the PC... Failing to restore unpatched images before an OTA can cause issues too...

Did you ever use App to patch images? (... Old .zip installation doesn't allow such a mismatch/ user error).

... Remember to treat your Xiaomi SAR A only device as ramdisk=yes for your clean setup, and patch / flash boot.img exactly matching or extracted from current ROM...

PW

Hope you will have patience with my ignorance on this matter ...so, will the following help?

1. open Magisk app and select recovery mode and do a direct install
2. then again using Magisk app uncheck the recovery mode and do a direct install

Or will it be just better to uninstall magisk completely, re-install the apk and use boot image patching method? Again, when creating the boot image patch file do I need to select the recovery mode option?

Once again, thanks for your patience. As you can see, I am clueless on how Magisk does its tricks!

EDIT : You are correct, in my case ramdisk=no.

 

[pndwal]

Hope you will have patience with my ignorance on this matter ...

First, I asked : Did you ever use App to patch images? (Answer will eliminate some possible issue causes...)

so, will the following help?

1. open Magisk app and select recovery mode and do a direct install

No... Treat you device as ramdisk = yes...

- Magisk manually added a basic ramdisk to boot partition (it always does when missing, yous in case it can be used for Magisk init... Still says no to indicate no OEM ramdisk as most A-only legacy SAR booting type devices won't be able to use the ramdisk due to incompatible bootloader... Xiaomi inexplicably has boot-ramdisk compatible bootloader despite OEM not utilising it...

So, don't use recovery mode (for patching recovery image)...

2. then again using Magisk app uncheck the recovery mode and do a direct install

Well you can, but won't be clean... Thought you wanted to eliminate any issues with configuration which is in /data/adb...

Or will it be just better to uninstall magisk completely, re-install the apk and use boot image patching method?

Uninstall Magisk, so do as you said (select Complete Uninstall) or simply patch correct image, delete /data/adb but leave app if correct version and flash newly patched image before any reboot... (Am I repeating all this?)

Again, when creating the boot image patch file do I need to select the recovery mode option?

No! ... Only if you want to use the troublesome Magisk in Recovery ramdisk option, but why do this when bootloader allows Magisk in boot??

Once again, thanks for your patience. As you can see, I am clueless on how Magisk does its tricks!

No worries, but do take time to read official Installation instruction(s) 3 or 4 times till you get your head around pertinent instructions... Many clues I've given are just from these...

EDIT : You are correct, in my case ramdisk=no.

PS Google is your friend! (Not Evil)... And FWIW, Android is their (adopted) baby, their mobile OS!... What's not to like?! PW

 

[J.Michael]

@evil-google If you use the Magisk manager app to patch an image, and there is a checkbox for "Recovery mode", it is your responsibility to use that checkbox to tell Magisk what kind of file it is patching. Only check that box if you are giving Magisk a recovery image to patch. And make sure that you flash a recovery image to the recovery partition.

 

[evil-google]

First, I asked : Did you ever use App to patch images? (Answer will eliminate some possible issue causes...)

No, I did not. As I mentioned, I took the quick and dirty option since someone posted that it worked of them without any issues and now I know that it was the wrong choice!

Thanks again for going through the responses in detail and it makes a lot more sense to me. I will uninstall it and then patch the LOS boot.img file and flash it as you have mentioned rather than trying to fix what may be broken.

Appreciate your help.

 

[evil-google]

@evil-google If you use the Magisk manager app to patch an image, and there is a checkbox for "Recovery mode", it is your responsibility to use that checkbox to tell Magisk what kind of file it is patching. Only check that box if you are giving Magisk a recovery image to patch. And make sure that you flash a recovery image to the recovery partition.

Is there any advantage of patching the recovery image over patching the boot image?

 

[pndwal]

No, I did not. As I mentioned, I took the quick and dirty option since someone posted that it worked of them without any issues and now I know that it was the wrong choice!

To be clear, issues may not stem from .zip installer recovery installation, but it is not recommended even by John for post ramdisk boot type devices... Modern installation can patch other partitions where needed also (zip installer doesn't), and also eliminates issues stemming from 3rd party Recoveries of which there are many that magisk cannot control (flashing, mounting, etc etc).

Thanks again for going through the responses in detail and it makes a lot more sense to me. I will uninstall it and then patch the LOS boot.img file and flash it as you have mentioned rather than trying to fix what may be broken.

Appreciate your help.

PW

 

[J.Michael]

Is there any advantage of patching the recovery image over patching the boot image?

I think not.
If anything, patching the recovery image is a last resort, used only when patching the boot image cannot work.

(All right, if Magisk is installed in recovery, it might be possible to boot in a way that leaves Magisk inactive. It is possible that some "tamper detection" processes will be satisfied if Magisk is not active. So, you could make the case that there is some advantage to installing Magisk to recovery.)

 

[pndwal]

Is there any advantage of patching the recovery image over patching the boot image?

No! (except possibly benefits of having boot to both system with root and system without it mentioned in following posts)... Booting system via recovery is also quite awkward ...

This mode was provided because most devices with no OEM ramdisk (A only legacy SAR) cannot support an added one, so there is no other option for running Magisk since it always resides in a ramdisk... John calls this "The worst type of device to ever exist as far as Magisk is concerned".
https://topjohnwu.github.io/Magisk/boot.html#piecing-things-together

Fortunately for you:
"Some Type III devices’ bootloader will still accept and provide initramfs that was manually added to the boot image to the kernel (e.g. some [actually all(?) or most] Xiaomi phones), but many device don’t (e.g. Samsung S10, Note 10). It solely depends on how the OEM implements its bootloader."...

Recovery mode is simply for installing it to ramdisk in recovery partition and Magisk app toggle signals system to reboot via recovery, patch recovery.img instead of boot.img when taking Direct Install etc... PW

 

[pndwal]

I think not.
If anything, patching the recovery image is a last resort, used only when patching the boot image cannot work.

(All right, if Magisk is installed in recovery, it might be possible to boot in a way that leaves Magisk inactive. It is possible that some "tamper detection" processes will be satisfied if Magisk is not active. So, you could make the case that there is some advantage to installing Magisk to recovery.)

This is correct... Normal bootup will boot system without Magisk, and this may have some limited-use benefits... PW

 

[zgfg]

Is there any advantage of patching the recovery image over patching the boot image?

Not unless you want the following:

- Normal booting will boot to Android without Magisk

- Booting through Recovery (Vol+ & Power) to boot into Android with Magisk

Usually, it is not practical

Also, you may probably have troubles with OTA

 

[Tech = Spy-Biz]

PS Google is your friend! (Not Evil)... And FWIW, Android is their (adopted) baby, their mobile OS!... What's not to like?! PW

So trueeeeeeeeeee.
NVM 450 services inside Play Services alone ..each a gem! As stated by Ed Snowden on Utube- Guugle does a brilliant job of shielding its users from others but guugle itself collects, analyses & sells private info on its users for ad revenue, and so does Appel and many others. Thats how they got so rich & powerful so fast. (sorry,off-topic though but living with the pain u knw)

@pndwal said:

Yup, your parents held your hand and spied on you but weren't (necessarily) evil. ...

Wadiya spect Tech = Spy-biz? PW

Me replied :
As a kid I was too young & naive to not realize that my parents were actually spying on me & even selling my data to AdMob , AdSense, Pentgon & agencies. Where did all that Ad money they received go? I didn't get any of if in the "Will" they left behind. My parents can't be so evil .

 

[pndwal]

So trueeeeeeeeeee.
NVM 450 services inside Play Services alone ..each a gem! As stated by Ed Snowden on Utube- Guugle does a brilliant job of shielding its users from others but guugle itself collects, analyses & sells private info on its users for ad revenue, and so does Appel and many others. Thats how they got so rich & powerful so fast. (sorry,off-topic though but living with the pain u knw)

Yup, your parents held your hand and spied on you but weren't (necessarily) evil. ...

Wadiya spect Tech = Spy-biz? PW

 

[pndwal]

Off-Topic: I always thought that 'The Problem' colloquially known as Zoomers were the 'ones' that prefer to use abbreviations and/or acronyms for every other word typed or spoken.

like i totes dont like even get you right now....Bruh

Not just zoomers... the olds too... at least the Googlers...

• The GKI kernel is built from the ACK sources.
• The GKI kernel is a S-KB plus associated LMs per architecture, per LTS release (currently only arm64 for A11-5.4 and A12-5.4).
• The GKI kernel is tested with all AP releases that are supported for the associated ACK. There’s no feature deprecation for the lifetime of a GKI kernel version.
• The GKI kernel exposes a stable KMI to drivers within a given LTS.
• The GKI kernel doesn't contain SoC-specific or BS code....

... well maybe I took some license with this. ... Here you go:
https://source.android.com/docs/core/architecture/kernel/generic-kernel-image PW

 

[pndwal]

... But seriously, Magisk prepared for GKI (Generic Kernel Image) 2.0 w/ v 25.0:
[MagiskInit] Support Android 13 GKIs (Pixel 6)
- this:
Support GKIs without ramdisk …
Fix #5819
topjohnwu committed on 12 May

This is because

For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel.

So users of Pixel 7(?) and future devices launching w/ A13+ will need to patch / flash new init_boot.img for Magisk installation instead of boot.img per vvb2060's note (Translated):

https://source.android.com/docs/core/bootloader/partitions/generic-boot

Magisk has been adapted in advance and supports the new partition layout of Android 13.

Please extract the init_boot.img first if you manually patch the image, if not, then extract the boot.img

https://t.me/magiskalpha/530

Nb. Updated devices can use ramdisk in original boot partitions as per John's fix for Pixel 6...

PW

 

[zgfg]

... But seriously, Magisk prepared for GKI (Generic Kernel Image) 2.0 w/ v 25.0:
[MagiskInit] Support Android 13 GKIs (Pixel 6)
- this:
Support GKIs without ramdisk …
Fix #5819
topjohnwu committed on 12 May

This is because


So users of Pixel 6 etc and future devices launching w/ A13+ will need to patch / flash new init_boot.img for Magisk installation instead of boot.img per vvb2060's note (Translated):

https://t.me/magiskalpha/530

Nb. Updated devices retain generic ramdisk in original boot partitions.

PW

Putting that simple, it probably means that if on A13 and higher init_boot img exists - patch the init_boot; otherwise patch the boot (or recovery) img as usual

I didn't check the doc - on a/b devices should there be again init_boot_a and init_boot_b?

 

[CSX321]

So users of Pixel 6 etc and future devices launching w/ A13+ will need to patch / flash new init_boot.img for Magisk installation instead of boot.img per vvb2060's note (Translated):

https://t.me/magiskalpha/530

Bit confused by that. There's no init_boot.img in the Pixel 6 Android 13 zip. When I updated mine yesterday, I just extracted and patched boot.img as always, and everything seems normal.

 

[zgfg]

Bit confused by that. There's no init_boot.img in the Pixel 6 Android 13 zip. When I updated mine yesterday, I just extracted and patched boot.img as always, and everything seems normal.

"Launching with" actually means future devices that will be initially launched with A13

IMO, as that it could not refer to Pixel 6 if it was originally launched with A12

That was a similar case with eg FBE - mandatory for devices launched with A10+, not those launched with A9- and just upgraded to A10

 

[pndwal]

Putting that simple, it probably means that if on A13 and higher init_boot img exists - patch the init_boot; otherwise patch the boot (or recovery) img as usual

Correct.

I didn't check the doc - on a/b devices should there be again init_boot_a and init_boot_b?

I believe 1st stage init will still require a ramdisk for each slot so that is assumed. Pixel 7 series users may confirm this later...

Vv's statement is clearly refering to new partitioning for devices launched with A13 so the latter part (re non-manual patching) "... if not, then extract the boot.img" is ambiguous to me... Something lost in translation? Statement not properly thought through (like my edited one above )? PW

 

[pndwal]

Bit confused by that. There's no init_boot.img in the Pixel 6 Android 13 zip. When I updated mine yesterday, I just extracted and patched boot.img as always, and everything seems normal.

Yes; Sorry! - I edited my remark!

It was based on John's release note:
v 25.0:
[MagiskInit] Support Android 13 GKIs (Pixel 6)
which was connected with:
- this:
Support GKIs without ramdisk …
Fix #5819

I initially assumed the fix meant p6 had the new init_boot image scheme, but it actually lacked ramdisk in boot.img due to this being moved to new vendor_boot!

John's chosen fix actually involved recreating ramdisk in boot.img for magisk.init. This:

When a v4 boot image does not contain ramdisk, we will have to create the CPIO from scratch. However, since this ramdisk will have to be merged with other vendor ramdisks, it has to use the exact same compression method.
v4 GKIs are required to use lz4 (legacy), so hardcode it here.

So this fix actually allows implementations of Android 13 GKIs for updated devices (Pixel 6 etc) to work...

vv's note however, preempts Android 13 release devices, ie. Pixel 7+... PW

 

[ipdev]

Nah, as it says, it will be released soon, i was just giving folks, and you especially a heads up

Personally i abandoned it (it had *nothing to do* with that time i removed lsposed but forgot to uninstall the magisk module portion of HMA and bootlooped myself ) for updatelocker some time ago, as it does all i was really using HMA for.

But with the talk the new HMA will drop the magisk module, i might give it another go

Same as you.
I am waiting for the new official release.

Is Hide-My-Applist actually shifting to Zygisk.
ZygoteArgsHook for Android 11+

Cheers.

PS.
One of these days I will look up the tg channel.