yashsingh1/xdaforums huggingface dataset:
[Magisk] badabing2003:
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.

My suggestion is to have an unrooted Magisk, set a flag in /data/local/tmp or somewhere convenient, so that a rooted Magisk will skip loading modules.

Basically

Same as your comment below, but without really having two different versions, disabling would be based on the flag.

Thanks for the tip from @Didgeridoohan I didn't think I could do that,

On Pixel phones you have to press the Power and Volume up to bring up the reboot options, and then long press the power button to boot to safe mode.

Great handy tip, thanks
[Magisk] pndwal:
mmm... So just a simple fastboot flashable mod that only writes an empty file named 'disable' to /data/adb/modules would be perfect, but can we do this with fastboot?...

I guess you're actually suggesting a more complex mod to a boot image that is capable of writing similar files to data?...

Yup... bit late but might have worked...

I tested reboot to Safe mode from system with Magisk and it works to disable modules... Haven't tested if reboot to Safe mode from bootloader/fastboot occurs in practice when fastboot mode was called from Safe mode, or if Magisk Daemon detects this successfully to disable modules, but Didge suggests it should work and may have tested... PW
[Magisk] badabing2003:
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

We definitely can create such file in adb which would have helped @gecowa6967 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.
[Magisk] zgfg:
I don't see that Fastboot is needed (and I don't know of a command in Fastboot to achieve that)

But your previous post was in the great direction:

1) Flash a stock/original boot.img (not patched by Magisk) and reboot

2) Use adb to create a file in /adb/local/tmp to flag which (or put it simple - just all) modules to be disabled

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)

---

Although I still don't understand what is wrong with Safe Mode. Are there devices that cannot boot to Android Safe Mode, or just ppl don't know about, or don't know (google about) how to use the fingers to boot to the Safe mode
[Magisk] badabing2003:
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.
[Magisk] zgfg:
More thoughts about:

- Magisk uses /data/adb (not /data/local/tmp or Internal memory) since an app needs a root to access there.

Otherwise, all banking and similar apps would be able to read the Magisk config files (which modules to disable, etc) and that would give them just one more and totally a simple way to seek for the 'oot'

- Since Magisk does already have a way to mark which modules have to be disabled (disable files in the corresponding /data/adb/modules folders), and since those have to be there (see the previous remark), we have to be very careful if proposing a new/additional file to disable the modules, plainly visible on Internal memory, how would it look and work like

- To avoid a conflict (and a question of precedence) between that new file and the established disable or uninstall files in /data/adb/modules folders, it has to be something very simple and limited only to the really emergency use

- Ie, a file that will force Magisk to boot to the root-only mode (that includes that all modules have to be disabled).

Magisk might even delete that file once it consumes the command, or user will be responsible to delete the file - knowing that as long as he does not delete, Magisk will continue booting to the root-only mode

That way, the file will be present only temporary and in special case, hence it won't cause a conflict with the existing modules flags (disable and uninstall files) in /data/adb/modules folders, and that new file would not become a common open door to seek for the Magisk presence

----

I cannot find it now but I think there used to be a setting to force Magisk to boot to the root-only mode, and it used to use a config file like disable_magisk in /data/adb or so (sorry, I also didn't search through the documentation now before posting)

Hence something like that but on Internal memory now, that user can easily create it by one-time booting without Magisk...

---

But there is already a great Magisk Bootloop Protector module (and the corresponding mechanism built-in to Magisk Delta) by @huskydg - read more about and install from (it can be also found by Fox MMM):

GitHub - Magisk-Modules-Alt-Repo/HuskyDG_BootloopSaver: Protect your system from bootloop caused by Magisk modules.

Protect your system from bootloop caused by Magisk modules. - GitHub - Magisk-Modules-Alt-Repo/HuskyDG_BootloopSaver: Protect your system from bootloop caused by Magisk modules.

github.com

In fact, nost of the stuff above (a control file on /data/local/tmp and so) makes actually a re-inventiion of the wheel, once compared to the documentation how already the MBP module works😁
[Magisk] badabing2003:
Yes of course, this file needs to be written by a user / process without root for emergency purposes, this is not something that should be there permanently or be used in any other way,

That would be perfect, in fact consuming it is a good idea, basically the no modules boot is a one time thing. if the user just reboots, the Magisk will attempt to load the modules.

It's up to the user to delete modules that are causing an issue.

yep

Indeed it is, the only catch with MBP is that users need to have had that module prior to the problem.

I do, but do we all, this being integrated into Magisk makes it simpler and easier.
[Magisk] pndwal:
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. 😶

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...

My further thoughts: Seems it would be even simpler to restore old core-only mode toggle in-app instead of using a file-based flag however...

Of course we could then simply flash unpatched image and set this mode in such an 'emergency' before re-flashing patched image to boot Magisk w/ modules disabled! 🤪

This would also circumvent these difficulties:

-----​

Correct...

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
[Magisk] zgfg:
Yes - but in Delta

And one more good feature in the latest Delta - Clean Hidelist (of orphan apps)
[Magisk] gecowa6967:
Yes, I was not able to boot into safe mode using key combination when I was using the patched boot image.

I only have the log of the bootloop I posted before, I do not know which module caused the issue. Once I was able to boot with my modified patched boot image, I ran "magisk --remove-modules" to remove all modules.

When I ran "magisk --remove-modules" with the "normally" patched boot image during boot, the phone would restart, but the modules would not be removed. I think magisk did not have write permission for the folder or something like this.

The idea of a "dumb" patched image that does not load any modules would have been good, that's why I posted the APK for anyone else having this issue.

I am very grateful for all the kind feedback you gave me for my hacky solution. And also thank you to my roommate who helped me with all of this. :)
[Magisk] badabing2003:
Does any of the resident Magisk experts know what process is responsible for creating magisk_backup of the stock boot.img ?

