yashsingh1/xdaforums huggingface dataset:
[Magisk] zgfg:
If he has a problem caused by some module (as he claims):

See the answer right below yours - reflashing Magisk will not help since Magisk will again find the problematic module in /data/adb/modules (reflashing Magisk does not disable/uninstall modules)
[Magisk] podiwadda:
Thank you a lot. Will try this 🤗🙏
[Magisk] jons99:
fastboot flash boot will flash your active boot partition in an ab device
[Magisk] m0han:
If you have a working TWRP, why don't you just delete that 'bootloop saver' module folder? If that doesn't work just flash the Magisk apk (or renamed zip file), provided you haven't already done that.

I doubt you have a patched file (or can patch one), since you don't have root ATM.

I'm sure the more knowledgeable folks here will advise you better on this.

p.s.: I see they already have.
[Magisk] Fry-kun:
#rant

I understand preventing downgrades is usually desirable, but something like this is a lifesaver if you don't have access to a computer temporarily... From past bad experience I tend to delay magisk upgrades for the same reason.. and still have problems
[Magisk] J.Michael:
@podiwadda Is there any chance you used "hide the magisk app" to change the package name and then installed another Magisk app?

See if you have a file "magisk" in one of your bin directories (/bin, /xbin, /sbin, /system/?bin)
[Magisk] podiwadda:
No I did not. Only the modules. By the way I found its not modules making it that way. When I try to add Google apps to set in deny list. That's what cause the issue.
[Magisk] podiwadda:
Hey I did this . I mean I didn't fully understood this. But I removed everything saying "magisk and "bootloop" then phone restarted and root back as normal . I reflashed just to make sure. Btw I found out that modules not causing the losing root. It caused by setting play store in deny list
[Magisk] J.Michael:
Still not a reasonable sounding problem. I have never heard of adding something to the deny list causing the loss of root. Unless maybe you added 1000 things to the deny list, and the Play Store was one too many.

Will you please check to see if the file "magisk" is still in one of your "bin" directories. Then try running it from a command prompt.

Assuming you're interested enough to recreate your problem.

EDIT: OK, I take it back, I guess if you put the Magisk manager app in the deny list, it will look like Magisk is no longer running.
[Magisk] shoey63:
Not only does it work, but if you take a few extra steps, you can make a 100% clean install of ANY Magisk version or fork without PC or TWRP.

Here's how I do it :-

- Download Magisk version/fork you want to try

- Add .zip to the end of the Magisk apk eg: Magisk.apk becomes Magisk.apk.zip

- Unhide the Magisk app if you have hidden/renamed it

- Turn on aeroplane mode

- Delete /data/adb/Magisk folder and /data/adb/magisk.db file

- In Magisk app, perform Uninstall Magisk - RESTORE IMAGES so you are back on stock boot image

*edit: Skip this step if no backup image is found. Magisk manager will reconstruct the existing patched boot image

- Install the new Magisk.apk.zip as a module

- Change Magisk.apk.zip back to Magisk.apk

- Uninstall the Magisk app (the apk only NOT Magisk itself)

- Reboot

- Install the new Magisk.apk

- Open it up and check settings and modules and customise to your needs eg: zygisk may need to be re-enabled and deny list reconfigured

- Reboot again and turn off aeroplane mode

You will now be on a new clean install of whatever Magisk you are trying. No loss of root or modules and no need to clear data from play services to re-enable wallet (assuming it worked before and you set everything up properly)

Only thing left to do is grant root to whatever apps need it.
[Magisk] ctcx:
As part of the "learning" process, I downloaded current Magisk 25.2 apk and manually unzipped it, then compared the included boot_patch.sh with the current one here

Magisk/scripts/boot_patch.sh at master · topjohnwu/Magisk

The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.

github.com

and noticed the first one may be few commits behind.

Notably, apk one still lacks PATCHVBMETAFLAG and RECOVERYMODE flags; despite this, when patching with the app it does show a possible option "Patch vbmeta in boot image".

If apk's script lacks that flag, how is it possible that it shows the option in the app?
[Magisk] badabing2003:
@pndwal

Question for you, I'm pretty sure you know the answer to this :)

I wanted to hand me down my Pixel 6 to my son, he wanted it rooted.

So I did the following.

Considering that it already had Magisk Canary 25206 installed, I patched the latest stock boot with it.

Flashed latest factory image with wipe option.

To both slots (inconsequential, but mentioning regardless)

