yashsingh1/xdaforums huggingface dataset:
[Magisk] J.Michael:
I think you are confused. (I know I am.)

You said you flashed the stock ROM. Then you said you patched and flashed, which implies that the device was running after flashing the stock ROM. So you never mentioned trying to recover from the bootloop by flashing the entire stock ROM. I believe it would have worked, you just didn't do it.

The thing that needed to be fixed was the bootloop after patching and flashing. I listed the first few things that came to mind that would explain why you got a bootloop. Those are the things that you need to be careful of the next time you try to install Magisk.

If you have never had Magisk installed, you can ignore everything that refers to a previous installation of Magisk. Your bootloop was probably a matter of patching and flashing the boot from a different version of the ROM. Or maybe it was patching the boot image when you need to patch the recovery image.

When installing Magisk on a Samsung device, you should "patch" the entire AP.tar file. Magisk will patch three images within the tar file (assuming either the Recovery option is selected by default, or you specifically select it). Then you hand the patched AP.tar to Odin and everything in it gets "flashed". After you've gotten it working, if you're a glutton for punishment you can see if you can patch and flash less than the full AP.tar, but I think you still have to give a tar file to Odin.
[Magisk] pndwal:
My take: Neither worked...

Flashing stock caused boot to Odin (download) mode with 'red errors' (because something in /data is set to accept patched vbmeta or other)... John W indicates factory reset may be needed to fix this but it ain't always so...

Next, member patched AP (presumably on another device?), then flashed (with other binaries?) which failed... This was likely because selinux/module rule directory will be wrong in modern Magisk unless patching is done on the same device (with system booted)... It probably would have worked if pre 26.0 Magisk had been used for patching however, then simply Direct install taken to update to latest Magisk, but most users won't know this.

Finally, extracting and flashing boot.img independently of AP worked as vbmeta (and/or other?) partition is presumably still patched (and needed) for (some?) Samsung devices (it's not for most other devices since major 2SI init refactoring in 25.0 however) and the previous failed patch/flash attempt (w/ Magisk patched AP) presumably achieved that...

Ie. My best guess is that 1) stock /boot couldn't work with stock /vbmeta without full /data wipe, 2) 26.0+ /boot patched on a different device couldn't work with patched/vbmeta, but the combination of stock /boot and Magisk patched /vbmeta worked as stock /boot uses correct factory set selinux rules directory...

Good luck or good management, this seems to have saved the day. 😜

Well, member did that first, no?...

Don't think so... Said "patched the stock ROM"... I think only patching of current AP / flashing via Odin was attempted(?)

Initial bootloop (or rather, boot failure/soft brick) was clearly caused by "try(ing) to restore either boot... (without) a full Odin restore with data wipe"...

/recovery won't/can't/shouldn't be patched on that device as it launched with Android 10 so is 2SI and definitely has ramdisk in /boot (so Recovery mode option wouldn't even show)... However, maybe when patched on another device (as I presumed), if that happened to be an A-only device launched with Android 9 and Recovery mode was selected when patching, recovery.img in AP may have been patched erroneously and that would likely cause issues...

Please say which 3... I believe only 2, if not 1(?)...

Not doing this is apparently what allowed stock boot image to work on Sammy previously hosting Magisk w/o wiping /data however. (Ie. to get patched /vbmeta + stock /boot and /recovery).

... But yes, I believe patching AP on another device using pre-26.0 Magisk (or any Magisk if it could have been done on the A12 itself) and flashing all binaries via Odin would probably have worked too.

🤠 PW
[Magisk] J.Michael:
@pndwal There isn't much point in you and me arguing about what @dronkit really did, in what order. If he posts a new description with the statements in chronological order, making an effort to make it clear what device is involved in each step, I'll read it.

Magisk 20.3 patched boot, recovery, and vbmeta in the AP.tar. (I think the "patching" of boot was just zeroing out a signature.) I remember the installation instructions saying if you don't want to flash the entire AP.tar, make a smaller tar with at least those three files. I cannot find that in the current install.md.
[Magisk] dronkit:
@J.Michael @pndwal Thnaks for your responses. Didn't imagine this issue would be interesting.

The story is, I bought this phone (a127m, mediatek processor) used, so I don't care about wiping it. I meant to wipe it. I found out it had magisk installed and it was rooted indeed. I did a factory reset from Android's configuration menu, reinstalled the magisk app and then installed Jumobile's root uninstaller to debloat the phone a bit. In doing that I screwed something up and it wouldn't connect to wifi. Strangely, neither the app or me weren't able to find the backups the app supposedly does.

