yashsingh1/xdaforums huggingface dataset:
[Magisk] cohiba90:
I still have this error:

** Magisk post-fs mode running...

** Magisk post-fs-data mode running...

Preparing modules

Bind mount dummy system

Bind mount module items

Enabling systemless hosts file support

Mount: /magisk/.core/hosts

Bind mount system mirror

Mount: /system

Bind mount mirror items

** Magisk late_start service mode running...

service: /magisk/phh/service.sh

phh: Live patching sepolicy

phh: Mounting supath

phh: Starting su daemon

** Removing tampered read-only system props

** Starting Magisk Hide

MagiskHide: Error occurred...

What can i do?

Thanks!
[Magisk] garthybarthy:
I had this problem when I installed it on a ROM that I'd been using for a week or so and modified already.

Once I did a clean install and wiped internal storage, installed Magisk. The error was gone.
[Magisk] Portgas D. Ace:
Use suhide and root switch app.
[Magisk] andrew2432:
I saw someone using su hide with root switch and magisk, claiming success. You'll need a system version of xposed installed for root switch to hide it correctly, it can't hide 86.6. I'm trying to find someone else with success on this method, I can't remember who the guy is. He said flash sr3, su hide, magisk. I wasn't aware that sr3 would work for magisk...?

I know this q doesn't belong here but is 86.6 universal? I'm on a Samsung s5 and have to use wanam builds but I'm currently on 5.0 not 5.1.1 like sdk 22 claims to work with. Don't want mm for now because I have what I need working on here :/

Few pages back:

I didn't know suhide worked with magisk thought that was off limits lol, did v9 make some compatability?? Are you able to use modules while playing that stupid mobile game freak knock off?
[Magisk] SDMU:
What I did was , install Root Checker from the playstore and then check for root access . Root Checker informed me that I was properly rooted . I then went into Magisk Hide and selected Root Checker .

I then opened Root Checker again , this time it told me that I did not have root access .

I selected Root Explorer going into Magisk Hide again , then I tried opening some root files using Root Explorer . It showed a message that I had no root access .

I guess Magisk Hide also does hide root access ( to an extent or atleast for these two apps ie. Root Checker and Root Explorer )
[Magisk] Captain_Throwback:
FYI - SafetyNet is hidden by default when enabling Magisk Hide. There's no need to add any apps to the Hide list if that's all you're using it for. The list is only if you want to also hide it from other apps besides ones that use SafetyNet for validation.
[Magisk] Abhi142:
Are u using custom ROM or stock ROM?
[Magisk] shantam3108:
Custom rom nitrogen OS
[Magisk] Didgeridoohan:
Ha! I just noticed that after the last reboot (the earlier provided magisk.log), Magisk Hide was disabled (all modules including root still functioning). Rebooted again and everything works as expected. Suddenly, while writing this, I realise I'm experiencing the same problems you guys have reported, with lost root and also all modules gone from Magisk. Out of the blue! Another reboot brings everything back to normal, again...

This time I verify that everything is working, Magisk and root and that Magisk Hide is active. When I try an app I've checked in Magisk Hide it detects root and after that root is lost and all modules are again gone from Magisk. Reboot again and everything is back in working order.

I'm gonna disable Magisk Hide, for now. Might add an issue on GitHub later, when I have time...
[Magisk] ss4rob:
I used the latest Magic Manager 2.5, updated my phh SU module to 266-2, and flashed v9 of Magisk. I only checked the main Magisk Hide button, I did not have to add anything individually, specifically in the Magisk Hide section. Finally, I had to clear PoGo data and relogin and I'm playing again! I didn't have to clear data for Android Pay, it just worked (my chicken nuggets were delicious, heh).
[Magisk] fefuzzo:
hi, i have a xiaomi mi5s plus with android 6.0.1 and Miui 8 (from xiaomi.eu) and root (i root with TWRP recovery: i reboot to recovery and I go to advanced > SuperSu > swipe to install SuperSu)...my question is: can i install Magisk on my device?? my root version is NOT systemless, is this a problem??
[Magisk] SDMU:
You need systemless SuperSU :)
[Magisk] mrxtc89117:
I have the same problem too and it's happening more often than I want. It defeats the purpose of magiskhide. I uninstalled magisk for now and went back to supersu.
[Magisk] pndwal:
Ah... So no dirty ROM re-flash yet...

