yashsingh1/xdaforums huggingface dataset:
[Magisk] DaOldMan:
Guys,

I am still strugling with V26. I use direct install in Magisk app. Then every app in denylist crash. It's due to a crash of Zygote table that causes some frameworks (dex files) not to be recognised. So apps crash with unknown method error. I have no idea what to do with it. All prior versions work just fine, even no problem to pass safetynet. Changing kernels and patching the new kernel to V26 causes the same fatal errors :-( .

I attach the logcat with the zygote fatals and app crashes. I would be happy that this gets solved for my rom users. I am the rom maintaner for now.

Thanks !
[Magisk] zgfg:
No use of providing logs here and asking for a fix

Developers (particularly TJW) are not in this thread - actually, not on XDA. Just users like you

You need to go to Magisk GitHub, read instructions there and submit the issue
[Magisk] DaOldMan:
Sure, no problem. Logs are abc of debugging and should be always submitted, even here.

Or you prefer "not working" as a question?
[Magisk] zgfg:
I don't prefer one or another. I just said, if you ask for a fix, better submit the way you will reach developers

I have also problems with v26.3 and I wrote here about - as of now, couple of serious issues are known (and for some of them workarounds have been proposed and discussed here!). But I don't expect it will be fixed because it was posted here - so I also didn't submit logs here bcs (practically) nobody will read them 😁
[Magisk] J.Michael:
You said "V26". Around here people say v26.1 vs. v26.3, which version were you actually using?

You say older Magisk was working for you. Which version?

(Doesn't really matter, if old version worked, and new version doesn't, stick to old version. At least until you read that a newer version fixes problems.)
[Magisk] DaOldMan:
Any v26 does this. 26.0, 26.1, 26.2, 26.3 all of them. I am using 25.2 which works just fine. Even safetynet passes. I will try alpha, maybe it will work?
[Magisk] pndwal:
Alpha ii's syncd with TJW Magisk but builds experimental commits... The key current difference is that it builds Shana's WIP (since March) native bridge loaded Zygisk from LSPosed Metagisk... If you think Zygisk loading may account for "zygote fatals and app crashes" on your device, then it seems likely that this may fix issues...

Nb. NB-Z was touted for Magisk 27.0 by LSP Devs (on TG), but it seems to be a long process getting it finalised... I find no problems in Alpha but the PR says 'conflicts still need resolving'... Not sure whether John intends to introduce this in Canary, or is waiting till stable enough for public Beta testing...

Also, there are several Magisk issues pending this PR being pushed as native bridge loading is already a known fix for them... Guess your issue might be another...

🤠 PW
[Magisk] 0ther:
latest magisk dont ask me about vbmeta

I have not "Patch vbmeta in boot image" option at all

does it only happen to me?
[Magisk] pndwal:
However, main 26+ changes include.

• New Magic Mount Implementation

Magic Mount has gone through a major rewrite. The existing implementation doesn’t work well with OEMs injecting overlays into their system using overlayfs. The new implementation fundamentally changes how filesystem mirrors are created, giving us a more accurate clone of the unmodified filesystem.

• New sepolicy.rule Implementation

Magisk allows modules to provide custom SELinux patches by including the file sepolicy.rule. Due to the complicated nature of SELinux patching, the compatibility of this functionality has been pretty spotty... In this release, a brand new pre-init partition detection mechanism has been designed to support even more devices...

• Zygisk Updates

The new Zygisk API v4 is now live! It comes with new features and a refined PLT function hook API. The implementation of Zygisk has also gone through some major refactoring, including new code loading/unloading mechanisms and a new PLT function hook implementation...

Nb. The last is not yet native bridge loading, but these changes may be causing your issue... Or another change related regression or possibly LineageOS incompatibility...

I'd also be inclined to check with all modules disabled...

Next, refresh (clean) your Magisk installation... Try 1) Deleting /data/adb/magisk directory and data/adb/magisk.db and rebooting to force rebuilding Magisk config files... If no dice, 2) Patch and flash ROM matched boot image fresh in case issue was from patching previously patched boot image...