This post peeked my interest about the issue.

I started looking at this gist and did some investigation on my phones.

And I first posted by observations / questions in here.

To summarize.

It appears that Magisk stores a reference to the last stock boot.img's SHA1 in a config file (see location in the above gist)

And this is my Pixel 6's contents

KEEPVERITY=true
KEEPFORCEENCRYPT=true
PATCHVBMETAFLAG=false
RECOVERYMODE=false
SHA1=2bde725117d3bd0990437faf06d37baa9adeb818

All the entries make sense, and the SHA1 matches October release's stock boot.img SHA1

All good.

Then looking at the Magisk backups, I see the following backup

drwxr-xr-x 2 root root 3452 2022-10-03 14:21 magisk_backup_7f04123661284ff8d554f01060b00eb6f188a07b

The date / time of the backup matches when I dirty flashed the October release including the patched boot.img through PF (not other flashing was done since)

I find it odd that the backup SHA1 is the SHA1 of the September's boot.img SHA1, but created when I flashed the October image.

Aside from the concern of why it is not the correct one, my question is, what process did actually create that?

I never flashed anything directly in Magisk, (no Direct Install)

I only created patched image using boot_patch.sh.

So I thought perhaps patch creation actually creates the backups, but that is not the case.

I moved that folder out, and created a patch both in Magisk Manager UI and through boot_patch.sh

None created it.

It can't possibly be created by a dirty flash through fastboot, so what is actually creating it, and why it backed up the old boot.img?

Perhaps this relates to the mystery I reported here.
[Magisk] pndwal:
Goognisance?

www.twitter.com/topjohnwu/status/1577787539116605442

😋 PW
[Magisk] pndwal:
This may help as a starting point:

