yashsingh1/xdaforums huggingface dataset:
[Magisk] ctcx:
The issue here:

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

where applying @osm0sis 's suggested tests in manager.sh do NOT yield the same result as what actually app UI tells.

Tests result in "Ramdisk = No"; app UI tells "Ramdisk = Yes", and I need to know where the difference is.

@zgfg :

You forgot I did try what you insist:

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

And happens with ALL tested boot images: patched with app UI, patched via scripting, even with original fully functional boot.img.
[Magisk] J.Michael:
Say what "issue" you want to resolve. Do not point to another post and say "the issue buried somewhere in that post". Do not repeat everything you ever thought, or everything you ever tried, or all of your hopes and dreams. Just describe the one "issue".

I, personally, would prefer that you not "link" to other posts -- the XDA system displays the thoroughly useless first post of the thread. If you would "Quote" the post (there's a "Quote" button at the end of every post; there's an "Include quotes" button in the UI where you compose a post) the amount of the referenced post displayed will be limited, but at least will give some idea of what it says, without requiring that I follow the link immediately.

If the "issue" is that you have not yet been able to reproduce the Magisk manager app's "Ramdisk: Yes/No":

Did you try a "wrapper" for the shell script function you found? At the time you reported several script fragments, there was talk of needing to call other functions first to set up environment variables.

Look up the "echo" command. There is a form that causes the shell to echo all lines as they are executed. Do this, redirect output to a log file, and you can crawl through and maybe spot where it first disappoints you.
[Magisk] badabing2003:
I'm running into an interesting problem that I can't put my fingers on, and am open to ideas / suggestions.

As you may already know, Magisk embeds the SHA1 of the stock boot image used to create the patch into the patched image, this is great because one can easily determine the source image that was used and validate if it is what it is supposed to be.

And this is exactly what PF does, it extracts the SHA1 from the patched image.

Here's the function code

def extract_sha1(binfile, length = 8):
with open(binfile, 'rb') as f:
s = f.read()
# Find SHA1=
pos = s.find(b'\x53\x48\x41\x31\x3D')
# Move to that location
if pos != -1:
# move to 5 characters from the found position
f.seek(pos + 5, 0)
# read length bytes
res = f.read(length)
return res.decode("utf-8")

Unlike magiskboot and Android Kitchen Tools by @osm0sis which extracts the ramdisk.cpio and performs magiskboot cpio <ramdisk.cpio> sha1 on it, PF (to keep it lightweight) it just looks for the string SHA1= directly on the patched file and then reads the next 8 hex characters and converts them to ascii.

And this has worked flawlessly so far, until this.

Basically what is happening is:

The expected embedded SHA1 is: 40100d6b9512f6dffbb6f6b67c1b878f3bd82d18

With the exception of the red part of the SHA1, everything matches.

In one case 0100 part which is expected to be 30 31 30 30 hex it is instead 89 00 FB 33, and in the other case it is 72 00 FC 15

I don't understand why this is happening, my first guess would be some kind of encoding, but then why now and only with this image, my other guess / fear is that perhaps the writing is not clean which would be a bug in Magisk.

Obviously I can skip over the first few bytes and do the validation with the remaining bytes, but I'd hate to take a path like that without understanding why this is happening, who's to say that this thing can't happen on the other portions of the SHA1 string.

If you have any ideas, I'm all ears.
[Magisk] ctcx:
Regarding this whole suggestion, is it actually affected by the fact that I'm trying in a completely unrooted device, which has never been installed Magisk before?

Because I just began like normal: get 26.1 apk from Github releases and install apk in device. Like this, I'm completely unable to find most of Magisk stuff even with adb root (custom ROM here): for example, even trying the find command on entire '/', there's no assets stuff anywhere, thus nothing about the scripts.
[Magisk] J.Michael:
What "issue" are you trying to resolve?
[Magisk] osm0sis:
I believe "needing to call other functions first to set up environment variables" is exactly why he is getting a different result from the app. 👍

I could gut out all the relevant bits for him to run, but, not trying to offend here, I kind of don't see what the point of all this has been, so I don't think I can justify putting in that amount of effort when I've got my own stuff to be doing... 🫤

Edit: One final thought. It could also be that he needs to use Magisk's busybox and busybox ash env for some of the commands like Magisk would be to get the intended output.