So I figured I'd download the latest stock rom, and flashed the whole thing (BL, AP, CP, CSC) via odin. There I got the phone going straight to download mode with errors in red about vbmeta.

Realizing my mistake, I patched the whole AP file on my A32 phone (magisk 27.0), and flashed the whole ROM (BL, patched AP, CP, CSC), but got a bootloop. I found it curious that the patched AP file is 1 gig smaller than the original, and found that magisk apparently patches boot.img and vbmeta.img and copies the rest but leaves out userdata.img. Also, IDK if it's an issue but the original files are in lz4 format, and the patched ones are uncompressed.

A friend at a telegram group gave me the suggestion to flash the stock boot.img and recovery.img, which got the phone working (unrooted).

Since then I've been reading forums about how to install TWRP and magisk root it again. It seems there is no TWRP for it since any a127xx twrp I flash, when rebooting pressing the vol up or power+vol up keys does a reboot once, and then boots to system and reinstalls the stock recovery.

As for the rebooting, I tried flashing the boot.img patched by magisk 27.0 as per a thread on the a12 forum. But I get a bootloop. Flashing the original boot.img makes it bootable again.

That's all i've done until now. I'm going to keep trying to root it. I'll flash the whole AP again in the A12 to see what happens and keep you updated.

@pndwal , you mentioned a "full odin restore with data wipe", how do I do that? Does that mean simply flashing all four stock files or do you mean something else? Thanks!
[Magisk] dronkit:
UPDATE: flashed the whole AP file in the A12 with magisk 27.0, flashed BL, AP, CP and CSC, got a bootloop again.

UPDATE2: again, flashing the stock boot.img alone, revives it.
[Magisk] J.Michael:
If you flash the stock ROM you downloaded -- no Magisk, nothing patched -- just the stock ROM, does your device work?
[Magisk] dronkit:
Yeah, just tried it. Flashed the whole rom (BL, AP, CP, CSC) and worked at the first try.

Should I try again with the patched AP+everything else?
[Magisk] dknight178:
Hi all, is there a place which has older versions of magisk canary (eg 26404 and later)? Thanks
[Magisk] bdr127:
The official topjohnwu github: https://github.com/topjohnwu/Magisk/releases

Canary versions just become future stable releases, so just pick an old release there.
[Magisk] dknight178:
Thanks. In this case I need 26404 canary so that shamiko would work - any reputable source for this?
[Magisk] J.Michael:
You probably don't need "canary" for Shamiko to work. If you just don't see anything old enough on github, try the Internet Archive.
[Magisk] J.Michael:
Yes, subject to every other caution you've been given.

Make sure the bootloader is unlocked. (I know you said it came with Magisk, but I've heard of people relocking the bootloader, and it's easier for you to check the toggle in Developer Options than it is for me to research under what circumstances the bootloader can be relocked.)

Try to pick a version of Magisk that hasn't had problems reported.

Pay attention during "select and patch a file" to whether it offers a "Recovery" option, and to whether the option is selected.

Try to follow the instructions for Samsung in John Wu's Installation Instructions.
[Magisk] dknight178:
Thanks. I actually just downloaded stable as canary 27002 cannot hide the app
[Magisk] Lughnasadh:
Known issue (which has been fixed and merged and should be in the next Canary release) with Magisk Canary 27002. Try using Canary 27001 or Stable 27.0.

Not sure what you mean by you "...downloaded stable as canary...".

EDIT: Disregard, misinterpreted your statement.
[Magisk] Nergal di Cuthah:
They meant downloaded stable, because canary doesn't hide.
[Magisk] Lughnasadh:
Ah...Nevermind... 🙃
[Magisk] dronkit:
@J.Michael UPDATE: flashing the whole stock rom (BL, CP, CSC) plus the AP patched by Magisk 25.2 worked on the Galaxy a12 a127m (mediatek processor)

UPDATE: installing the latest (27.0) magisk apk and following instructions, which updates and reinstalls magisk by the direct method works fine!
[Magisk] badabing2003:
Magisk General Support / Discussion

This is the place for general support and discussion regarding "Public Releases", which includes both stable and beta releases. All information, including troubleshoot guides and notes, are in the Announcement Thread