Check code after lines 608, 617 (# Installation Related section, # Legacy backup, # Stock backups) here:

https://github.com/topjohnwu/Magisk...a0346615d5fea79f6bc/scripts/util_functions.sh

🤠 PW
[Magisk] badabing2003:
Thanks

@capntrips led me to the same piece of code in the other thread.

Then to avoid cluttering that thread, we took it to a conversation.

For posterity and benefit of others, I'll summarize the findings and the tips below.

If rooted boot_patch.sh creates stock_boot.img file in the directory where boot_patch.sh is run, typically /data/adb/magisk

Simply opening Magisk Manager app, run the run_migrations routine, which creates the backup and then deletes the stock_boot.img

When a patch is created through Magisk Manager, the stock_boot.img file is created in: /data/user_de/0/com.topjohnwu.magisk/install/stock_boot.img

For obvious reasons (root might still not be available at that point), the migration is not performed, Magisk application restarts have no effect.

Upon reboot, Magisk migrates the stock_boot.img to /data/adb/magisk and then run the migration, effectively creating the backup and clearing /data/user_de/0/com.topjohnwu.magisk/install

Things still to check / verify

Is /data/user_de/0/com.topjohnwu.magisk/ path constant or varies per device / platform ?

where is the config file that stores the SHA1 value created when Magisk Manager is used.

The following piece of code (thanks @capntrips ) would run the migration, and hence could be invoked programmatically and not require Magisk manager start.

cd /data/adb/magisk
./magiskboot cleanup
. ./util_functions.sh
run_migrations
[Magisk] HippoMan:
Rooting itself is here to stay.

However, over time, fewer and fewer other apps will work properly on a rooted Android device.

Rooting is dead. Long live rooting.
[Magisk] pndwal:
But not yet!

... And , of course, you're only speaking of the (small) subset of apps who's Devs require proper attestation to an unmodified execution environment, and who's designs you want to take advantage of while circumventing the same... and their wishes...

The vast majority of apps are not threatened at all!

... And not yet because Google has clearly been in no great rush to fix that attestation...

And of course many of us thought this would have been achieved years ago!... Ie. Game Over for the mouse... But the Cat hasn't killed the mouse yet; it's still playing with it... so the game continues!

Fun eh! (?)...

... Bye, MagiskHide. Long live MagiskHide (Wu) - PW

Perspective is a funny thing...
[Magisk] YNSHNDR:
Hello can you help me please !

me installing a magisk and twrp to the xiaomi mi 9T device after and while installing, I accidentally installed it on the boot partition instead of the recovery, and then when I restart, fastboot mode starts, so it does not boot. log files are attached
[Magisk] J.Michael:
Can't you just reflash the proper image to each improperly flashed partition?
[Magisk] pndwal:
Don't use Magisk in recovery ramdisk mode! Ignore Ramdisk (means OEM supplied ramdisk) = No... It's Xiaomi and actually has bootloader compatible with ramdisk in boot partition... Ensure Recovery mode is always disabled...

So do you mean you Magisk-patched TWRP image and flashed that to boot partition?

Dirty flashing stock recovery and boot images should restore boot (stock system).

You could try simply flashing TWRP (not patched) to recovery and patched stock boot.img (if you have this already) to boot... Personally I'd avoid TWRP (and use stock recovery) unless you really need it... You can usually simply boot to TWRP (not flash) to install custom ROMs etc... PW
[Magisk] ququq:
I need help with accessing the magisk recovery mode.

I have no boot ramdisk, as indicated by the app, so I did the extra step needed. I keep doing the volume up, just boots normally without accessing magisk recovery mode. Logs are attached, and any help is appreciated. Thank you!
[Magisk] huskydg:
How long will you keep cheating yourself with this? Dear pndwal 😁
[Magisk] Captain_cookie_200:
does this mean custom roms etc. are gonna be gone too? (if arent rooted) because some roms dont pass safety net, play integrity by default.
[Magisk] dr4go:
Dude you can't defeat tee / hardware attestation. As long as nobody breaks that it's a dead end.

And although it was fun sometimes, I'm glad that my road will soon end as well regarding root - which is insane, it really is... unbelievable what **** has happened the last years regarding that... but I seriously can't believe how much time I've literally wasted the last years just to keep the phone running with every app I want and need on the phone. It's not worth it anymore...
[Magisk] Captain_cookie_200:
rip... i finally had a phone running custom gsi... i pass safety net everything... guess its going away gotta go back to one EW (it lags alot for my phone with cut features)
[Magisk] 73sydney:
Dude youre so predictably negative i was literally counting down until you posted here....it astounds me that you spend your time building a custom magisk build

If you dont believe in it, why do you bother, and why do you always have to be negative here?
[Magisk] 73sydney:
Please specify your device.....
[Magisk] 73sydney:
@badabing2003

Any chance we can stop this becoming a Pixel Flasher development thread (again)?

Thread title:

Magisk General Support / Discussion​

If im pointing this out, you know you've done something wrong....as im about the most offtopic person seen on xda :)
[Magisk] huskydg:
Well, this thread used to be the place for momo/scheck/shamiko/.... questions and no one said this 😏
[Magisk] 73sydney:
those devs never set a foot here and tried to use the thread to develop their own software.....
[Magisk] ququq:
My bad, its samsung a50. i can provide more details if the logs aren't enough
[Magisk] 73sydney:
to boot into recovery on recent Samsungs, you need to make sure you have a cable plugged in and use the side/bixby key and volume up, this is how it works on my S20+ 5G

cable is important - like to get into download mode for ODIN, you have to power the phone off, hold down the vol up and down buttons, and then plug the cable in....

for more info on magisk install for your device, check your devices forums:

https://xdaforums.com/f/samsung-galaxy-a50-roms-kernels-recoveries-ot.8683/

https://xdaforums.com/f/samsung-galaxy-a50-guides-news-discussion.8682/
[Magisk] pndwal:
Not sure you need recovery mode w/ Galaxy A50... Some seem to have had success rooting w/ zip installer so I'm assuming magisk in boot ramdisk can work for you... (Nb Magisk installs a basic ramdisk when patching if absent, but Ramdisk = No remains.)

You seem to have A11... Do you mean you can't get to recovery from powered down state at all?...

I believe you now need USB connection while using any special key combo booting, eg to recovery or safe mode, on Sammy with late Android (OneUI 3.0+?) so that's probably your issue... Apparently even connecting a usb headset while doing key combo works...

Even if you succeed running Magisk in recovery, give Magisk in boot a go... PW
[Magisk] pndwal:
Might be being a bit harsh...

He's trying to diagnose a magisk routine issue, even if called from his/other 3rd party utility... Any issue here is plainly in Magisk code... PW
[Magisk] ququq:
I'm certain its A50, sadly wished it was on an easier model. And yes, I can't access the Magisk Recovery Mode indicated in point nine of the installation for samsung devices here in this github page by topjohnwu.

Installation

The Magic Mask for Android

topjohnwu.github.io

And thank you, I'll try what you've suggested with the usb connection thing.

Skipping to the installer in the apk app unfortunately doesnt work however, tried it. Just boots up again to normal android, though this is if I understood you correctly.
[Magisk] ququq:
Thank you! I'll look into these posts and try it once again with your suggestions in mind.
[Magisk] badabing2003:
I'm sorry, I thought I was posting in Magisk General Support / Discussions thread.

I'll go find that thread and post in in there.

My apologies.

So it's not about the relevance of the post to the thread, but who and why?

And if it matters to you at all, I saw a post in another thread where a user was having an issue with Magisk and it poked my interest, (he wasn't even using PixelFlasher), this thread being the most pertinent thread with resident experts to ask about how that part of Magisk functioned, I posted it here. If that knowledge eventually can produce a tool that helps users avoid similar problems or rectify the situation, where's the harm in there?
[Magisk] pndwal:
Na... Just means that when banks etc consider that the critical mass of devices with keymaster 3+ / Android 8+ is sufficient to justify enforcing strongIntegrity in combination with a consideration of the number of modern devices (OnePlus and others) that still have broken keymaster implementations and can't pass stongIntegrity verdict, they'll adopt that option and running such bank apps etc will be out of the question for any device with an unlocked bootloader as it will be for older (A7 and earlier) devices and many (notably OnePlus but also some RealMe, Xiaomi, other) devices with busted OEM keymaster...

FWIW, I believe this decision is still a way ahead as banks will be hard pressed to make the move with this known casualty list... Further, I don't imagine Google will preempt this move either, but I think they'll be obliged to move to adopt strongIntegrity for G Pay, Playstore etc once banks do... I now believe they're waiting just like we are... This is only a hunch but...

So custom ROMs themselves are in no danger...

Eventually it seems you may also need to carry an unmodified phone in your other pocket if you wish to have a customised device as a daily driver...

😝 PW
[Magisk] pndwal:
Yeah?... With what? PW
[Magisk] 73sydney:
Maybe if it didnt tend to be post after post (along with a large graphic signature promoting software) that tends to dominate the thread when you post here, and detract from people asking actual general questions

Then theres the fact that no one here is an active developer on magisk and yet youre asking development questions, in a general thread (not sure how many times i have to point this out?)

Generally threads at least in my experience have always been separated on XDA, go and look at any devices section, theres one for development, and one for Q&A..

Ill also refer the gentleman to (which contains developer guides):

Magisk Documentation

The Magic Mask for Android

topjohnwu.github.io
[Magisk] Captain_cookie_200:
i am screwed my knox is tripped and i have no other device nor can i buy one. rip me
[Magisk] 73sydney:
knox is tripped the moment you unlock the bootloader and then flash any nonofficial binary....that is probably the most common knowledge thing in the entirety of customizing a Samsung device....

knox tripping is not the end of the world, it merely means youve lost warranty and a couple of Knox backed Samsung features, and at least one of those can be regained with magisk
[Magisk] Captain_cookie_200:
i already knew that. i never used knox features. and samsung freaking killed my fingerpritn sensor with an update which is never coming back. they also introduced a stupid mobile data bug for my phone where the mobile data would crash during heavy loads or when loading pics or something. what the hell was i supposed to do? samsung didnt fix the bug yet. i could have downgraded i know but i was done with samsung. i never used knox features anyways. and i might switch my phone soon anyway. i swear to god i am never getting a samsung phone from mid range A series.
[Magisk] 73sydney:
unfortunately the chances of downgrading on Samsung can be sometimes be limited by which ever bit your firmware is on, so a downgrade may not have been a valid option anyways

im no Samsung fan either, but they stopped making good Pixel phones (literally every one has an issue after the last one i was on) and so after 3 years away i ventured back to Samsung, wouldnt say its bene plain sailing for me either, and it will take an act of God to make me buy another one. My choice was in part because i also have a Watch ....
[Magisk] pndwal:
... so please say why this is so(?) 🤔 PW
[Magisk] Captain_cookie_200:
my phone allowed downgrading. i could easily do so.

i dont have any products from either company's eco system. since android 13 was WAY more stable then when it came with pixel 6 with so many bugs i might consider to get pixel 7 or 6. (if i have the budget)