Magisk General Support / Discussion

[zgfg]

I've thought about a similar way to get ramdisk= yes on such devices too, but it would be a little messy, and can't be the way you described, simply 'recognizing the existence of ramdisk when patching and remembering', because existence of ramdisk is not the problem (and nothing is 'remembered').

The problem is that such devices did NOT use ramdisk in boot image, so generally they use a bootloader that is no longer compatible w/ ramdisk, so even if ramdisk is ADDED SUCCESSFULLY to boot image, (and I believe this is always done if ramdisk is not present), and Magisk is successfully added to boot image also (ie patching is wholly successful), the Magisk Installation will STILL fail due to bootloader, and, as John says, Magisk has no way to see bootloader compatibility.

Xiaomi devices just happen to use ramdisk compatible bootloaders, probably because they never rewrote the code fully, which is to our advantage because John has done us (Xiaomi etc users) a favour by adding a 'manually add initramfs if not present' feature to Magisk.

So Ramdisk= no correctly means no FACTORY ramdisk in boot image. To make it mean no ramdisk without qualification WOULD involve adding a memory feature to remember a successful boot with root before changing this flag... as I said, could get a bit messy (otherwise I might have suggested this as a feature also). PW

Flashing DOES NOT fail, we patch and flash the patched boot img and have the Magisk up and running

About 'remembering', finding and declaring that there is no Ramdisk, look at my previous post and the log attached there

 

[zgfg]

Is this a fair intepretation of the point you are making?

* Before flashing a patched img: Magisk's Ramdisk detection method used at that time (call it "detection method 1") shows that there is no Ramdisk on the given device.

* After flashing a patched img: Magisk's same detection method 1 shows that there is still no Ramdisk of the type that it is looking for, but there is now another version of a Ramdisk which is present on the device which shows up as a result of a different mechanism for detecting a Ramdisk (call this "detection method 2").

* After patching, the results of detection method 2 should be presented to the user, because there now is at least some form of Ramdisk that is being used, even though it isn't detectable by detection method 1.

Did I understand your point correctly?

And what is unfair when I said earlier - not consistensy, using one method here, the other method there...

 

[HippoMan]

And what is that different than I said earlier - not consistensy, using one method here, the other method there

I see it as the same as what you said earlier. I'm just saying it in a different way to perhaps make it more understandable to those who seem to be missing your point.

 

[HippoMan]

I see it as the same as what you said earlier. I'm just saying it in a different way to perhaps make it more understandable to those who seem to be missing your point.

... and to be clear, I agree with the point you are making, and this is just an attempt to support it.
And I used the word "fair" to mean "accurate" (i.e., fair to you by my attempt to accurately represent your point).

 

[pndwal]

Screenshot: patching the stock boot.img, it says PATCHING RAMDISK

Upon flashing that patched img it still displays: Ramdisk No

But the attached log from repatching parses that the same patched img and finds the (not existing?!) ramdisk:
Parsing boot image:
...
RAMDISK_SZ [713664]
...
RAMDISK_FMT [raw]

As mentioned, making it say ramdisk = yes for manually added ramdisk would be misleading as Magisk will now always add ramdisk support to a boot image lacking it, but this will usually not help anyway.

