Did you have Magisk App hidden when updated?... Classic trap... Supposed to work, but bit like a pot-luck dinner...
Experienced this issue on a fork of Magisk too. https://forum.xda-developers.com/t/...third-party-magisk-fork.4460555/post-87255925
It's a general rule: take chances (w/ awareness of issue/remedy) or take Restore the Magisk app before updating App... My success estimate is reducing... 50/100 --> 40/100 --> 30/100 (?).Experienced this issue on a fork of Magisk too. https://forum.xda-developers.com/t/...third-party-magisk-fork.4460555/post-87255925
Alright so I looked a bit and had very little luck and gave up. Then I opened terminal emulator for some unrelated activity, ran su, and "device manager" stopped working. Gonna see what happens when I uninstall that...Did you have Magisk App hidden when updated?... Classic trap... Supposed to work, but bit like a pot-luck dinner...
You're probably suffering from DACFRAS*, which is NOT fatal but all the clinics are full...
Check in device settings, Apps for your old hidden App... Default name is 'settings', or its what you named it... Uninstall it, and presto!
*Dual Apps Competing For Root Access Syndrome...
Maybe problem with github serverExperienced this issue on a fork of Magisk too. https://forum.xda-developers.com/t/...third-party-magisk-fork.4460555/post-87255925
Very simple (and you don't need Terninal, su, etc):Alright so I looked a bit and had very little luck and gave up. Then I opened terminal emulator for some unrelated activity, ran su, and "device manager" stopped working. Gonna see what happens when I uninstall that...
Worked lol shows which version is installed access to superuser tab and modules tab active haha
i guess you're aware about that fork not requiring 'hide/rename/restore the app before updating'... so, maybe this: https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87272599
Ah yes, certainly... I see you didn't hide...i guess you're aware about that fork not requiring 'hide/rename/restore the app before updating'... so, maybe this: https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87272599
Done... PWWould you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.
I tried to explain it somewhat simply here, please let me know how far I missed the mark
Released - you have APK?Meanwhile for users of HideMyAppList, from that place we can sometimes mention and link to comes this news:
Guys long time no see.
The 3.0 version of HMA is under development and will be released soon.
In the new version, we solved a lot of problems existing in the 2.x.
1. Remove the Magisk extension, and introduce a new way (Xposed only) to prevent apps from using file detection to scan /data/data and Android/data (Unfortunately it might only support Android 11+), which does not inject code into app process to prevent detection.
2. UI redesign with full Material You and better interactive logic. Also there will be night mode fix.
3. Introduce a new effective way to implement hide on high version Android.
We reestablished the discussion group, but the verification bot is not well written yet, so the public link will not be visible now.
I've also done the same thing, more than once and had bootloops, also.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
Seems to be device/rom related.
No one will read it but..<SNIP>
Unfortunately,v I also don't know why TJW does not acknowledge this problem and if they could not fix it, AT LEAST to make a note into the Installation instructions (I know, nobody would read) and a warning into the Changelog
Of course, he does not read this thread and he doesn't care about all the users experiencing the same problem (99% of them are not on the level to have GitHub account and to report there, and they don't bother him to his lovely Twitter)
### Known Issues Some devices and/or roms still have issues updating when Magisk is hidden (renamed). Add Quick Explanation of the the Problem. To fix the failed update (Word this better). - Uninstall the older (hidden) Magisk app and reboot. Note something about continued updates. - Restore Magisk - Upgrade directly via the Magisk app using its “Direct Install” method. - Add or link to updating for Samsung and/or Magisk in Recovery.
Yeah, even better and more friendly
I think safe mode using key combination is not very reliable, or at best requires a tricky timing.
@gecowa6967 can comment, but it wouldn't work for him, not sure if it booted to safe mode and Magisk failed to disable the modules (in which case it would be a Magisk bug) or Safe mode never got activated.
I personally didn't know that we could boot to safe mode from the UI, which was a great tip that we can try if this happens again, I know that gecowa6967 was not the only one that experienced this issue.
Yup, but doesn't this still require USB debugging enabled?... And @gecowa6967 had issue where adb command magisk --remove-modules had no effect...
Yup... No idea either.but can we create such file using fastboot?
I looked at fastboot commands, and I see this, but I have no idea how to use it and if it can help us create an empty file
Android Things: stage IN_FILE Sends given file to stage for the next command. get_staged OUT_FILE Writes data staged by the last command to a file.
If we can, then @gecowa6967 code, instead of disabling loading modules would simply look for the presence of such file and if found skip loading the modules.
It's just a working possibly (actually allowed the fix used); seems ADB (requires USB debugging enabled anyway) and Safemode (user could only enter it w/ unpatched boot image) had no effect and are also often inaccessible to other users...
This seems a good approach......Even more user friendly: let it be a file on Internal memory (like in Download folder) - hence one does not even need to pinpoint with adb
For this, root is not needed and without Magisk, there should be no bootloop due to the modules
3) Then flash back the patched boot.img and reboot.
Magisk should read the file from step 2 and disable the module(s)
He was only able to boot to Android Safe mode w/o root (ie after flashing unpatched boot image) which doesn't trip Magisk Safe mode (requires running Magisk daemon to detect Safe mode triggers and to set flags for disabling modules)... Not a Magisk bug since it wasn't running!
And need for running Magisk daemon is the key to this too; We boot to Android Safe mode w/o root but rely on reboot after a fastboot flash (we access fastboot from Safe mode to flash Magisk-patched image) being reboot back to Safe Mode... Modules will only be disabled at this point...
User simply couldn't get access w/ key combo w/ patched boot image, but this is also problematic due to Magisk's need to detect user entering key combo (booting from off state only) and timing is also critical... Eg on MIUI we can generally get Android Safe Mode w/o triggering Magisk Safe Mode unless we alter the usually key release timing... I know others have also had different problems with this approach...
Praps we could just use an old wheel (Core Only mode) again for emergency use!... PW
You can do some cleaning like this:I'm using the systemless debloater module to degoogle and debloat a device (and several other magisk modules to assist in that endeavor). I'd really like to be able to do a factory reset to clear the device of any data/artifacts from the debloated apps, but of course a factory reset wipes out magisk modules, so I'm in a catch 22.
Okay folks, thought I'd post up the procedure:
adb pull /sdcard/Download/magisk_patched_[random_strings].imgworks just fine;
$ heimdall detect Device detected $ heimdall print-pit --no-reboot > print-pit.txt
$ heimdall detect Device detected $
fastboot flash boot /path/to/magisk_patched.imgat the 7th bullet point here
$ heimdall flash --BOOT magisk_patched-25200_UjUVt.img Heimdall v1.4.2 Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna http://www.glassechidna.com.au/ This software is provided free of charge. Copying and redistribution is encouraged. If you appreciate this software and you would like to support future development please consider donating: http://www.glassechidna.com.au/donate/ Initialising connection... Detecting device... Claiming interface... Setting up interface... Initialising protocol... Protocol initialisation successful. Beginning session... Some devices may take up to 2 minutes to respond. Please be patient! Session begun. Downloading device's PIT file... PIT file download successful. Uploading BOOT 100% BOOT upload successful Ending session... Rebooting device... Releasing device interface... $
I wouldn't source. The script is supposed to be called as an executableHow does PixelFlasher invoke boot_patch.sh?
Does it invoke it as an "executable", creating a new process? Or does it "source" it, so changes to the environment will survive?
Does PixelFlasher create an environment variable named "SHA1"?
My copy of boot_patch.sh has a compound statement that tests whether SHA1 has a non-zero length value before setting it to the sha1 of the boot image. If the environment variable is already set, it will not be overwritten. I don't know why.
#!/system/bin/sh # Boot partition AB=$(getprop ro.boot.slot_suffix) BOOT_PART=/dev/block/bootdevice/by-name/boot"$AB" # Boot and patched boot images DOWNLOAD=/sdcard/Download/ BOOT_IMG="$DOWNLOAD"boot.img PATCHED_BOOT_IMG="$DOWNLOAD"patched-boot.img # Magisk path MAGISK_PATH=/data/adb/magisk/ # Disk-dump boot image to Download folder dd if="$BOOT_PART" of="$BOOT_IMG" # Patch the boot image and move to Download folder "$MAGISK_PATH"boot_patch.sh "$BOOT_IMG" mv "$MAGISK_PATH"new-boot.img "$PATCHED_BOOT_IMG" # Flash the patched boot image dd if="$PATCHED_BOOT_IMG" of="$BOOT_PART" # Reboot reboot