Didn't reboot to system (used the flag to skip reboot)

Flashed the patched boot

reboot

The system booted normal, and was prompted with standard Google phone setup.

After the setup, I installed Magisk 25206 canary, matching what was in boot.

Upon launching Magisk, it told me that it needed to setup something, or something along those lines.

Zygisk was not active, and even though it was showing Magisk installed, the Install button was active.

I ignored the message, I figured I have the core and I also have the Manager, why do I need to do anything else.

Changed the settings, to enable Zygisk.

then tried to install a module, which failed with a message that Magisk installation is not complete.

Why did this happen, and what exactly Magisk had to do to be complete?

I proceeded with direct install, reboot

Zygisk was still disabled, then I enabled Zygisk and rebooted.

All was good after that.

Still would like to know what was missing.

Thanks
[Magisk] J.Michael:
What makes you say "apk one still lacks PATCHVBMETAFLAG and RECOVERYMODE flags"?

The implementation of a function in a program is separate from whether the program connects environment variables to the function.
[Magisk] zgfg:
This is usual. It shall reboot one time and then you use it
[Magisk] badabing2003:
Do you know why?

What actually it is doing?

I understand a reboot is needed of you enable or disable zygisk, but i got the prompt before i toggled anything, i got it as soon as i started the app.
[Magisk] ipdev:
Too late. 😿

Magisk- [GitHub] - commit

Cheers. :cowboy:
[Magisk] shoey63:
Whilst you had the necessary ramdisk/boot image changes and the Manager apk installed, /data/adb had not yet had a chance to be populated with the required Magisk files, having just come off a factory reset.

This happens upon the next reboot, and I presume is done by the Magisk manager, once fully installed.
[Magisk] ctcx:
Finally installed Magisk on an ocean (Moto) device with LOS 20.0. With Zygisk active, universal safetynet module, and adding the infamous banking app to deny list, app finally let run instead of complaining "device cannot be trusted, exit".

But there were big problems, which I describe in 2 separate posts.

First, trying "fastboot boot magisk_patched.img" did not work at all.

Fastboot output:

fastboot FAILED (remote: '') # yes, [B]nothing[/B] inside the simple quotes...

Bootloader logs:

incomplete boot image downloaded