The boot.img contains the ramdisk.cpio.gz/.lz4/.lzma/.xz and while text strings may get stored as-is in a compression format, that isn't guaranteed and the compression might find something it thinks it can "optimize" for space savings. That's why `magiskboot cpio <file> sha1` is run on the uncompressed ramdisk.cpio. 🙂
[Magisk] badabing2003:
Thank you, that makes a lot of sense
[Magisk] m0han:
Did you install using 'universal' or architecture-specific apk? How is Fox's Magisk Module Manager (FoxMMM) Androidacy Module Manager for you with v2.0.2?
[Magisk] zgfg:
Thanks, I was on the Action builds v2.0.1 (I reported two bugs, they were fixed in the Action builds)

One was "Hitting a snag" when trying to install any module from the online Repo (Alt Repo) - but now in v2.0.2, the same bug is again present for me - see the screenshot

[BUG] Hitting a snag when trying to install a module · Issue #2 · Androidacy/MagiskModuleManager

Just installed the new AA MMM v2.0.2, and I have again the same bug as previously reported for Fox MMM v2.0.1 (it was fixed in one of the Action builds and I successfully tested): Fox2Code/FoxMagis...

github.com

Can you try on your side pls
[Magisk] m0han:
For me too. I tried to install your module. ;)
[Magisk] zgfg:
You can confirm to the new AA MMM Github, I just reported the Issue - see a link in my previous post
[Magisk] m0han:
SNAFU with Androidacy Modules Repo enabled.
[Magisk] zgfg:
Installation fails with any module, I tested also with an Upgradable module, and when I tried to install a module zip file from the local storage

Sad that the same bug was present in Fox MMM v2.0.1, fixed in one of its early Action builds, but now reappeared again
[Magisk] m0han:
Wonder how this was missed during the developer team's testing. All fine with v0.6.7 that I was running for a long time (prior to my recent testing).
[Magisk] ctcx:
@osm0sis , @J.Michael , @pndwal , everyone else:

I realized -too late as always- that it was me the one missing and misunderstanding ALL the information, and I owe all of you apologies.

Yesterday, even before all your postings of today, I decided to start over from zero: search and read about the basics of Android partitions, and then the seamless updates (A/B devices) introduction, as well as its close relationship with SAR.

With these basics finally given, I went re-reading the docs again:

Android Booting Shenanigans

The Magic Mask for Android

topjohnwu.github.io

Finally realizing things:

The Moto ocean device I currently use is Type II -it's A/B device-; the older Moto osprey one was originally good old Type I, turned into Type IV with the custom ROM based on Android 10.

Type III devices are the ugly ones which need patching in recovery, and seemingly they were only a handful A-only during 2018-2019; the "good standard" has always been ramdisk in boot partition.

With all of this, I re-did all my failed tests, and this time they all matched.

Thanks very much everyone, and sorry again.
[Magisk] NEOVerse!XChara:
ok, after my last post, i thought i know how to fix magisk at all...

TL;DR: After flashing magisk on pixel experience phone keeps rebooting (bootloop)

after flashing new ROM (Pixel Experience) from this site: https://get.pixelexperience.org/mi439 the ROM working well, but when im trying to flash magisk 26.1 or 25.2 (btw i changed my ROM from crDroid to this due Magisk made my phone literally brick) the phone can't load to the ROM and just bootlooping.

after renaming magisk-[26.1/25.2].zip to uninstall.zip the bootloop still stay, the thing what made my phone work is reflashing the ROM, using Shizuku via wireless debbugging just to get minimal root features or adb commands isn't that fun as uding Magisk.

tried methods to flash magisk:

TWRP (bootloop)

ADB SideLoad (still bootloop)

flashing boot image via magisk app (in "repacking image" state magisk crashing and Downloads folder show file, but it is 0.0MB/MiB)

Flashing Magisk after/before flashing (bootloop/Magisk don't work)

Installing Magisk via TWRP, and then factory reset/clearing caches/full reset (still bootloop)

anyone who had this problem and solved that, say me the solution, please. thanks
[Magisk] rodken:
Why aren't you using the fastboot method?
[Magisk] zgfg:
Custom ROM. Click to his link
[Magisk] Homeboy76:
Blame my post on no morning coffee. :ROFLMAO:

I Deleted the comment. :)
[Magisk] NEOVerse!XChara:
what is that? i've never heard about doing Magisk in fastboot mode
[Magisk] NEOVerse!XChara:
For You and others: TL;DR: After flashing magisk on pixel xp, phone bootlooping
[Magisk] zgfg:
Have you ever read the official Installation guide on Magisk GitHub (patching and flashing in Fastboot)

Also, countless times mentioned here
[Magisk] NEOVerse!XChara:
btw the one funny moment is that i changed the rom, stuck with recovery and all of things with this issue... ...made by me! i was 25.2 user. after 20 days of github showed 26.1, i installed that. boom, no su anymore,

Spoiler content hidden.

Spoiler content hidden.