Are you sure you successfully installed Magisk to inactivate slot after OTA the last time?... Because if that boots at all, it should be with Magisk injected in boot.img and boot with root. 🤔...

I suspect you didn't flash Magisk the last time and as you haven't yet restored images properly (Magisk cannot restore those it didn't change/back up itself, ie. Dreamland patched /system); it seems post reboot partition digest check is simply tripped due to /system changes...

Despite what I said earlier, when you are ready, I'd flash your older available ROM again and flash patched boot.img to root, then try the OTA update w/ Magisk preservation method again. (Restore images, don't reboot, take OTA, don't reboot, install Magisk to inactive slot, reboot)...

Once again you may have broken Verity check this time due to Magisk patched /boot, but it may still boot (with root) with the long button press bypass you discovered... It may also boot fine without errors as these checks were only introduced in late Pixel updates AFAIK...

Even if you have verity errors but can boot with root you'll be able to find the Magisk backup of unpatched boot.img to keep for patching or restoring stock OS manually, and/or dump the magisk-patched_boot.img... Taking OTA again without installing Magisk to the inactive slot but flashing magisk-patched_boot.img normally (ie. to current slot) should fix any verity issues you had and you should then have latest OS with Magisk root...

Hope it helps. 🙂 PW
[Magisk] pndwal:
Please can you confirm that you set channel back to Stable and then got stub version 33+ again (on Magisk App home page) after restoring app and re-hiding?... Because if it remained properly matched version 21 (for 23.0 Magisk), I'll still assume that the updated stub app was the issue...

... If you turned that off I'm pretty sure the update to 33+ couldn't occur!... So you couldn't really have tested...

At least I don't think you can sideload any app without that permission...

But did you get 33+ again?...

Sure... But please confirm if you saw a stub version higher than 21 again so I can know if newest stub apps can actually work with old 23.0 Magisk for sure...

Welcome... PW
[Magisk] HippoMan:
I'm sorry that I didn't explain well and didn't make it clear that after doing the following, "33" never appeared again:

" ... set channel back to Stable, un-hide and hide app again and see if you get this again/consistently with mismatched (33+) stub ..."

I still think that something in the past (I have no idea what) somehow caused me to get into that "33" state, and I'm guessing that this caused the original error. I didn't see anything greater than "21" again when running the 23.0 Magisk, and I never saw the original problem again, either.
[Magisk] pndwal:
Thanks... Confirms the real issue was mismatched stub apk...

I think the experiment failed due to your disabling sideload permission... Even with Stable JSON pointing to stub v36, it failed to update and seems Magisk app used stub v21 in package binaries... A previously known way to get app to call packaged stub rather from than online channel was simply to disable network connections... PW
[Magisk] pndwal:
Moving this here as it may be more suitable for General Magisk audience:

If Denylist works for your apps it's fine, but really Denylist is not designed for hiding root... (My bank also works with simple denial of root + PI deviceIntegrity too.)

It retains some original pre-24.0 Hidelist code, but all prop spoofing, both for passing device integrity verdicts and for bypassing bank app detection has been removed (USNF, Shamiko and other modules set those 'sensitive' props and more now) and it now simply reverts and denies further Magisk modifications in listed processes... As John indicated, it's a 'valuable' tool, but its really aimed at software testers/developers, not root-hiding-modders.

Here's some of what John said re. 'sunsetting' MagiskHide, new Denylist and hiding modules from other Devs:

www.twitter.com/topjohnwu/status/1445598597521633285

Shamiko is a proper hiding module... It doesn't use Denylist functions (these are disabled), it simply uses the existing list for convenience but as a hidelist to unmount magisk for listed processes, restore MagiskHides 'sensitive' (suspicious) prop spoofing (sets values as if unmodded) as mentioned, as well as adding many new mechanisms for hiding 'traces of root' including Zygisk memory/leaks, isolated processes, tmp mount, traces of modified init.rc and more. Here is a complete change log for Shamiko:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-86889071

👀 PW
[Magisk] J.Michael:
@pndwal: Notes on your notes

Re: @HippoMan's adventure

Does "hide the Magisk app" work if Magisk is not installed?

If Magisk app has root privilege, maybe it doesn't really need "install unknown apps" privilege; or at least, it can grant it to itself, maybe only as long as it wants it.

Re: @newbie1113

I would have wanted to emphasize that, after OTA to new slot, before (or part of) install Magisk to inactive slot: get a new boot image from the inactive slot, to be patched by Magisk app and then flashed to inactive slot.

I'm sure there are times when the pre-OTA boot image will run (at least some) with the post-OTA system, but why make life more interesting than it has to be?
[Magisk] HippoMan:
Thank you for the idea.

However, I didn't test that case, and I don't have time (nor inclination) to go back and try that right now. Maybe some time in the future when there is less going on in my life and with my job.
[Magisk] pndwal:
I believe it doesn't...

Yeah, I'm unclear on this. There may be another reason stub didn't go to version in Stable set JSON the last time when it did previously... It was just a stab in the dark.

What I am certain of is that the mismatched v33 stub version of the stub was the source of the issue with no superuser grants... The fix was applied when @HippoMan set custom channel to archived raw JSON address for archived 23.0 Stable Magisk and later restored/re-hid the magiskApp so expected v21 stub replaced the 25.2-matched v33 build... The permission setting evidently played some part, but that the underlying issue was the always the wrong version was sufficiently confirmed for me when we knew that installation reverted to (and remained) v21 stub.

But his method will properly use the updated boot.img since it's patching /boot in that slot...The previous issue was that the current slot images had not been fully restored by Magisk Restore images process as Dreamland XPosed module had messed with/system partition... The current problems (seen w/ P6, P7 series) are evidently due to new post-boot partition digest checks introduced by Google, meaning that while both OTA and Magisk get applied correctly (and should work) the update engine will mark slot as corrupt on first reboot as these checks find the modified /boot partition.

This issue may not affect the OTA build for this device at all which is why I suggested trying again... I did mention ways to fix installation in the event that he has verity errors again but can still bypass these and boot, as he could with the/system partition verity error.

🤠 PW
[Magisk] Vovan2k:
Someone said i can install magisk by renaming apk to zip then installing with TWRP and renaming back to .apk, whats the difference between this method and simply installing APK?
[Magisk] BillGoss:
With the latest versions of TWRP you can flash the Magisk apk (as long as it's named Magisk-*.apk, eg Magisk-26.1(26100).apk) without renaming the file to zip.

This method patches the current boot image but does not install the full Magisk app - only a stub. Once the system is properly booted you will be rooted and can install the apk to get the Magisk app installed properly.

This works with the current stable version (26.1). But it may not work with Canary versions.
[Magisk] zgfg:
Simply installing just Magisk application, does not install Magisk.

Magisk application is not the Magisk itself (in the older versions, Magisk app was called Magisk Manager)

Once you install Magisk app, you must then patch the boot.img and flash it

---

If TWRP is available for your device, you can flash the apk renamed to zip to unstall Magisk

Actually, you don't need to rename the apk file to zip, TWRP 3.6.9_1 and newer will recognize the zip installation even when the file has apk extension

---

Please, study the Installation instructions on the Magisk GitHub page
[Magisk] zgfg:
You can, disable or uninstall the module you don't like😁

I have dozen of modules and only two of them create and use folders on Internal memory

And those two have corresponding apps - hence editing them would actually require rebuilding the applications

Generally, you cannot just 'prevent' them - if they need those files, they will not work without. Or you would have to change their scripts and/or corresponding apps to use the other locations
[Magisk] Vovan2k:
For some reason every time i install magisk with TWRP i am getting this dialog inside magisk app after rebooting and have to reinstall from within the app and reboot, only then it works okay.

Is this normal and expected behaviour?
[Magisk] BillGoss:
Yes
[Magisk] J.Michael:
In at least some circumstances, there is information available only when the regular Android system is booted, not when the recovery system is booted. So (clearly) some things get done when you ask TWRP to install Magisk, but some things need to be done when the real system is running.
[Magisk] @Peterrrrr:
I wounder if anyone here have any guide that is easy on how to create magiska modules?

I need to add a few lines in the /vendor/etc/camera/camxoverridesettings.txt file.

Which is is: exposeFullSizeForQCFA=TRUE maxRAWSizes=19 Into

Any tips?
[Magisk] zgfg:
Copy that file to PC (or do it in the phone with eg MiXPlorer in the Download folder), edit it and save under exactly the same name

If you have Systemless hosts enabled (for AdAway), then go to:

/data/adb/modules/hosts/system

Create there nested subfolders:

vendor/etc/camera

And put your edited file there:

camxoverridesettings.txt

And reboot

---

If you don't use Systemless hosts but any other module, then use its folder:

/data/adb/modules/<SOME-MODULE-FOLDER>

(you will see, each module has its own folder there)

Create there the nested subfolders:

/system/vendor/etc/camera/

Put there your edited file:

camxoverridesettings.txt

And reboot

Be careful, names must be exact

---

That way you can test if your Camera changes will work

Later you can play by creating your own module. Some documentation can be found on the Magisk GitHub page, under Documentation for Developers

Also, you will learn best by unzipping few module installation zip files and by studying what they contain and then by experimenting (make a change in the module.prop, re-zip, install and study what happens, etc)

But the above is the essence of what you want to achieve to let the Magisk (systemlessly) mount your edited camera file over the original

Of course, assuming that the folder and file names (the full path) you cited are correct, exactly as for your ROM
[Magisk] J.Michael:
Have you looked at the guide for module developers? Skim through it just to find the directory string.

I don't think you'll be able to overlay the file you named, unless it is actually accessed as "/system/vendor/".
[Magisk] @Peterrrrr:
Which guide? :) Link?

What is a Systemless host? :)

