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.
I realized the attachment did not work. This time the file is zipped.
Before I recorded the bootloop (with the patched imaged) I was using the original boot image to boot into safe mode. But as you explained this does not have an effect on the modules as magisk itself is missing.
I thought TWRP was working when I tested is a few weeks ago, but right now TWRP is stuck at the splash screen, so I cannot test it probably this is because of Android 13
Well done, your perseverance paid off.My solution was to modify magisk itself. I removed the module loading part, compiled magisk and patched the boot image again. This was I was able to boot and remove all modules and then again patch the original boot image with the "real" magisk. See here for more detail https://github.com/topjohnwu/Magisk/issues/6301#issuecomment-1265164036.
Thank you all for your help.
EDIT: I have attached the binary if anybody has the same issue. But you can and should always compile it yourself.
Possibly... Others have made various suggestions for more reliable disabling of modules etc, and these have been closed...
I think any flag in data may be difficult to set w/ the TWRP / ADB issues this user had and others may face...Furthermore, it would be great to add a feature into Magisk Manager UI to set a flag for disabling modules, yes I realize that it would need to be set outside of /data/adb, why not in /data/local/tmp? rooted Magisk can check for existence of a disable_modules or similar file and not load modules.
https://www.didgeridoohan.com/magisk/MagiskModuleIssues#If you cannot get the button combination working, you could also disable Magisk completely by flashing the stock boot image to your device. This should let it boot, but with Magisk (and thus all it's modules) disabled. From here you can activate Safe Mode from the Power Menu. Long press "Power Off" and you should get a prompt to enable it. Once the device reboots, press and hold the button combination to enter the bootloader menu or equivalent for your device. From here you should be able to then install a Magisk patched boot image (through fastboot, or equivalent) and when you then reboot your device it will go to Safe Mode which in turn will let Magisk disable all the modules and you can continue as described above.
Bootloop Protector should just work as it is however as it checks looping (via Zygote Process ID mismatch for some 30 secs) before disabling modules and rebooting...
Yeah that would be an issue if @gecowa6967 was stuck in bootloop, he was able to flash a stock boot.img and boot normally, install Magisk, create a patch, but booting to the patched version obviously had the issue.
We can't write to /data/adb/modules without root (and we're bootlooping with root), hence why it has to be to somewhere like /data/local/tmp
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.
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