xdaforums.com
[Magisk] pndwal:
27001 will be synced with 27.0 (in case you want to stay with Canary channel). All 001 builds are effectively the same as public Beta or Stable just released... 🤠 PW
[Magisk] dknight178:
Thanks. To clarify - are you saying 27001 canary = 27000 stable?
[Magisk] pndwal:
Yeah... See edit to post above... I wasn't quick enough... 😉 PW
[Magisk] J.Michael:
@pndwal I was reading Installation Instructions. Are there things in there that are not "official"?
[Magisk] dknight178:
Thank you
[Magisk] n.p.:
The installation instructions on one device (a 905X3 TV box running Android 9) do not work for me.

In particular, the page says:

"If your device does NOT have boot ramdisk, get a copy of the recovery.img."

The options section when I press Install shows a (selected) checkbox labeled Recovery Mode, but attempting to patch recovery.img produces this error:

- Device platform: armeabi-v7a
- Installing: 27.0 (27000)
- Copying image to cache
- Unpacking boot image
Parsing boot image: [/data/user_de/0/com.topjohnwu.magisk/install/boot.img]
HEADER_VER [1]
KERNEL_SZ [9861416]
RAMDISK_SZ [6817522]
SECOND_SZ [80906]
RECOV_DTBO_SZ [438]
OS_VERSION [9.0.0]
OS_PATCH_LEVEL [2018-08]
PAGESIZE [2048]
NAME []
CMDLINE [androidboot.dtbo_idx=0 --cmdline root=/dev/mmcblk0p18 buildvariant=user]
CHECKSUM [8b8bb8af23ba5b997e675d0ef0f4bbb5bddb75f1000000000000000000000000]
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
! Boot image patched by unsupported programs
! Please restore back to stock boot image
! Installation failed
[Magisk] n.p.:
I wanted to provide an update to this issue (hey, six months have passed :) ). The phone no longer bootloops when attemping to install Magisk - instead, it just does nothing. Magisk appears to install correctly, but upon rebooting the phone and opening Magisk, it still shows version 25.2 (25200) for Magisk. Of course, I have version 27.0 (27000) for the App. The Magisk log:

- Target image: /dev/block/mmcblk0p20
- Device platform: arm64-v8a
- Installing: 27.0 (27000)
- Unpacking boot image
Parsing boot image: [/dev/block/mmcblk0p20]
HEADER_VER [0]
KERNEL_SZ [7150894]
RAMDISK_SZ [1854399]
SECOND_SZ [0]
EXTRA_SZ [0]
PAGESIZE [2048]
NAME [1478934223]
CMDLINE [bootopt=64S3,32N2,64N2 enforcing=0 androidboot.selinux=permissive]
CHECKSUM [25e585033120742c21c0ec5346ca80dfde2f4871000000000000000000000000]
KERNEL_DTB_SZ [81343]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
incorrect length for PRIVATE [10] (primitive)
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
- Magisk patched boot image detected
Loading cpio: [ramdisk.cpio]
Extracting entry [.backup/.magisk] to [config.orig]
Restore [.backup/init] -> [init]
Removed entry [.backup]
Removed entry [overlay.d]
Removed entry [overlay.d/sbin]
Removed entry [overlay.d/sbin/magisk32.xz]
Removed entry [overlay.d/sbin/magisk64.xz]
Dumping cpio: [ramdisk.cpio]
- Patching ramdisk
Loading cpio: [ramdisk.cpio]
- Pre-init storage partition: userdata
Add file [init] (100750)
Create directory [overlay.d] (0750)
Create directory [overlay.d/sbin] (0750)
Add file [overlay.d/sbin/magisk32.xz] (100644)
Add file [overlay.d/sbin/magisk64.xz] (100644)
Add file [overlay.d/sbin/stub.xz] (100644)
Patch with flag KEEPVERITY=[false] KEEPFORCEENCRYPT=[false]
Found fstab file [fstab.mt6755]
Loading cpio: [ramdisk.cpio.orig]
Backup [init] -> [.backup/init.xz]
Record new entry: [overlay.d] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk32.xz] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/magisk64.xz] -> [.backup/.rmlist]
Record new entry: [overlay.d/sbin/stub.xz] -> [.backup/.rmlist]
Create directory [.backup] (0000)
Add file [.backup/.magisk] (100000)
Dumping cpio: [ramdisk.cpio]
Loading dtbs from [kernel_dtb]
Loading dtbs from [kernel_dtb]
- Repacking boot image
Parsing boot image: [/dev/block/mmcblk0p20]
HEADER_VER [0]
KERNEL_SZ [7150894]
RAMDISK_SZ [1854399]
SECOND_SZ [0]
EXTRA_SZ [0]
PAGESIZE [2048]
NAME [1478934223]
CMDLINE [bootopt=64S3,32N2,64N2 enforcing=0 androidboot.selinux=permissive]
CHECKSUM [25e585033120742c21c0ec5346ca80dfde2f4871000000000000000000000000]
KERNEL_DTB_SZ [81343]
KERNEL_FMT [gzip]
RAMDISK_FMT [gzip]
incorrect length for PRIVATE [10] (primitive)
Repack to boot image: [new-boot.img]
HEADER_VER [0]
KERNEL_SZ [7150894]
RAMDISK_SZ [1826598]
SECOND_SZ [0]
EXTRA_SZ [0]
PAGESIZE [2048]
NAME [1478934223]
CMDLINE [bootopt=64S3,32N2,64N2 enforcing=0 androidboot.selinux=permissive]
CHECKSUM [269edd0e67d4cf7a785fd30cefe0e33d9da47b8e000000000000000000000000]
- Flashing new boot image
- All done!