Are there any other explorer that are a freeware, MiXPlorer isn't free.
[Magisk] J.Michael:
Google "magisk module developer guide"

This has a section that hits the high points. You'll have to dig to find if you can just add a "vendor" directory under "/data/adb/modules/yourmodulename/system" and that will automatically overlay "/vendor", or if it only applies to a system where "/system/vendor" is a symlink.
[Magisk] zgfg:
/system/vendor

and

/vendor

are linked one to another. That's the essence for all modules that do changes on /vendor

@Peterrrr- on the Magisk GitHub page, follow:

Magisk Documentation/ Developer Guides

Developer Guides

The Magic Mask for Android

topjohnwu.github.io
[Magisk] dcarvil:
Link to free version of MiXPlorer.

[APP][2.2+] MiXplorer v6.x Released (fully-featured file manager)

[APP][2.2+] MiXplorer (full-featured file manager) Hello everyone! My name is Hootan. I work on XDA in my free time and this file explorer is my favorite Android project! MiXplorer mix of explorers (SD, FTP, Lan, Cloud and other storage...

xdaforums.com
[Magisk] zgfg:
Systemless hosts is an internal module you can enable in the Magisk Settings, that let the AdAway app similarly mounts over /system/etc/hosts file to block ads

Do you use any other module?

See the second part of my post about misusing their folders

Sorry, I don't have time to start from the very basics

Ive seen Senior member so I thought I give you the essence and you will be familiar and will figure out the rest
[Magisk] J.Michael:
Mixplorer is as free as free can be.

You clearly haven't tried very hard.

If you found Mixplorer on Google Play Store, you should have been drowned in other, *free*, file explorers. Enjoy the ads.

"systemless hosts" is either a specific Magisk module, or a side effect of a specific Magisk module. @zgfg just picked it as a module he thought you might already have, to absolutely minimize the effort needed to try to do what you want to do to see if this approach works.

Which is never going to happen until you actually try something.

You are right to be cautious. Learn to boot to Safe Mode before you make a module, or add a file to an existing module.
[Magisk] J.Michael:
I wasn't sure whether Magisk does something special for "vendor".

If the "vendor" partition is mounted at "/system/vendor", with "/vendor" symlinked to that, I would expect it to "just work" when someone puts a file in "$MODNAME/system/vendor".

If the "vendor" partition is mounted at "/vendor", with "/system/vendor" symlinked to "/vendor", I would expect Magisk module modifications to "system/vendor" to only be visible when the app or system component references "/system/vendor" -- *not* if someone refers to "/vendor". At least, not unless "vendor" gets special treatment in Magisk, and Magisk overlays "/vendor".

I remember some discussion, I came away thinking there was a short list of partitions other than "system" that got overlayed, I don't remember if "vendor" is currently special.
[Magisk] zgfg:
It always works for /system, /vendor, /product, /system_ext and /apex)