A bootloader compatibility flag, if only it were possible, would be the true indicator of success BOOTING a boot image with Magisk and ramdisk. Successful patching of Magisk to boot image is simply not enough. (Users of type III devices without compatible bootloaders will see ramdisk exists in logs after Magisk adds initramfs too, but it won't be usable. Ours is, but there is apparently no way to tell other than to try...) PW

 

[zgfg]

A bootloader compatibility flag, if only it were possible, would be the true indicator of success BOOTING a boot image with Magisk and ramdisk.

even if ramdisk is ADDED SUCCESSFULLY to boot image, (and I believe this is always done if ramdisk is not present), and Magisk is successfully added to boot image also (ie patching is wholly successful), the Magisk Installation will STILL fail due to bootloader, as John says...

Ok so maybe there is another bug then - Magisk app just incorrectly declares that Magisk is installed

And maybe I was wrong all the time thinking that I'm using Magisk, while I could not be, because the way it was installed must fail

Then sorry for spamming in this thread, if not running Magisk my opinions are not relevant

 

[Zoki88]

Did you read the Magisk Wiki (find it from Magisk Github, link to Github is right on the Magisk app main window), and did you try the suggestions there

If you don't pass SafetyNet you maybe need to install SafetyNet fix.
Apps you want to hide from must be enabled for under the the Magisk Hide

But some apps could look for something benign, like TWRP folder and just because of that they declare that the phone is rooted

Etc

i didn't read it, i'll head now there and take a look, but yes, i pass safetynet every time, have those apps under magisk hide, and also magisk manager itself hiden with random named data folder, and still didn't help. Thx for magisk github, hope there will find solution

 

[pndwal]

Flashing DOES NOT fail, we patch and flash the patched boot img and have the Magisk up and running

About 'remembering', finding and declaring that there is no Ramdisk, look at my previous post and the log attached there

Please read carefully what I said. It WILL fail for these devices (w/ non ramdisk compatible bootloaders)! This is the whole reason John added Magisk in Recovery option.

And of course there is now ramdisk; Magisk adds it! ... But this DOES NOT mean it's usable (unless OEM happens to leave legacy support in bootloader, as does Xiaomi)... It's simply reporting no FACTORY ramdisk as this is the only one sure to work. (Factory ramdisk present indicates compatible bootloader. Manually added ramdisk indicates nothing!) PW

 

[nowster]

Does anyone have same issues with hiding magisk actually not working after update from few days ago? Apps actually recognize root, even if all things are enabled magiskhide and hide the magisk app. I'm on LG H930DS Oreo Europe software

Reboot. You'll probably find MagiskHide has turned itself off. Turn it back on.

It sometimes happens with the recent update.

 

[pndwal]

Ok so maybe there is another bug then - Magisk app just incorrectly declares that Magisk is installed

And maybe I was wrong all the time thinking that I'm using Magisk, while I could not be, because the way it was installed must fail

Then sorry for spamming in this thread, if not running Magisk my opinions are not relevant

Of course it's not incorrect, you have Magisk, and no-one said it must fail w/ this Installation method, and please don't make out I did! ☹

It's just as John said:

Some Type III devices’ bootloader will still accept and provide initramfs that was manually added to the boot image to the kernel (e.g. some Xiaomi phones), but many device don’t (e.g. Samsung S10, Note 10). It solely depends on how the OEM implements its bootloader.

And no need to apologize for all that spam! FWIW I quite enjoy your opinions. Seriously; all learn from each other here!

PW

 

[Newtype14]

Writing this to avoid any confusion:

Device: Samsung Galaxy S7, Stock Android 8.0.
Context: Updated to latest version of Magisk, then phone wouldn't boot past the Samsung logo.

So I found what the issue is. It seems that on my device, if I install TWRP without Magisk, my phone will bootloop.
Installing Magisk through TWRP fixed the issue. (I tried installing it with ADB/Fastboot like the instructions say, but Fastboot couldn't detect my device; I don't even think the S7 has a Fastboot mode, or if it has one it's different.)

What I think happened is that when I updated Magisk, the phone then rebooted, but Magisk stopped preventing my phone from bootlooping. I'm not knowledgeable enough about this to know why.

So now everything works fine. Phone is restored with my old Backup too, but I'm worried if the same thing will happen again every time there's a new Magisk update.

Thanks to everyone who tried to help.

 

[pndwal]

FWIW, John gave some clarification on why Magisk "Says Ramdisk No, but still works, annoyingly" last October:

topjohnwu commented on 5 Oct 2020

In the last section in Android Booting Shenanigans is your answer. And I quote: Some Type III devices’ bootloader will still accept and provide initramfs that was manually added to the boot image to the kernel (e.g. some Xiaomi phones), but many device don’t (e.g. Samsung S10, Note 10). It solely depends on how the OEM implements its bootloader. It is literally impossible for Magisk to know whether a device bootloader accepts ramdisk, so the assumption is to always inform the user to use recovery mode

This and other details:
https://xdaforums.com/t/magisk-general-support-discussion.3432382/post-83987947 PW

 

[ineedroot69]

So anybody experience this after a failed Magisk v22.0 installation attempt ??
my phone is 100% fully operational but everytime i boot up my device or access recovery mode (I can access recovery mode ) this thing always shows up but my device is 100% fully operational IDK should i try to fix it or just leave it there??

 

[ineedroot69]

update::
So i did some searching and apparently dm-verity is a feature that verify Android partition( system, vendor, and optionally oem partitions ) with SHA256 checksum hash. and due to the fact that i tried fixing Magisk 22.0 installation issue by flashing my "dumped" stock "system.img" (i'm the one who dumped it i'm pretty sure its stock version) . I guess you could say my device is Stock ROM but since SHA256 checksum didn't match dm-verity is triggered .. well fuk me then

 

[pixbuf]

My device is a Sony Z2 tablet running AICP, android version 10. For years up to now I have had no trouble with Magisk. But when I updated to v22 the Magisk app says Magisk is not installed. I followed the "100% guaranteed to work method":

1. extracted boot.img from ROM
2. patched boot.img with Magisk
3. copied magisk_patched_*.img to PC
4. fastboot flash boot magisk_patched_*.img

Magisk still says it's not installed. I tried changing .apk to .zip and flashing it in TWRP. Nope. I tried uninstalling and reinstalling magisk_v22.0.apk. Nope.
Any ideas?
TIA

 

[pndwal]

My device is a Sony Z2 tablet running AICP, android version 10. For years up to now I have had no trouble with Magisk. But when I updated to v22 the Magisk app says Magisk is not installed. I followed the "100% guaranteed to work method":

1. extracted boot.img from ROM
2. patched boot.img with Magisk
3. copied magisk_patched_*.img to PC
4. fastboot flash boot magisk_patched_*.img

Magisk still says it's not installed. I tried changing .apk to .zip and flashing it in TWRP. Nope. I tried uninstalling and reinstalling magisk_v22.0.apk. Nope.
Any ideas?
TIA

Did you previously have a hidden Manager? Did you restore it first? PW

 

[jelly_jeremy]

If only people could read requirements and that highlighted sentences when prompted to update. Everything is written in that update notes, called changelog...

The problem is, we tap the update notification pushed out by the old magisk app without reading the changelog because there isn't one in the notification. Not everyone is free to look at the changelog on GitHub or here before installing every version. We only found out that we have to unhide magisk manager before installing the new app, after installing the new app.

So maybe it's a new circumstances where no one is at fault here? Maybe the users will have to adopt the new habit of reading changelog before installing EVERY VERSION. Or maybe the developers can learn to not push out notifications to ask users to update directly without warning when there is some big change like this in the future? No?

 

[tramp20]

My device is a Sony Z2 tablet running AICP, android version 10.
Any ideas?

Magisk versions > 20.4 are incompatible with Sony Xperias :-(

Please read https://github.com/topjohnwu/Magisk/issues/3636

You can either update your old previous version with Magisk app (Manager) v.22.0 or try the patched boot.img (this does work) and then update.

 

[DiamondJohn]

I have a Pixel 4a running A11. From what I have found, there is no TWRP for this device on this firware. So, if a Magisc module creates a bootloop, I do not know how to resolve it. by deleting or disabling the speific module

If I flash the stock boot image, Magisk is gone and so the bootloop stops, HOWEVER, I also loose root, and so I cant manually disable the offending module manually.

How do I disable a module triggering a bootloop, without TWRP?

 

[kiwigi]

Writing this to avoid any confusion:

Device: Samsung Galaxy S7, Stock Android 8.0.
Context: Updated to latest version of Magisk, then phone wouldn't boot past the Samsung logo.

So I found what the issue is. It seems that on my device, if I install TWRP without Magisk, my phone will bootloop.
Installing Magisk through TWRP fixed the issue. (I tried installing it with ADB/Fastboot like the instructions say, but Fastboot couldn't detect my device; I don't even think the S7 has a Fastboot mode, or if it has one it's different.) ........

I've got the same phone and the same stock version.
To be able to use ADB you need to have the drivers installed on the PC( and I'm sure you have done that) . Then connect via usb from the motherboard port( better).
In Android make sure it is connected for charging, not for file transfer.
Use command prompt on the PC and use the ADB commands.
It took me ages to find this out.
I've got a file somewhere with a few command samples if you need.
Does the above make sense?
Good luck.