Spoiler content hidden.
[Magisk] NEOVerse!XChara:
uhhh, magisk having that?
[Magisk] NEOVerse!XChara:
ah, you mean patching boot image and flashing via fastboot?
[Magisk] NEOVerse!XChara:
if yes, when im doing all steps, on step (checking magisk)- wait what, magisk just did that, it is patched my boot image. i dont remember if it is my rom's boot, im gonna try redownloading rom again and see
[Magisk] zgfg:
Of course, since ever. Same URL you download the Magisk from, scroll down through the page

And the link to GitHub is directly in the Magisk app - screenshot attached
[Magisk] NEOVerse!XChara:
by some reason, magisk patched that, i dont trust it and i dont have time for pc, could anyone flash this boot image with no recovery mode or vbmeta patch?
[Magisk] zgfg:
How do you think anyone will remotely flash to your phone?

Or what use would your patched boot.img have to others with different phones (or same phone but different ROMs)?
[Magisk] NEOVerse!XChara:
i mean could anyone patch this boot and send magisk_patched[_x].img to this thread, my phone and magisk as well doing +-75 percents fail
[Magisk] zgfg:
You originally said totally different. Quoting your words " I dont have time for pc, could anyone flash this boot image"

Now, you ask others to patch (not flash) instead of you or what exactly?

1) For patching you don't need PC

2) Nobody could patch your boot.img if you didn't provide that file

3) I'm not sure if patching your boot.img on eg my phone (different phone/ROM) would later work for you.

Nevertheless, you will then still need your PC to flash that patched img to your phone

Besides, not sure do you really understand the process - it's very important, otherwise there would be a small step to brick your phone

1) You had to download and install Magisk app

2) You had to find the boot.img corresponding exactly to your phone and the ROM you are running.

You are responsible to find that img (usually eg by downloading the zip file corresponding to your ROM and to extract the boot.img from that zip file) - if it's not the correct zip file / boot img file, you will brick your phone

3) From your phone, Magisk app, patch the boot.img

4) Transfer that patched img to your PC, use Fastboot from your PC and flash to your phone

Ofc, you may search on XDA or elsewhere, on the (sub) forums for your phone, if somebody else could provide you the boot.img or even patched img for your phone - but you must be 100% sure that his img is exactly for your phone and your current ROM

You see how many times I used your phone/your PC/ your ROM/your boot img
[Magisk] pndwal:
Since 26.0 you need to patch on same or specific device to set up selinux/module rules directory which Magisk needs to select per device... PW
[Magisk] pndwal:
Further, you need to ensure you use boot image from current ROM as mentioned above, but seems you may now have incompatible modules(s) causing bootloop especially if you updated ROM to higher Android version... Did you clean flash PE ROM after crDroid ROM bootlooped?

Unless clean installed (always recommended when changing ROMs), to fix you'd need to disable installed modules... Find a way to delete /data/adb contents... Could use TWRP or boot to safe mode method if you can power off properly or break bootloop cycle enough to do this... Clean install (wipe /data / factory reset) would also resolve module issues... Check Magisk FAQs...

👀 PW
[Magisk] carpz:
When I use this command in Termux it gives an error saying I/O error. Does this command work in Termux with SU? I just copied and pasted exactly what you wrote and it shows that I/O error. Is there anything I am doing wrong? Thanks
[Magisk] Nergal di Cuthah:
At a guess did you replace $(magisk --path) with the actual path to magisk
[Magisk] ipdev:
Should't have to but..

Termux is a bit different from adb shell and other terminal apps. 😉

I do not use Termux so, I can not say one way or the other.

Out of curiosity, what do you get if you run in Termux?

echo $(magisk --path)

--

This is what I get running the command on a Pixel 7 using adb shell.

panther:/ #
panther:/ # mount -o rw,remount -t auto $(magisk --path)/.magisk/mirror
'/dev/block/dm-7' is read-only
panther:/ #

Cheers. :cowboy:
[Magisk] J.Michael:
Why are you (and others) trying to remount something as "rw"? Why not use a Magisk module?
[Magisk] NEOVerse!XChara:
i had only 2 modules what have been deleted from recovery: systemless hosts - adaway; lucky patcher's one - give me more installation things. i tried to wipe ALL DATA and flash stock boot but it is still bootlooped so i decided to change rom
[Magisk] NEOVerse!XChara:
wait really? well, i should do it myself
[Magisk] NEOVerse!XChara:
i got the PC but, when i boot to the image magisk don't said additional setup requied or magisk installed, if i flash, phone can't use boot or something and don't showing OS logo just rebooted, fixed via flashing stock boot, magisk still isn't installed. does my rom even rootable?
[Magisk] carpz:
I am trying to modify the LPM file on my Galaxy Tab in /system/bin to force the device to automatically boot up when it gets power from the USB port. If I am not mistaken, if it was a Magisk module it wouldn't work since I want the code to run basically when the device is off.
[Magisk] kevinco1:
The only person who tested was the mod from Androidacy. Same problems plagued 1.0, seems ridiculous to release a major build with basic functionality broken but that's what happens when there's only one person working on their own
[Magisk] zgfg:
Pls report (confirm) to the Issue as opened, he claims that he cannot reproduce and that it affects only 0..1% of users:

[BUG] Hitting a snag when trying to install a module · Issue #2 · Androidacy/MagiskModuleManager

Just installed the new AA MMM v2.0.2, and I have again the same bug as previously reported for Fox MMM v2.0.1 (it was fixed in one of the Action builds and I successfully tested): Fox2Code/FoxMagis...

github.com
[Magisk] zgfg:
On the modern devices, System is read-only on the file-system level and you will not be able to make any hard changes

With Magisk and the modules, you can dynamically mount changes when Android boots and Magisk initializes, but that probably too later for you

Chack your /vendor/etc/fstab.* and find if /system or / are mounted as ro=read only
[Magisk] ephemunch:
As I expected in advance, problems with Magisk occurred after the OTA update of LineageOS (Pixel 6a).

Updated from a 20.0 build to lineage-20.0-20230429-nightly-bluejay

After the update it was necessary to flash the new boot image again. I have done that. But Magisk simply does not root. Magisk patched the downloaded LineageOS boot-image, saved it in the download folder and that was it.

Magisk was hidden before I did OTA update.

Simply very beautiful. All this after setting up LineageOS to my liking.

And what can I do now except re-flash ROM?
[Magisk] zgfg:
But what is the problem or unexpected

Magisk app is not Magisk itself. Before the Magisk is installed (flashed), Magisk app can ONLY patch the boot.img FILE and you have to flash it then by Fastboot or TWRP

Direct install works only for updating Magisk, when Magisk is already installed and Magisk app can flash the patched boot.img to Boot - since it requires root

Also, OTA usually overwrites the Boot partition, hence you loose your previously patched Magisk and you have to patch and flash the patched boot.img again

Hence flash your newly patched boot.img
[Magisk] ephemunch:
Was my stupidity and my mistake. I completely forgot to flash via fastboot.
[Magisk] J.Michael:
Did you unhide Magisk before the OTA update?
[Magisk] J.Michael:
Have you seen other posts about this crusade? There is at least one thread devoted to people beating their heads against this particular wall.

I don't remember whether anyone tried making a Magisk module. It is so easy, I do not understand why noone would try. The patch I have read about is replacing the lpm file with a script, so it expects that in the so-called powered-off state, there is enough of a system running for there to be a shell -- maybe Magisk is also active.

Failing that, since you have no respect for the sanctity of the system partition, you could try crafting a new system partition: unpack the system.img, replace the lpm file, repack, flash. I have no idea what tamper-resistant safeguards you will trigger.

[EDIT] @ebod reported success after following directions in a thread dedicated to this "problem".
[Magisk] carpz:
Thanks, I followed the steps and that worked perfectly.
[Magisk] ipdev:
You might be interested in this.

If you are using the current Magisk canary build, addon.d support was fixed.

A few weeks ago, I tested it on my Pixel 3a and made a post in The Age of Zygisk thread.

Post #3,128

Since I did not install Magisk via recovery, I made a module that overlays Magisk's addon.d script into the system/addon.d directory.

The module is not necessary after the first OTA.

- The OTA updater will actually restore the Magisk script into system with the others.

Magisk Survival Module - [GitHub] - Link

Please read all of the readme if you decide to use it.

- This only works with addon.d-v2 (A/B slot devices).

Cheers. :cowboy:

PS.

I have updated my 3a using the OTA updater 4/5 times now and Magisk is retained each time.

No need to manually patch and flash the new boot image after update.
[Magisk] m0han:
Shamiko update (v0.7.1) available

https://xdaforums.com/t/discussion-magisk-the-age-of-zygisk.4393877/post-88498031
[Magisk] ctcx:
@badabing2003 :

So finally I think I could "assemble" a wrapper non-root script for patching with Magisk, of course based on PF:

#!/system/bin/sh

## Initial flags ##
ARCH=$(getprop ro.product.cpu.abi)
ZYGOTE=$(getprop ro.zygote)
MAGISK_APK=$(pm path com.topjohnwu.magisk) # If hidden, replace with package name