You can play debloating system apps (from those partitions and on the new ROMs from more, like /odm, /india, /my-bigball and so):

GitHub - Magisk-Modules-Alt-Repo/SystemlessDebloater: Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP

Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP - Magisk-Mo...

github.com
[Magisk] chickenben81:
So I've been trying to get read-write permissions for my root directory and am unable to do anything but see root files on motorola g power 2022. I am wondering if when I rooted with magisk something went wrong and I never was given any permissions or magisk just doesn't enable write access. Im really confused and could use some help.
[Magisk] zgfg:
On the new phones (that 'new' already means couple of years ago) System is READ-ONLY on the File-system level, and Magisk/root will not make it writeble

Instead, Magisk provides SYSTEMLESS root, it mounts the changes over the read-only System every time on booting. That's the way all (systemless) modules work

Over the few last years this has been many times responded here in the thread, with more details. You can also google about the systenless (root) term
[Magisk] chickenben81:
So there really is no way to gain write permissions anymore. things have changed a lot
[Magisk] HippoMan:
Yes, things have deteriorated a lot.
[Magisk] zgfg:
Not in the way that you could change file-system permission from ro (read-only) to rw (read-write) and that you could make permanent changes

Please study how systemless rooting mechanism do. Eg, enable Systemless host and see how AdAway makes 'changes' to /system/etc hosts file