🤠 PW
[Magisk] pndwal:
These changes:

Disable boot vbmeta patch when found vbmeta.img

topjohnwu committed 3 weeks ago

Fix device detection scripts and logic

topjohnwu committed 3 weeks ago

Do not allow user to configure boot vbmeta patching

topjohnwu committed 3 weeks ago

🤠 PW
[Magisk] DaOldMan:
I just installed alpha and patched the boot.img. After restart all apps in denylist crash and zygisk fatal crash is also in the logs. So it's not the fix for this problem. My kernel is 3.4.113 so it may have the bug with old kernels as well. I may try to use a new kernel to boot the device and see if that helps.
[Magisk] pndwal:
The issue where "Samsung added their stupid exec limitation" existed only in some devices with ≤ 3.19 kernel, so doubt it's that...

Suspected it may be due to one of the major 26.0 refactors however, hence also posted this:

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

above... PW
[Magisk] Traviscott:
Old android phone

Android 7.1.2

Arm v7 32bit

Lineage os

Magisk 26.3 (26300)

...

In the new version of magisk, when I update, I get this error (Insufficient Partition Size)...!!! This error happens whether I update magisk from app or through twrp recovery...also I uninstall the magisk Completely and restored the stock boot, and then re-flashed magisk with the new version, but the same error also occurred... !?

Note -:

the previous version 26.1 worked normally...but the problem occurs with me in the new update .
[Magisk] dope77:
Open an issue on github.

And i was checking the issues to see if it was already reported and i saw that you had 2 closed issues due to nit following correct format.

Reopen a new issue and follow the correct format
[Magisk] J.Michael:
What is the size of the stock boot image?

What is the size of the Magisk patched boot image?

What is the size of the boot partition?

Maybe you really don't have room for Magisk.
[Magisk] J.Michael:
The name of the tar file does not matter.

The names of the files in the archive do matter.

In Samsung tar files the boot image will be either "boot.img" or "boot.img.lz4". If in the process of patching "boot.img.lz4" is expanded, it doesn't need to be recompressed before putting it in the new tar file, it just doesn't get the "lz4" suffix.

You seem to have posted a log fragment from an attempt at flashing, not a log fragment from an attempt at patching. Please explain in more detail what you did and when you got this "unsupported format" message.

You were supposed to build a tar file containing "boot.img" and "vbmeta.img"; then use Magisk manager app to Select and Patch a File, giving it the tar file; then examine the magisk-patched.tar file to see which files in the tar file got patched.

If you don't have a Samsung, and are not using Odin, you don't flash a tar file. You extract the patched files from the patched tar file and then flash them the way you usually flash an image file.
[Magisk] portsample:
This is not a Samsung phone, so am not using Odin. It is a Sonim XP8. I made a tar file using stock boot.img and vbmeta.img. That tar file was named recovery.tar. This was moved to the device download directory, opened Magisk and tried to patch this tar file. Yes, the plan was to have Magisk open the tar and patch vbmeta and boot and produce a patched_recovery.tar, from this I would extract the patched image files and flash on the device using Qualcomm EDL tool. Below are the error messages produced by Magisk after trying to patch the recovery.tar,

-Installing 26.3 (26300)

-Copying image to catch

-unpacking boot image

-Unsupported/unknown image format

-installation failed

Thanks in advance.
[Magisk] J.Michael:
Is Magisk able to patch the boot image if that is the file you Select and Patch?

Check the PixelFlasher thread. @badabing2003 might have found the command line switch to patch a vbmeta file.

Maybe repeat why you want to patch vbmeta. Someone may have a better idea of how to do it, or whether you really need to do it.
[Magisk] portsample:
Don't know that it needs to be done. These phones rooted fine w/Magisk on Android 8.1. Magisk documentation says that if a vbmeta image is present,

"...you can patch the vbmeta partition with command:

fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img"

so I assumed this needed to be done.
[Magisk] Saggittarius79:
Hi, I have a new Allnet Android tablet running Android Version 11 AOSP. The tablet is rooted by default.