## Setting up environment ##
cp "${MAGISK_APK#package:}" /data/local/tmp/pf.zip
cd /data/local/tmp
echo "Setting up environment..."
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
if [ $ZYGOTE = zygote64_32 ]; then
cp ../lib/armeabi-v7a/libmagisk32.so magisk32
fi
chmod 755 *
echo

. ./util_functions.sh

## Flags for patching ##

RECOVERYMODE=false
[ "$(getprop ro.build.ab_update)" = "true" ] && SLOT=$(getprop ro.boot.slot_suffix)
[ -n "$SLOT" ] && ISAB=true || ISAB=false
if ! $ISAB; then
grep ' / ' /proc/mounts | grep -q '/dev/root' && RECOVERYMODE=true
fi
$RECOVERYMODE && echo "Ramdisk value = no" || echo "Ramdisk value = yes"
echo

[ -n "$1" ] || { echo "No image to patch specified; exiting."; exit 1; }

if $RECOVERYMODE; then
[ "$(basename $1)" = "recovery.img" ] || { echo "Invalid boot image for this device, expected 'recovery.img'; exiting."; exit 1; }
else
[ "$(basename $1)" = "boot.img" ] || [ "$(basename $1)" = "init_boot.img" ] || \
{ echo "Invalid boot image for this device, expected 'boot.img' or 'init_boot.img'; exiting."; exit 1; }
fi

SYSTEM_ROOT=false
[ -f /system/init -o -L /system/init ] || grep ' / ' /proc/mounts | grep -qv 'rootfs' || \
grep -q ' /system_root ' /proc/mounts && SYSTEM_ROOT=true

get_flags
echo

echo "Flag values:"
echo "KEEPVERITY=$KEEPVERITY"
echo "KEEPFORCEENCRYPT=$KEEPFORCEENCRYPT"
echo "PATCHVBMETAFLAG=$PATCHVBMETAFLAG"
echo "RECOVERYMODE=$RECOVERYMODE"
echo "SYSTEM_ROOT=$SYSTEM_ROOT"
echo

export KEEPVERITY
export KEEPFORCEENCRYPT
export PATCHVBMETAFLAG
export RECOVERYMODE
export SYSTEM_ROOT

## Patching boot image ##
./magiskboot cleanup
./boot_patch.sh "$1"
SHA1=$(./magiskboot sha1 "$1" 2> /dev/null)
cp -f new-boot.img /sdcard/Download/magisk_patched_$SHA1.img
echo

cd /data/local/tmp
rm -r *

Tested the script in device here, and compared both patched images: one made with app UI and the other with script.

So first extracted the imgs with "magiskboot unpack", in different directories, then on each one did

cat ramdisk.cpio | cpio -idm

(had to do this as root, because the .backup directory and all its contents have permissions zero?)

Then, with "diff -r", I saw the ONLY change in whole image was certainly the RANDOMSEED strings in file .backup/.magisk.

So I guess this meant "success".

Regarding the zygote value, I saw you do more than one test in PF, but it seemed to me that, for arm64 devices, it could be just enough with testing whether zygote64_32 or not? The other possible values as far as I could see with other devices were just zygote64 and zygote32...

I know you may already have some of this stuff in PF, but still what would you think? Could some of this still be useful?

Thanks again.
[Magisk] mightyvenom:
Hi, so a bug that has been present on all my Pixel devices (5 and 7 pro) using latest QPR3 Beta 3.1 and Stable keeps showing up. Each time I try to check/install the play system update the system will restart 1-2 times in a row.

This also occurs when trying to query play integrity API (for example using YASNAC app check).

The issue is present with zygisk on and off, enforce list on and off - it doesn't matter.

I have attached the bug report. Can someone please have a look?

PS: I tried reporting the bug on the official magisk github page but since I am a noob I can't seem to manage to upload the logs there - hence why my bug report gets automatically closed

Thanks!
[Magisk] jons99:
it's a known issue you need to unroot your phone before you update play system after update you can root again (reboot 2 times before rooting) a workaround is to install main components from apkmirror

I don't think magisk log is helpful in this case
[Magisk] pndwal:
Aside from it being a known issue, your bug report is getting closed because you didn't follow template and put Magisk version code: 26101 in the body of first post, not because of lacking bug report... They may close it manually if that's missing... Be sure to replicate issue after installing Debug build for verbose logs if reporting or they may laugh at you. 🤪 PW
[Magisk] mightyvenom:
Thanks for letting me know, it was driving me crazy and I thought I was the only one having this bug 😂

Can you please explain the steps with the apkmirror workaround? Do I install the apk while being rooted and then check again for play system updates or?