You will thousands and more blocked sites) in the hosts file but when you disable Systemless hosts or boot without Magisk, it will be back the original hosts file with few lines

Also, if you have TWRP for your device, you will see in TWRP the original, unchanged hosts file (since when TWRP boots, you are not in Android, Magisk did not boot and did not mount the changes over the hosts file)

By the way, all that is safer for you regarding the OTA
[Magisk] pndwal:
RO /system is actually due to new shared blocks / dynamic (ie sub-super) partitions.

These behave very much like Linux LVM, being flexible and easy to change around:

https://source.android.com/docs/core/ota/dynamic_partitions

These must be RO... Requirement for stock A10+ introduced alongside project Mainline (modularised Android progression from Treble)...

https://source.android.com/docs/core/ota/dynamic_partitions/implement

Maverick modders can actually still reformat everything and restore standard partitions mountable RW (no more super) however... I've linked a couple of methods published on XDA in the past for the very adventurous...

Also, while required for stock ROM certification it's not required in custom ROMs 😜...

Custom ROMs can of course do what they like, and I don't know of any that have sacrificed RW in favour of partitions with no wasted (empty) space that dynamically resize... But there may be some...

👀 PW
[Magisk] zgfg:
Kudos (again) to @osm0sis, for his module:

GitHub - Magisk-Modules-Repo/adb-ndk: adb-ndk

adb-ndk. Contribute to Magisk-Modules-Repo/adb-ndk development by creating an account on GitHub.

github.com

I was on vacation without a notebook, but I brought two phones and an USB-C two side cable ('just in case')

At the end I couldn't resist to test again patching and flashing KSU

I used Terminal emulator and magiskboot to unpack boot.img:

/data/adb/magisk/magiskboot unpack boot.img

and to repack upon replacing the kernel:

/data/adb/magisk/magiskboot repack boot.img

and MTP over USB cable to transfer the patched new-boot.img to the other/helper phone

Then again USB cable and the Fastboot NDK module from the helper phone for testing:

fastboot boot new-boot.img

Unfortunately,the AOSP kernel is no good for MIUI, it booted but touch screen did not work. Hence I safely rebooted to my Magisk patched boot.img

Without the double USB-C cable and Fastboot NDK module, I would have to permanently flash the KSU patched new-boot.img through TWRP

However, since the phone has Recovery integrated to Boot, if new-boot.img was not bootable, I would need PC to unbrick (to flash back my TWRP+Magisk patched boot img)
[Magisk] osm0sis:
Recently did something similar while my laptop was away being fixed! Surprising how well it works.

Only trick is knowing how to make the correct device the host, then the extra manual `su -c stop adbd; start adbd` step (but no simple way to automate that since it's only needed once per boot).
[Magisk] zgfg:
I didn't observe. Maybe I had to call adb devices / fastboot devices twice to start the daemons and to reconnect, but cable was loose (short connectors and masks on the phones) hence I attributed to my cable

Once I also lost the loose connection but it was not risky for fastboot boot compared to fastboot flash