Some of the apps I want to use won't run because they complain about Android being rooted.

So I've started to look into Magisk (to hide the root from these apps). I've installed Magisk version 26.3 getting

Installed: N/A

Zgisk: No

Ramdisk: Yes

Then I've tried to install Magisk.

I'm using the option "Direct Install(recommended) but then getting an error (?) saying "Unable to find preinit dir". See below.

Any ideas how this could be resolved?

Many thanks
[Magisk] Nergal di Cuthah:
To start with you're trying to root a rooted system. I don't think it works that way. What method was the tablet rooted with originally?
[Magisk] Saggittarius79:
Good question..how can I check this? The tablet is rooted by default/by the vendor and sold like this.
[Magisk] J.Michael:
"rooted by default" is probably a problem.

Check with the distributor of the ROM, find out if the "root" is by way of Magisk, and whether you can upgrade the Magisk.

If the tablet came with Magisk installed, then it probably also came with a Magisk manager app. Find it. Use it.

You really need to understand what you have before you try to change it. Since it's too late for that, you need to try to figure out what you have done before you do anything else.

Do you still have "root"?

Do you have a terminal emulator app?

From a terminal emulator command line, what happens when you type "magisk --help"?

How did you get the original boot image you tried to patch with Magisk manager app?
[Magisk] Nergal di Cuthah:
From what i read they didn't, only installed magisk app and trying direct install to live boot (already rooted by unknown entity)
[Magisk] portsample:
Does it fine on 8.1 and root is obtained. Magisk appears to do it on 10.0 (no Magisk error messages), but root is not obtained. Thanks.
[Magisk] Saggittarius79:
yes, that's correct. I haven't provided the original boot image as I used the direct install. The vendor must have used something else (not magisk). There was no Magisk app on the Tablet installed.

I still have 'root' access.
[Magisk] Nergal di Cuthah:
Ok i think (maybe not) i may be barking up the wrong tree. Looked again at your photograph, i see that magisk finds a magisked boot, but fails on the lack of preinit folder. Someone smarter than me needs to help here