I tried with su in PC console, "--set-active=b" just to be sure (albeit it's always slot b, and it already was), different platform-tools versions... NOTHING.

Why is this?
[Magisk] ctcx:
The other problem was with patching boot.img via script.

In order to be able to use boot_patch.sh without root, these links were the ones:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2608#post-87014873

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2456#post-85933007

So:

---Downloaded latest Magisk apk from Github

---Unzipped lib/arm64-v8a/{libmagisk64.so,libmagiskboot.so,libmagiskinit.so} and assets/{boot_patch.sh,util_functions.sh}

---Renamed the *.so removing the "lib" and ".so" parts

---Put original boot.img among all these files, and all of them in one single directory

---Pushed all of them to device's /data/local/tmp/tempdir

---Chmod all to 0755, except boot.img, which was 0644

---adb shell "cd /data/local/tmp/tempdir && ./boot_patch.sh boot.img

The patching was successful, but not so the flashing...

As mentioned in the above post, fastboot boot didn't work, so had to just directly fastboot flash boot.

The boot.img patched by Magisk app directly was ok.

The boot.img patched by scripting like described above, did flash, but did not boot. When LOS was trying to boot, it just ran the animated booting logo endlessly (boot loop?).

I hard reset, tried to flash the "good" patched img, or even original one... now fastboot command hanged with no response until hard resetting device...

In another try I got

error: Failed to identify current slot

Rebooted into LOS recovery, it said slot b was active (as always for this device).

Back into bootloader mode. Again ran fastboot --set-active=b. It already was set.

Then suddenly it let me again flash either the Magisk patched img or the original one.

One thing, since the very beginning, when flashing I always got these messages:

<bootoader> logical has-slot: slot_b not found
writing boot_b image not signed or corrupted

However in the end everything went ok according to fastboot.

Do you happen to have an idea why I got these shenanigans when trying the "scripted" patching?
[Magisk] J.Michael:
What inspired you to remove the "lib" and ".so" parts?
[Magisk] pndwal:
"Your device needs additional setup..." message is associated with env_fix, fixenv, EnvFixEvent etc routines in app/src/main/java/com/topjohnwu/magisk/core/tasks/MagiskInstaller.kt and other files...

Seems it may be called for several reasons, but additional setup is generally needed where /data is wiped after Magisk is set up or a /data wipe is associated with an initial Magisk installation... For the reason that flashing CSC Odin binary necessarily wipes /data, this note is included in Installation Instruction for SAR+ Samsung devices:

So the Magisk App simply detects the missing configuration files...

As @shoey63 indicates above this occurs "coming off a factory reset" and it can actually be reproduced simply by removing Magisk folder and .db from /data/adb while booted and opening app again...

Without digging into the code further this indicates to me that the 'Additional Setup' needs no special routines in this case, only a simple reboot to rebuild configuration files which happens automatically if they're missing anyway... Seems we just need two reboots after factory reset / data wipes simply because Magisk cannot build configuration in /data/adb until initial Android Setup is performed.

Since it seems that if you'd simply rebooted and done intial Android setup after

Instead of

and then

You would have avoided "Your device needs additional setup..." message.

... Also, regarding this:

it's not clear if you rebooted between enabling Zygisk and installing module... Doing that should have fixed the Magisk environment at that point... 🙂 PW
[Magisk] pndwal:
Actually Magisk daemon does this even if App is not present... The App will (inconsistently) force the reboot however. 😉 PW
[Magisk] pndwal:
Funny, I put that link with the Twitter link!

... Edits disappear on my device if I swap from XDA page in browser to copy something and forget to refresh when returning... 🤷 PW
[Magisk] zgfg:
With Magisk Delta, it asks me on every update (I always do patch and flash), I let it 'finish' the installation, it reboots and no problem
[Magisk] pndwal:
You mean it asks to do Additional Setup?

Interesting... Are you also removing anything from /data/adb or taking Complete Uninstall? PW
[Magisk] zgfg:
Yes, finish or additional setup or so (I don't pay attention, I let it do)

No, I don't wipe anything, just updating Delta by patch and flash (Delta Canaries come several times a week)
[Magisk] m0han:
With Magisk Delta Canary 'Direct Install' too. I was thinking mine was one of those rare cases.
[Magisk] pndwal:
... Wonder if Delta does that after Direct Install to update too?... PW

... Edit: Answered above!... Thanks... Must be additional reasons...
[Magisk] martyfender:
Yes, I also almost always use the direct install method with my device that has Magisk Delta debug on it.
[Magisk] zgfg:
And does it also ask you to do additional setup and reboot?

Btw, Magisk does not install Magisk binary, its scripts, BB to /data/adb/magisk but it links to /data/unencrypted/MAGISKBIN and installs them there

Don't know is that additional setup related to that

But sometimes I update Delta, forget to open Delta app and run the phone with no problems (modules work, etc) although I didn't do additional setup
[Magisk] badabing2003:
Thank you @zgfg @shoey63 @pndwal

It makes all sense now,

I don't recall ever needing to reboot when I did the following steps manually, most likely my memory is not serving me well.

Brand new system, setup phone

Install Magisk

Create Patch (at this point /data/adb/magisk can't be setup, no root yet)

Reboot to bootloader and flash the patch (still no /data/adb/magisk)

Reboot to system and Magisk works and does not need to reboot.​

Is this not the case?

If it does need to reboot then what follows below spoiler is moot and everything is clear,

Spoiler content hidden.

No I did not, which explains it, thanks.
[Magisk] badabing2003:
If you're running boot_patch.sh those are referenced without .so

but if you're calling ligmagiskboot.so and others directly then there is no need to rename anything.

Here's an example script generated by PF to create a patch using boot_patch.sh on an unrooted system

#!/system/bin/sh
##############################################################################
# PixelFlasher 4.8.1.0 patch script using Magisk Manager 25.2:25200
##############################################################################
ARCH=arm64-v8a
cp /data/app/~~wUtBmsEAIr1uaL-H7KirJg==/com.topjohnwu.magisk-Bsw07ODC_tLE4-KThHUD3A==/base.apk /data/local/tmp/pf.zip
cd /data/local/tmp
rm -rf pf
mkdir pf
cd pf
../busybox unzip -o ../pf.zip
cd assets
for FILE in ../lib/$ARCH/lib*.so; do
NEWNAME=$(echo $FILE | sed -En 's/.*\/lib(.*)\.so/\1/p')
cp $FILE $NEWNAME
done
cp ../lib/armeabi-v7a/libmagisk32.so magisk32
chmod 755 *
export KEEPVERITY=true
export KEEPFORCEENCRYPT=true
./magiskboot cleanup
./boot_patch.sh /sdcard/Download/init_boot.img_4d938d3c.img
cp -f /data/local/tmp/pf/assets/new-boot.img /sdcard/Download/magisk_patched_4d938d3c.img
[Magisk] pndwal:
True, it is the case... No need for another reboot since you've already done one since flashing Magisk and Android system setup...

App doesn't need to be installed... Magisk daemon does the config setup... App will only notify you of need for extra setup (just a reboot actually) if it's opened...

Magisk Daemon succeeds in instance above because /data can be written to...

No, sorry...

You may have missed what I put in italics here:

... the important difference is actually that you (re)booted after the system was up... When you installed the Magisk App is immaterial...

In your originally scenario requiring 'additional setup' there was simply no booting with 'system up'... Magisk daemon could not set up configuration on first boot (following factory reset) because /data cannot be written to before the Android Setup is performed (system is preventing this) and you bypassed a reboot using flags...

Simply put, no boot with Magisk installed and Android configured had yet occurred... (Again, the App doesn't enter this equation)...

👍 PW
[Magisk] badabing2003:
Thank you @pndwal

This is the key subtlety I was missing.

Makes perfect sense.
[Magisk] ctcx:
@badabing2003: Thanks for clarifying.

By any chance, could someone perhaps help with the two previous issues?

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2745#post-88304845

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2745#post-88304875

Thanks.
[Magisk] badabing2003:
Have you unpacked the two (the good patch and the bad patch) and checked their differences?

I'd be curious to see what patch you get if you run the script as I showed above,

I see you're excluding Magisk 32 and also you're not doing magiskboot cleanup.

Instead of editing the script and adapting, you can use PF to do it all for you, obviously you don't need to flash.
[Magisk] ctcx:
I did try taking a look at PF source code at Github, but unfortunately I still know nothing of Python, thus could not understand much...

Having just seen that community here tends to be highly intolerant towards non-devs/non-experts in general, I realized I was almost completely on my own. Then, I was only able to follow what boot_patch.sh said in its code.

For all the above facts, yes, I did not export the KEEPVERITY=true and KEEPFORCEENCRYPT=true env variables -how am I supposed to know they're always needed no matter what device?-, did not unzip magisk32 -why on earth if ARCH in my case is arm64-v8a?-, and did not run magisk cleanup before patching -is this important?-.
[Magisk] zgfg:
The following question is not about Systemless hosts or AdAway (they work properly for me) but about traceroute applet in the Magisk busybox:

I have ads.google.con blocked in my /etc/hosts file (thanks to Systemless Hosts and AdAway)

Indeed, if I run:

cat /etc/hosts | grep ads.google.com

I obtain as on the screenshot:

0.0.0.0 ads.google.com
...

Hence if I open https://ads.google.com in browser (Chrome), I properly get ERR_CONNECTION_REFUSED (screenshot)

Also, if I use the built-in toybox and its traceroute command:

toybox traceroute ads.google.com

I correctly obtain (screenshot):

traceroute to ads.google.com(0.0.0.0)
...

Same result if I use traceroute through the PingTools app (from PlayStore) - screenshot

But if I use traceroute in the busybox built-in to Magisk:

/data/adb/magisk traceroute ads.google.com

then it ignores the hosts file and instead it resolves ads.google.com through DNS to its real address 172.217.19.110 (screenshot):

traceroute to ads.google.com (172.217.19.110)
...

Maybe @osm0sis or @ipdev (or somebody else) would know?
[Magisk] osm0sis:
Almost certainly from my patches to hack around Android Bionic libc being terrible for static compiled binaries:

https://github.com/osm0sis/android-busybox-ndk/blob/master/patches/050-b-xconnect-dietlibc.patch

and

https://github.com/osm0sis/android-busybox-ndk/blob/master/patches/050-c-dietlibc-dnscruft.patch
[Magisk] badabing2003:
It's ok not to be a dev or know Python, you can use the program as a user,

it would extract the boot from the image, transfer it to the phone, create the script based on the chosen file, create the patch and pull it back to your PC, and it is cross platform.

You can inspect the generated script which is bash, and understand what it is doing without necessarily knowing one bit of python.

The program is very verbose so that people can follow what is going on.

Generate a patch using the program, and let's assume this patch is not exactly what is needed and functional, let's call it a bad patch

Also generate a patch the manual way that you know works, and let's call this a good patch

Next you would compare the two, the patched boot files can be unpacked and compared.

This can be done on the phone or if you are more comfortable doing it on the PC, you can use the excellent toolkit Android Image Kitchen by @osm0sis

Even a binary diff would give you an idea of the difference.

See further below.

I don't agree with the above generalization, there's always outliers, but in general the community is very helpful, and amazingly patient even with newcomers, what is typically not tolerated is people not putting in the effort to research or even read few posts and expect all the answers to be delivered on a platter.

When a senior member who is well seasoned and knows what he/she is talking about, asks a specific question to be able to offer advise, and it is evaded, it naturally irks the person.

Almost always there is a lot of context in the questioner's mind that is not totally relayed in the post, hence why specific questions are asked and answers expected.

You're not supposed to know, but you find out with exploratory observation, testing, trial and error and of course differential analysis.

For example I didn't know about the KEEPVERITY and KEEPENFORCEENCRYPT flags when I first called boot_patch.sh, and just like you the generated patch was not good and different from a good patch.

I did a binary diff of the two (at the time I didn't even know I could unpack) and noticed those two keywords existing in the good patch, but not mine.

Read up about it, inspected the script, and asked questions to eventually figure out the right options to use to generate an identical patch.

Same with the Magisk32,
[Magisk] pndwal:
Did this get truncated? 🤔 PW
[Magisk] badabing2003:
no, as in similar approach to determine that I needed to include Magisk32 binary when creating a patch

It was an answer to this point

Because creating a patch manually using Magisk only matched the output from the boot_patch script when it was included.

Perhaps the exclusions were benign, but I wanted to generate a patch exactly an equivalent of the manual patch.
[Magisk] zgfg:
Ok, thanks. Hence the same problem would be then also in the BB for Android NDK

---

Btw, do you know, is there something like /etc/nsswitch.conf for Android (I looked on my two Xiaomi phones A11 and A12, cannot find or anything similar):

What is the /etc/nsswitch.conf file in Linux – TecAdmin

What is /etc/nsswitch.conf? /etc/nsswitch.conf is a Linux configuration file that specifies how the system should switch between different name service providers. The file can be used to configure which services should be used for hostname lookup, password lookups, and so on. Advertisement...

tecadmin.net

That Linux config file defines the order of precedence in resolving hostnames - hosts files first, then DNS service or vice versa

I'm curious if users who report that they have properly configured Systemless hosts and AdAway, and that they indeed have a properly mounted AdAway patched /etc/hosts file but that it is ignored (hosts pushing ads not blocked), that they maybe have a related problem with the order of precedence in resolving hostnames
[Magisk] osm0sis:
No haven't seen that one yet, but you could experiment by adding one with Magisk and see if anything respects it. 😛
[Magisk] zgfg:
I did test on my two Xiaomi phones, MIUI 12.5/A11 and MIUI 13/A12

None of them had the /etc/nsswitch.conf file, or anything similar

I created the conf file as zipped and attached (XDA does not allow conf extension attachments) and copied the conf file to:

/data/adb/modules/hosts/system/etc

After reboot, the conf file was mounted to /etc (as 'required')

Initially, the conf file defines:

hosts: files dns

Then I tested the opposite (both options are prepared in the same conf file, one must be commented out, the other un-commented):

hosts: dns files

and rebooted - but the conf file seems to be ignored, /etc/hosts file has always the precedence over DNS (ads are always blocked for me via the hosts file)

PS: Maybe if somebody with A13 (latest Pixel update) would like to test😁
[Magisk] ctcx:
Thanks again for your whole advice.

However, still nothing of this would explain my first problem back here:

https://xdaforums.com/t/magisk-general-support-discussion.3432382/page-2745#post-88304845
[Magisk] Elsrougy:
Did you get any answer? Absher, Nafath & SNB (Bank) all not working now
[Magisk] olik2000:
Yeah same for me
[Magisk] Nergal di Cuthah:
That was from a while ago (many magisk canaries). So lets start with basics.

What device

What android version

What other mods do you have

What version of magisk (canary stable beta and number)

What version of usnf are you running

What's in your deny list

All of that will make finding what is being seen by the apps easier . It is HIGHLY UNLIKLY that it is belching on strong integrity nobody to date uses that one, and if, by slight chance they are -which they're not - then the only remedy is to unroot and relock your bootloader and turn off oem debug.
[Magisk] pndwal:
Fastboot temp booting images doesn't work on all devices... Did you try flashing? PW