Any ideas on tracking down the cause of this?
[Magisk] zgfg:
That is a known issue (mentioned MANY times in this thread), applicable for a large number of devices from around the time of A9 - where Magisk app WRONGLY displays Ramdisk No (for Magisk app it actually means something else), hence Instructions wrongly direect you to patch Recovery (as if you don't have Boot partition), alrhough in fact you do have Boot (IMO, as a user, you should know your device), hence you have to disable the option to patch Recovery, and you should just normally patch Boot - when you do, Magisk will find Ramdisk in Boot and will patch the Boot just fine
[Magisk] pndwal:
I know similar has happened to others... May even be fixed, or this pending issue:

Magisk doesn't install after flashing patched boot.img confirmed regression

#7390 opened on Sep 27, 2023 by Cronick

... or may be another issue pending a fix...

So suggest you try latest Canary to check if late fixes help... Also, have you tried patching stock boot.img w/ latest Magisk?... Refactoring can make that necessary when coming from older versions... 👀 PW
[Magisk] pndwal:
If your box/SOC is A-only and originally launched with Android 9, the Recovery Mode option appearance will be correct... An issue with it appearing in error occurred with a few Magisk versions and is properly fixed if you are using latest builds AFAIK... You could try patching /boot as suggested in case there is bootloader support for ramdisk in /boot... Generally that won't "find" ramdisk there as OEM didn't supply it, but Magisk patching will actually install basic ramdisk cpio when it's missing in case it can work (as it can on A9 LV Xiaomi devices)...

However, I think you'll find it doesn't work... Seems your issue is actually that you have a pre-rooted ROM...

Many of the Amlogic and other boxes are re-sold, and some come with stock installations while others are supplied rooted by merchants, presumably to enable special functions and menus. (Interestingly, the issue I cited in my post above to you relates to a similar TV box, but I believe it's older and bootloader allows patching /boot.)

Error: "Boot image patched by other program" usually means that boot image (and note here that /recovery is a boot image too) is already patched with something like SuperSU... Since seller seems to have installed root in /recovery this way it seems that Recovery mode root is correct, but a foreign SU solution would generally need to be removed prior to installing Magisk which may not be easy, or you'd need to research and find proper stock (unrooted) or original ROM...

Once Magisk is installed, you'd also need to discover how to boot to system via recovery to have rooted Android as standard booting with still land you in unrooted Android... Generally this is done using adjusted recovery key combo per Magisk Installation instruction, Magisk in Recovery section, but there may be special considerations or menu options available for TV boxes like yours...

Found this XDA info but maybe not much help there... May give clues about stock firmware etc... :

https://xdaforums.com/t/tanix-tx3-firmware-s905x3-mali-g31.4016613/

All best, 🤠 PW
[Magisk] pndwal:
I just assumed you'd read something unofficial as I don't recall seeing it mentioned that 3 separate images are ever patched, but maybe that used to be the case?... The .md has changed alot... It used to accommodate Huawei and other special case configuration with images like ramdisk.img needing patching, but I thought only a boot image and a vbmeta image were only ever needed... PW
[Magisk] n.p.:
I hadn't thought of trying that... and it worked! Thank you. On to the other device.

I think @pndwal has described the situation more accurately.I know that I do have boot @zgfg, but the installation instructions seemed to indicate that the boot partition lacks a ramdisk, therefore I have to patch and flash recovery.

The partition list does suggest an A-only device. I should have mentioned that I have installed slimBOXtv. I guess that counts as pre-rooted. The second settings menu (slimBOXtv settings) has a menu entry called ROOT (selecting in has an Install root option, with Device not rooted directly underneath it).

Yes, patching the (slimBOXtv) boot.img and flashing it (with Recovery Mode unchecked) to the boot partition doesn't work (the box doesn't boot).

Do you think that (assuming I could locate the factory boot and recovery images, and that they don't include root capabilities) that patching and flashing the boot image would work, or would the slimBOXtv modifications to the ROM prevent that (meaning I would need to flash recovery in that case)?

That seems like the most trivial part of the whole operation (dd if=/dev/zero of=/dev/block/boot will force a boot from recovery every time). :)
[Magisk] pndwal:
👍 🎉

Yeah... Magisk should add missing generic ramdisk support when patching but that was added only when it was realised that Xiaomi A-only L-SAR devices inexplicably have bootloader support for ramdisk in /boot despite no OEM provided ramdisk so users could at least try /boot patching... Few other such "type III" devices have the B/L support however so /recovery must be patched.

Ah, yes... So you did it!... Custom pre-rooted firmware!!... Actually, I was aware that some resellers preinstall custom SlimBox too...

Please understand that magiskinit must always be injected in a boot image ramdisk... I've explained why boot.img CANNOT support this on your type III device; when bootloader only supports ramdisk in /recovery, that must be patched as there's no better option... Nb. recovery.img is also a boot image in the technical sense.

Maybe I'm not understanding the ROOT menu options you described, but seems it should possible to install SlimBox without root no?... Or you can unroot?... Or find a SlimBox unrooted build?... Or one built with/for Magisk?... In these circumstances you should be able to patch recovery.img with Magisk successfully...

Yeah, but is that not to re-boot?... Rebooting via recovery may work on some devices to arrive at system with Magisk, but I understand that the first boot to system with Magisk must generally be from powered off state, so key combo must be used with the earlier-than-normal key release timing to arrive in system with Magisk rather than in recovery... Of course a custom SlimBox variant may have been modified specifically to boot to system via recovery from the getgo, but I can only tell you how Magisk is designed to operate without specially modified ROMs...

🤠 PW
[Magisk] J.Michael:
I don't think zeroing the boot partition will make it easier to boot Magisk from recovery. Once Magisk becomes active, it then causes the normal Android system to boot. Maybe it doesn't need the boot partition, but I would think it would at least need for the kernel in recovery to be the same as the kernel in boot. Unless there's a copy of the oernel in /system.

I can't tell how far your tongue is in your cheek, so if you were just joshin', you got me!

(But if you do try it, please let us know if it works.)
[Magisk] n.p.:
Just to make sure I understand, you say that finding and patiching a factory boot.img (and flashing it to boot) will not work on this device?

For my curiosity, can you define "type III device"?

From what I understand, the ROM comes "unrooted," but with a menu option (which I clearly see) to install (and uninstall) SuperSU as needed. While slimBOXtv has frequent updates, they seem almost exclusively concentrated on user interface tweaks (and replacing the included user packages with newer versions), rather than anything related to security (or even updating system components such as Webview). Their Android 9 ROMs (that the project provides for my 905x3 device) use SuperSU for root (their Android 11 ROMs, which they offer for 905x4 systems, among others, do come with Magisk pre-installed).

So I do have a (kludged) working setup now. I patched boot.img (with Recovery Mode checked in Magisk), and then flashed the patched boot.img to the recovery partition (and zeroed out the boot partition using the method I indicated above). When I power the device on (hot or cold boot), it can't start from an empty boot partition, so it runs the patched boot image in the recovery partition, which brings up the system with Magisk working as expected.

If I keep twrp.img in the root directory of the microSD card, I can boot to that just by renaming it to recovery.img before rebooting (a recovery.img file on the microSD card takes precedence over the recovery partition). Not very elegant, but given that I don't need to screw around with pressing toothpicks into the headphone jack to select between system and recovery, the convenience most likely exceeds that of the typical setup (patiching boot.img and flashing it to the boot partition) on a device with no natural way of entering a key combination.

Not kidding at all, and it works as described above. From what I found, clearing the boot partition seems like a fairly well-known "trick," but I have no idea as to its generality. I suspect that functioning the way that it does has less to do with the ROM than with the Amlogic ecosystem (but I would not back that belief with any cash).