Edit: new path. Do you have a preinstalled root mangement app already (maybe it's a hiden magisk manager issue)
[Magisk] pndwal:
mmm...

Maybe a Magisk App is hidden, or another root management app is interfering... Can you see provided root GUI or research how to configure root on this device and provide screenshots?

Other than that, Direct install should find preinit dir used previously, but this was refactored in 26.0 (for greater selinux/module compatibility) so may be incompatible now...

Pre-root may still be an issue depending on implementation... sometimes it is, sometimes it isn't...

You could try:

• Install older 25.2 App and try Direct Install again... If that works, may next be able to update Magisk to current version...

Nb. If version (downgrade prevention) or signature checks cause App to be uninstalled on opening (running daemon does this), force install Magisk (core/mask) first by renaming .apk file to .zip and flash as a module from Modules, Install from storage... Next, install same version .apk...

• With latest 26.3 App installed, use boot image from ROM and take Select and patch file, then flash that (using fastboot or TWRP etc)... Despite being pre-patched, a new preinit directory should be selected in this patching process (Direct install may assume there should be an established preinit folder)...

• Check for unrooted firmware... Magiskroot should then just work...

Bypassing preinstalled root to update is fraught... Hope something works...

🤠 PW
[Magisk] J.Michael:
I'm going back to the beginning. I think you should, too.

What do you mean "It is locked"? What is locked?

Have you read the PixelFlasher thread to see if there is any mention of vbmeta?
[Magisk] J.Michael:
At any point when trying to use the Magisk manager app that you installed, did you get a prompt to grant privilege to the manager app?

Like @pndwal asked, do you have any app to oversee the permission granting that has gone on?

Can you contact the vendor? Did you buy this thing from a truck on the side of the road? Is the device mentioned anywhere else on XDA?
[Magisk] Nergal di Cuthah:
Sorry laughing at side of road comment, not your post in general
[Magisk] portsample:
Bootloader is locked. One of the listed prerequisites of Pixelflasher is that the bootloader be unlocked. This is why we are using the Qualcomm EDL method of modifying images on the device.
[Magisk] pndwal:
Yeah... in Australia you should be sure to meet Gumtree electronics vendor in the middle of a busy shopping mall!... In Asian countries this is even more imperative... 😆 PW
[Magisk] J.Michael:
Two things:

Why haven't you unlocked your bootloader?

I was not pushing you to use PixelFlasher. I was pushing you to read the PixelFlasher thread to see if @badabing2003 had discovered command line switches dealing with vbmeta. If Magisk needs to be cajoled into patching a vbmeta, the way to do it might be to use a command line switch. PixelFlasher issues commands, I thought the PixelFlasher thread might be the place for you to learn what the switch it.

Of course, it might be that "magisk --help" will tell you. Have you tried that?
[Magisk] pndwal:
Actually I missed B/L locked... Late to the party...

I think there may be more to it than stripping vbmeta flags needed here... That works for unlocked devices in many cases, but in these circumstances (in the context of AVB), the LOCKED state means that verification errors are fatal whereas in UNLOCKED state they are not...

AVB arrived with 8.0 and it's verification checks have been enhanced going forward... I doubt you can generally have root + locked B/L without custom signed images (custom keys, ie AVB yellow state) these days...

😬 PW
[Magisk] YU YUREKA:
Anyone help to solve this Miui14 Eu Android 13
[Magisk] badabing2003:
To dirty flash with PixelFlasher, you would need an unlocked bootloader.

To sideload stock OTA, you don't need unlocked bootloader.

More importantly for you, to create a patch, you don't need an unlocked bootloader.

I took a look at the vbmeta you posted in an earlier post, it's all blank (actually zeros) so I don't understand how that is causing the issue.

Obviously you can't do this because your bootloader is locked.

I haven't looked into the internal details of what exactly Magisk does for vbmeta patching, but the flag in question is PATCHVBMETAFLAG

I wonder when you create a patch with PF, what does it report the value of this flag (yes PF will output all the flag values)

I tried this tool to create a patch from your vbmeta.img

It failed

Error: The provided image is not a valid vbmeta image.

Then I tried on a good vbmeta.img

and it succeeded, it set a flag (AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED) at 0x7B

I did not test the patched vbmeta because I don't have the need for it nor I want to wipe my phone.

According to this reddit post, an empty vbmeta is an equivalent of a patched vbmeta.
[Magisk] portsample:
Okay, so if vbmeta.img is not the problem, what else? Thanks.
[Magisk] badabing2003:
I'm not sure if vbmeta.img is the issue or not.

I don't know how accurate that reddit post is.

Perhaps you can patch 0x7B to hex 03 to disable both verity and verification and try.

Do you happen to have the full firmware download, or you can only extract it from the phone?

What Magisk version did you use to create the patch?

Were there any options to select?

DO you happen to have the full output log from Magisk?
[Magisk] portsample:
Where is the "full output log from Magisk" located, or how do I create one?
[Magisk] badabing2003:
there is a save button (disk icon) after you create a patch,
[Magisk] bobfrantic:
I'm running into a bit of trouble installing magisk 26.3 into a rom for my s9+ where it gives the error "Unable to find preinit dir" and after the reboot I get the message that magisk needs to be reinstalled again, and when doing so by direct install I get same error and it repeats the process over and over like the magisk isn't getting installed due to that error. Anyone have this happen before and how did it get fixed?
[Magisk] portsample:
Thanks. Just to confirm...

I have created a patched boot.img when I copy that file from the device and use Magisk. Have not managed to get output when using a recovery.tar which is boot.img + vbmeta.img compressed to an archive. I can grab and post the log from the first case (patching just the boot.img) if that would help. As indicated previously, this method worked (produced root) with Android 8.1, but no root with 10.0 even though a patched boot.img was produced. Thanks.
[Magisk] badabing2003:
I don't know about patching a tar of boot+vbmeta, but the output of patching just boot is useful

What Magisk version are you using?
[Magisk] portsample:
26.3

I will get the log file (and output) from the patched_boot.img build tonight and post it. Thanks for your time and suggestions.
[Magisk] badabing2003:
I see that you have dumped stock_vbmeta_a.img

Have you also dumped stock_vbmeta_b.img

do they match?
[Magisk] portsample:
They should. However, I have Image files of the entire Android 10.0 installation from these devices. I will upload a vbmeta.img and boot.img from there to be certain. Thanks.
[Magisk] badabing2003:
From the phone manufacturer or you dumped each partition yourself?

if it is from phone manufactured share that or a link to it.
[Magisk] pndwal:
👍

So do you think with Android 10 & locked B/L AVB still won't produce 'fatal' verification errors for modified /boot (+ other?) partition and allow OS to boot just because EDL might allow flashing?

I said above:

😬 PW
[Magisk] badabing2003:
I don't know, and I don't want to take chances with someone else's phone and get it bricked.

I just don't like vbmeta.img that is all filled with zeros.

Even avbtool does not find it a good image.

Given image does not look like a vbmeta image
[Magisk] pndwal:
Point is, why touch it at all?!... I'm certainly not advocating stripping it any more than simply patching it.

I really think the whole modifying vbmeta (stripping flags etc or simply emptying it) idea for allowing a modified image while B/L is locked is a red herring, no?

That can only work if bootloader allows unverified OS/images to boot/load in any case, eg for you pixel users with B/L unlocked...

I think the reason @portsample could boot such OS/images only until Android 8.1 is that AVB was only verifying/disallowing images for normal flashing... Now we have checks that give 'fatal' errors irrespective of vbmeta, otherwise we could re-lock bootloader with root without signing with custom keys, no?

I just don't think we can expect modern Android/AVB to allow verification bypasses with locked, 'verified' green boot state simply because a user has found a way to flash via an EDL mode and modded vbmeta... For one thing, AVB would remain a joke...

As I understand it, AVB "typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn't have any known security flaws"... The vbmeta struct holds the hash for partitions in hash descriptors, and "because this is cryptographically signed, the boot loader can check the signature and verify it was made by the owner of key0 and thereby trust the hashes used for boot, system, and vendor"...

https://android.googlesource.com/platform/external/avb/+/main/README.md

Of course AVB can be overridden by tampering (altering/stripping flags etc) vbmeta struct to prevent checks for image hashes and hashtree metadata, but this relies/would rely on the signature checks not being enforced, ie B/L unlocked/"Unverified"/orange state...

If Google's description of AVB boot time functions is correct, altering vbmeta should NOT enable OS with custom signed/tampered images to load/boot in B/L locked/"Verified"/green state as proper (non-custom) signing is enforced regardless... Tampering vbmeta may hide the keys, but the checks mean they must be available!

... As Android Verified Boot (Verified Boot 2.0) was introduced with Android 8, I'm actually surprised loading such images was still possible in 8.1 by using EDL to bypass checks, but seems that option has since been properly patched...

So I think all this vbmeta stuff is a red herring for @portsample as long as bootloader cannot be unlocked... Please say if I'm still missing something... PW
[Magisk] portsample:
Attached are the vbmeta and boot image files from a full ROM backup of a SonimXP8 running Android10.

Files were obtained by running the attached xml file using Qualcomm tools and commands:

"QSaharaServer.exe -p \\. \ COM<X> -s 13: prog_emmc_ufs_firehose_Sdm660_ddr.elf"

"fh_loader.exe --convertprogram2read --port=\\.\COM<X> --sendxml=backup.xml"

Check post #230 here for full details:

https://xdaforums.com/t/sonim-xp8-root.3851187/page-12

Thanks in advance.
[Magisk] portsample:
Attached is a boot.img file from a Sonim XP8 running Android 10 that was patched using Magisk 26.3. The resulting patched file is attached, as well as the log file from this session. I appreciate the forum's review, analysis and suggestions regarding rooting this device. Thanks.